[ic] IC 5.6.0 parse_page: Error parsing page. - Possible Bug

ic at 3edge.com ic at 3edge.com
Sun Jul 6 15:58:03 UTC 2008

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
> users-bounces at icdevgroup.org] On Behalf Of Andrew Rich
> Sent: zondag 22 juni 2008 14:46
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] IC 5.6.0 parse_page: Error parsing page. - Possible
> Bug
> > I was able to get this same error on the demo1 site.
> >
> > create new page with left and top areas.
> >
> > I am not sure if creating a new page is a site restriction
> > (permissions error) or an actual bug.
> >
> > Anyone want to give this a try that has access to the Demo server?
> >
> > Steve
> Is there anyone able to help with this error as my customer is unable
> to
> edit their website properly?

I've been going over this issue during this weekend, install IC 5.6.0 with
the Standard demo, trying to figure out what is happening. Also to refer to
a previous thread by Ton & Stefan:

A quick work around to be able to create new pages is to comment out lines
2886-2889 in lib/UI/ContentEditor.pm  and add a ; to the line before
(parse_page($pref, $opt)). What this breaks, no clue - Mike jump in any time

The biggest issue seems to be that $opt->{new} is not set in case of a new
page, where the code seems to be suggesting that it bases certain decisions
on the existence of this $opt->{new}  ...

However if $opt->{new} would actually exist and one passes through the code
then eventually the 'return @compnames' returns again '0'  for a new page. I
have not gone through the big pile of code before the return, but I assume
that for a new page there is nothing yet defined. And this would again make
the parse_page sub return 'false' ... 

I've taken a look how to solve certain things. Passing on the 'new=1' as a
cgi param will not work because it depends on this param to show either the
screen to enter the page name/template and then to pass through the same
'lib/UI/admin/content_editor.html' to get the page to be edited shown.

Perhaps 'sub read_page' in ContentEditor.pm  could be used to stick in the
$opt->{new}.  Also there is something odd. There is an 'else { $opt->new = 1
}' but the previous      elsifs would always be called, because $spec is the
filename which if not existing would have already caused error messages. 

But whichever fix is made, the latest change seems to not be the way to say
'oh if I return false/0 etc it must be because something is wrong'  ....

I'm very short in my time and I think it needs more than just a line to be
fixed, so this is all I am able to contribute towards this issue for the
time being. Hopefully someone with more insight into the content editor can
give better ideas. As it is branded a 'legacy' tool I do not know if much
development is to be expected anymore in this area.



More information about the interchange-users mailing list