As we dropped PHP 3 support, we might also want to start use
require_once to get rid of bug #571409. Does any of you know something
that will need special care or just replacing every require with
require_once should be okay?
is it just me, or we have lost since the last few changes,
the value of Browser transformations?
MIME-type and transformation options are still there in the
structure page of my field, but Browser transformation is blank.
can someone have a look at the demo problem:
Warning: Compilation failed: missing terminating ] for character class
at offset 13 in
on line 1108
This does not happen on my server.
moving this duscussion to list, because I thing it should be there :-)
Original message (Garvin Hicking, 19.11.2003 11:57):
> a) Wait until after 2.5.5 RC1 and apply changes to HEAD then.
> Pro: No hurry for now.
> Con: I might not have the time then :)
No need to wait, if you have time :)
> b) Branch off a QA_2_5_5 tree now, make the RC out from that branch
> and apply my changes to HEAD now.
> Pro: Work can start immediately, a quite stable 2.5.5 release.
> Con: Later PHP4-enabled release
We will say that we don't support php3, but the code will still contain
many things for php3...
> c) Branch of a PHP4_QA tree, apply my changes to that branch, merge
> the changes to HEAD later on.
> Pro: Agitate on a 'secure' branch, work can start immediately
> Con: Maybe harder to merge afterwards, less people testing it (because
> CVS snapshot is from HEAD, and people using CVS directly will most
> likely use HEAD as well).
People expect HEAD to be the currently developped one, changing this
> d) Make changes to HEAD. Make 2.5.5 the first PHP4-release, thus
> moving the 2.5.5 RC1 about 1-2 weeks later and having huge changes in
> that 2.5.5 release.
> Pro: Making a real worthy 2.5.5 release? Work can start immediately.
> Larger testing user base.
> Con: No 2.5.5 release with the latest features, moved schedule.
Good solution. If there are not any things that are worth of releasing
quickly, I'd prefer this.
I just thought about a small optimization that could make our lives a little
As far as I can see, footoer.inc.php is always the last page to be called.
This is why we find much code like this:
imho, we should be able to put the exit call into footer.inc.php, so that we
do not always have to call it manually after having displayed the footer.
Alexander M. Turek
_ __ __ _ _ _
_ __ | |__ _ __ | \/ |_ _ / \ __| |_ __ ___ (_)_ __
| '_ \| '_ \| '_ \| |\/| | | | | / _ \ / _` | '_ ` _ \| | '_ \
| |_) | | | | |_) | | | | |_| |/ ___ \ (_| | | | | | | | | | |
| .__/|_| |_| .__/|_| |_|\__, /_/ \_\__,_|_| |_| |_|_|_| |_|
|_| |_| |___/
as decided long time ago and finally approved today I switched all files
in cvs from php3 to php. Mostly because of dropping support for old PHP
and MySQL versions.
Only thing you may need to change after cvs update is
mv config.inc.developer.php3 config.inc.developer.php
(if you are using this).