phpwiki-talk Mailing List for PhpWiki (Page 6)

And happy new year to you! I just tried the latest release candidate, and
it looks very nice! As mentioned in an email over the weekend, I am seeing
a bit of strangeness in the left margin, a few errors and warnings at the
bottom of pages, and captcha images not showing up. This is all running
under Fedora 16. My test server is at
http://hallikainen.org:8080/BroadcastHistory/
Thanks!
Harold
-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Not sent from an iPhone.
-- 
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
Not sent from an iPhone.

On Tue, Jan 3, 2012 at 8:53 AM, Marc-Etienne Vargenau
<Mar...@al...> wrote:
> Hello all Phpwiki users,
>
> The Phpwiki team wishes you a happy new year 2012.
>
> Reini, will you have some time so that we can get the
> final 1.4.0 out?
Yes. It was on my new year plan.
I'm just preparing a server for phpwiki.org (a fast standalone machine
with physical access, php-5.2.6),
preparing the domain name change from Steve Wainstead (got stuck but
now finally got a server),
and release 1.4.0 as is.
-- 
Reini Urban
http://cpanel.net/  http://www.perl-compiler.org/

Hello all Phpwiki users,
The Phpwiki team wishes you a happy new year 2012.
Reini, will you have some time so that we can get the
final 1.4.0 out?
Best regards,
Marc-Etienne
-- 
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Mar...@al...

Le 02/01/2012 04:54, Harold Hallikainen a écrit :
> Also, when editing a page, the captcha image is not showing up. Instead, I
> see "<img src="?action=captcha&id=1325476355" alt="captcha" />
> <label for="edit-captcha_input">Type word above:</label>"
Hello again,
This is fixed in Subversion 8217.
You can:
1) Try with the latest Subversion trunk instead of 1.4.0RC1
or
2) Modify file lib/Captcha.php
as in
http://phpwiki.svn.sourceforge.net/viewvc/phpwiki/trunk/lib/Captcha.php?r1=8071&r2=8217&pathrev=8217
Best regards,
Marc-Etienne
-- 
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Mar...@al...

Le 02/01/2012 04:54, Harold Hallikainen a écrit :
> I'm slowly migrating from Fedora 11 to Fedora 16 and updating my phpwiki
> in the process. It's looking pretty food, but I'm seeing a few problems.
> The new wiki is at
>
> http://www.hallikainen.org:8080/phpwiki-1.4.0rc1/index.php/HomePage .
>
> The problem areas are in the left margin where I'm seeing stuff like:
>
> # setAttr("accesskey","r"); $link->addTooltip(_("The list of recent
> changes in the wiki.")." [$p-r]"); ?>
> # RecentNewPages
> # What links here
> # setAttr("accesskey","u"); $link->addTooltip(_("Upload images or media
> files")." [$p-u]"); ?>
>
> under Toolbox.
Hello Harold,
Thank you for your interest in Phpwiki.
I cannot reproduce your problem, but it is probably related to
the fact that the file
themes/Sidebar/templates/navbar.tmpl
uses the old PHP syntax "<?" instead of "<?php".
Can you please:
1) Try with the latest Subversion trunk instead of 1.4.0RC1
or
2) Modify file themes/Sidebar/templates/navbar.tmpl
as in
http://phpwiki.svn.sourceforge.net/viewvc/phpwiki/trunk/themes/Sidebar/templates/navbar.tmpl?r1=8166&r2=8216&pathrev=8216
Happy new year 2012!
Marc-Etienne
-- 
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Mar...@al...

I'm slowly migrating from Fedora 11 to Fedora 16 and updating my phpwiki
in the process. It's looking pretty food, but I'm seeing a few problems.
The new wiki is at
http://www.hallikainen.org:8080/phpwiki-1.4.0rc1/index.php/HomePage .
The problem areas are in the left margin where I'm seeing stuff like:
# setAttr("accesskey","r"); $link->addTooltip(_("The list of recent
changes in the wiki.")." [$p-r]"); ?>
# RecentNewPages
# What links here
# setAttr("accesskey","u"); $link->addTooltip(_("Upload images or media
files")." [$p-u]"); ?>
under Toolbox.
Also, there are some php warnings and another warning at the bottom of page.
Also, when editing a page, the captcha image is not showing up. Instead, I
see "<img src="?action=captcha&id=1325476355" alt="captcha" />
<label for="edit-captcha_input">Type word above: </label>"
THANKS for any help!
Harold

2011年4月17日 Pat Grogan <pat...@bi...>:
> I have just migrated from a very early version of phpwiki to the very
> latest.
which version exactly?
1.4.0-rc1 or svn?
We would recommend svn, because we do not break things.
> I have got the wiki up and working but a soon as I try and edit the main
> page I get the following error:
>
> Fatal Error:
>
> lib/WikiDB/backend/PearDB.php:1061 Error[256]:
> WikiDB_backend_PearDB_pgsql: fatal database error
>
>  * DB Error: constraint violation
>  * (DELETE FROM version WHERE id=98 AND version=1 [nativecode=ERROR:
> update or delete on table "version" violates foreign key constraint
> "recent_id_fkey1" on table "recent"
>  * DETAIL: Key (id,version)=(98,1) is still referenced from table
> "recent".])
Hmm, looks like a major problem with autocleanup of older versions.
We don't really have to delete older versions anymore, only on
restricted size databases.
Please check if these values work for you until I have found the real problem:
MAJOR_MIN_KEEP = 2147483647
MINOR_MIN_KEEP = 2147483647
> Any help would be most appreciated.
-- 
Reini Urban
http://phpwiki.org/      http://murbreak.at/

I have just migrated from a very early version of phpwiki to the very
latest.
I have got the wiki up and working but a soon as I try and edit the main
page I get the following error:
Fatal Error:
lib/WikiDB/backend/PearDB.php:1061 Error[256]:
WikiDB_backend_PearDB_pgsql: fatal database error
 * DB Error: constraint violation
 * (DELETE FROM version WHERE id=98 AND version=1 [nativecode=ERROR:
update or delete on table "version" violates foreign key constraint
"recent_id_fkey1" on table "recent"
 * DETAIL: Key (id,version)=(98,1) is still referenced from table
"recent".])
Here is the database setup for each of the tables:
phpwiki=# \d recent
 Table "public.recent"
 Column | Type | Modifiers 
---------------+---------+-----------
 id | integer | 
 latestversion | integer | 
 latestmajor | integer | 
 latestminor | integer | 
Indexes:
 "recent_id_idx" UNIQUE, btree (id)
 "recent_lv_idx" btree (latestversion)
Check constraints:
 "recent_check" CHECK (latestminor >= latestmajor)
Foreign-key constraints:
 "recent_id_fkey" FOREIGN KEY (id) REFERENCES page(id)
 "recent_id_fkey1" FOREIGN KEY (id, latestversion) REFERENCES
version(id, version)
phpwiki=# 
phpwiki=# \d page
 Table "public.page"
 Column | Type |
Modifiers 
-------------+------------------------+---------------------------------------------------
 id | integer | not null default
nextval('page_id_seq'::regclass)
 pagename | character varying(100) | not null
 hits | integer | not null default 0
 pagedata | text | not null default ''::text
 cached_html | text | default ''::text
Indexes:
 "page_pkey" PRIMARY KEY, btree (id)
 "page_pagename_key" UNIQUE, btree (pagename)
Check constraints:
 "page_pagename_check" CHECK (pagename::text <> ''::text)
Referenced by:
 TABLE "link" CONSTRAINT "link_linkfrom_fkey" FOREIGN KEY (linkfrom)
REFERENCES page(id)
 TABLE "link" CONSTRAINT "link_linkto_fkey" FOREIGN KEY (linkto)
REFERENCES page(id)
 TABLE "nonempty" CONSTRAINT "nonempty_id_fkey" FOREIGN KEY (id)
REFERENCES page(id)
 TABLE "pagedata" CONSTRAINT "pagedata_id_fkey" FOREIGN KEY (id)
REFERENCES page(id)
 TABLE "pageperm" CONSTRAINT "pageperm_id_fkey" FOREIGN KEY (id)
REFERENCES page(id)
 TABLE "rating" CONSTRAINT "rating_rateepage_fkey" FOREIGN KEY
(rateepage) REFERENCES page(id)
 TABLE "rating" CONSTRAINT "rating_raterpage_fkey" FOREIGN KEY
(raterpage) REFERENCES page(id)
 TABLE "recent" CONSTRAINT "recent_id_fkey" FOREIGN KEY (id)
REFERENCES page(id)
 TABLE "version" CONSTRAINT "version_id_fkey" FOREIGN KEY (id)
REFERENCES page(id)
I manually went into the postgres database phpwiki and removed the entry
id 98 from table recent and was able to edit the home page. However once
saved another edit fails with the same error.
Is this a schema error or am I using an incorrect procedure?
I am using postgres on Ubuntu 10.10.
Any help would be most appreciated.
Thanks,
Pat

Hello,
I tried to download latest SVN files on 8th March, but still I have an error.
I have Apache with PHP 5.3.5.
The errors look like:
Strict Standards: Non-static method HTML::getTagProperties() should
not be called statically, assuming $this from incompatible context in
X:\xampp\htdocs\phpwiki\lib\HtmlElement5.php on line 45
...
Error: "Non-static method FileFinder::_get_lang() should not be called
statically"
...
Error: "Non-static method _variable_password::get_html() should not be
called statically, assuming $this from incompatible context"
Can this be fixed or should I better use older Apache/PHP?
Thanks
 Filip
On Thu, Mar 3, 2011 at 12:35 PM, Reini Urban - ru...@x-...
<+pw+firy+70c624cc55.rurban#x-r...@sp...> wrote:
> 2011年3月3日 <pw...@an...>:
>> is there some tutorial installing Phpwiki on Windows XP on Apache server?
>>
>> I tried to install Phpwiki (phpwiki-1.4.0rc1.zip) on default Apache
>> XAMPP server installation, but on the configuration page titled
>> "Configuration for PhpWiki config\config.ini" I get a lot of errors
>> like:
>>
>> Strict Standards: Non-static method HTML::getTagProperties() should
>> not be called statically, assuming $this from incompatible context in
>> X:\xampp\htdocs\phpwiki\lib\HtmlElement5.php on line 45
>>
>> Can somebody help me?
>> I am not an administrator guru, just something between intermediate
>> and litle advanced.
>
> Which php version exactly?
> Looks like a problem we fixed only recently for php-5.3, so you would
> need latest svn.
>
> svn co https://phpwiki.svn.sourceforge.net/svnroot/phpwiki phpwiki
>
> --
> Reini Urban
> http://phpwiki.org/      http://murbreak.at/
>
>

2011年3月3日 <pw...@an...>:
> is there some tutorial installing Phpwiki on Windows XP on Apache server?
>
> I tried to install Phpwiki (phpwiki-1.4.0rc1.zip) on default Apache
> XAMPP server installation, but on the configuration page titled
> "Configuration for PhpWiki config\config.ini" I get a lot of errors
> like:
>
> Strict Standards: Non-static method HTML::getTagProperties() should
> not be called statically, assuming $this from incompatible context in
> X:\xampp\htdocs\phpwiki\lib\HtmlElement5.php on line 45
>
> Can somebody help me?
> I am not an administrator guru, just something between intermediate
> and litle advanced.
Which php version exactly?
Looks like a problem we fixed only recently for php-5.3, so you would
need latest svn.
svn co https://phpwiki.svn.sourceforge.net/svnroot/phpwiki phpwiki
-- 
Reini Urban
http://phpwiki.org/      http://murbreak.at/

Hello,
is there some tutorial installing Phpwiki on Windows XP on Apache server?
I tried to install Phpwiki (phpwiki-1.4.0rc1.zip) on default Apache
XAMPP server installation, but on the configuration page titled
"Configuration for PhpWiki config\config.ini" I get a lot of errors
like:
Strict Standards: Non-static method HTML::getTagProperties() should
not be called statically, assuming $this from incompatible context in
X:\xampp\htdocs\phpwiki\lib\HtmlElement5.php on line 45
Can somebody help me?
I am not an administrator guru, just something between intermediate
and litle advanced.
Thanks
 Filipes

Hi,
On 22/02/2011 20:20, Reini Urban wrote:
> Is this acceptable fast for you?
> For me gives nothing.
Yeah, looks good.
>
> http://phpwiki.sourceforge.net/scripts/phpinfo.php
> content:<?php phpinfo(); ?>
>
> I'm just trying to revive our old webspace.
Excellent!
Seb

2011年2月23日 Marc-Etienne Vargenau <Mar...@al...>:
> Le 22/02/2011 21:20, Reini Urban a écrit :
>> Is this acceptable fast for you?
>> For me gives nothing.
>>
>> http://phpwiki.sourceforge.net/scripts/phpinfo.php
>> content:<?php phpinfo(); ?>
>>
>> I'm just trying to revive our old webspace.
>
> Hello Reini,
>
> It is quite good for me.
> Great if you can make it work again.
Oh, interesting. Here in Germany it is superfast. At home it didn't work at all.
I tried to reactivate it again, without the VIRTUAL tricks which might
confuse front-proxy.
Good, looks like we can use our old webspace again with the new system
they installed.
We even have shell access again.
http://phpwiki.sourceforge.net/phpwiki14/ will be the new url.
-- 
Reini Urban
http://phpwiki.org/      http://murbreak.at/

Le 22/02/2011 21:20, Reini Urban a écrit :
> Is this acceptable fast for you?
> For me gives nothing.
>
> http://phpwiki.sourceforge.net/scripts/phpinfo.php
> content:<?php phpinfo(); ?>
>
> I'm just trying to revive our old webspace.
Hello Reini,
It is quite good for me.
Great if you can make it work again.
Marc-Etienne
-- 
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Mar...@al...

Hi Reini,
Sounds acceptable from france at least.
On Tue, Feb 22, 2011 at 9:20 PM, Reini Urban <ru...@x-...> wrote:
> Is this acceptable fast for you?
> For me gives nothing.
>
> http://phpwiki.sourceforge.net/scripts/phpinfo.php
> content: <?php phpinfo(); ?>
>
> I'm just trying to revive our old webspace.
> --
> Reini Urban
> http://phpwiki.org/ http://murbreak.at/
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Is this acceptable fast for you?
For me gives nothing.
http://phpwiki.sourceforge.net/scripts/phpinfo.php
content: <?php phpinfo(); ?>
I'm just trying to revive our old webspace.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Maybe this will change our hosting problems.
---------- Forwarded message ----------
From: SourceForge.net Team <no...@so...>
Date: 2011年2月9日
Subject: Project web service changes for your projects
To: ru...@x-...
Hello,
We are pleased to announce the rollout of our updated project web
service to all projects. This rollout has been undertaken on an
expedited basis to make security improvements available for this
service and was announced to our blog at the start of our incident
response.
Full details are in our site docs at: http://tinyurl.com/sfprweb
This updated service has been tested over the past few months and
provides substantial improvements:
* File access is now per-project when file perms are set properly,
allowing you to safeguard database passwords and other confidential
data.
* Directory space is now writable by your app code, eliminating the
need to use our old /home/persistent space.
* Web logs are available (IPs are obfuscated).
* Updated PHP, Python, Perl, etc.
* Outbound email is permitted via authenticated SMTP service (password
is per-project).
Your applications may need updates to work under new PHP (5.3 has some
changes) and optimally with our new file permissions model. Please
review the documentation provided above and contact us at
sfn...@ge... if you have any questions.
Rollout will commence today (Wednesday) with 'a' projects, continuing
through the alphabet until all migrations are complete. For further
progress information, please watch our blog at:
http://sourceforge.net/blog
Thank you,
The SourceForge.net Team
----------------------------------------------------------------------
SourceForge.net has made this mailing to you as a registered user of
the SourceForge.net site to convey important information regarding
your SourceForge.net account or your use of SourceForge.net services.
We make a small number of directed mailings to registered users each
year regarding their account or data, to help preserve the security of
their account or prevent loss of data or service access.
If you have concerns about this mailing please contact our Support
team per: http://sourceforge.net/support
-- 
Reini Urban
http://phpwiki.org/      http://murbreak.at/

Le 04/01/2011 16:34, Reini Urban a écrit :
 >
 > Can we please make these discussion public, on the mailinglist?
 >
Sure.
 >> == Bug tracker ==
 >>
 >> * 3041169 can be changed to fixed
 >> * 3024802 can be changed to fixed
 >> * 3022476 can be changed to fixed
 >> * 3018502 can be changed to fixed (please check, cannot reproduce)
 >> * 1906123 can be changed to fixed
 >> * 1847961 can be changed to fixed
 >> * 1811616 can be changed to fixed
 >> * 1683604 should be changed from wontfix to fixed
 >
 > I gave you tracker premissions. Sorry I forgot. Better if your write
 > the descriptions
I have updated these, except 3018502 that I cannot reproduce.
It would be nice if you could go thru the list, some old bugs
can probably be closed.
 >> == Help ==
 >>
 >> Could you help me to solve these problems?
 >>
 >> My users complain that BackLinks do not work when the text is 
handled via
 >> plugins:
 >> * link is inside a RichTable or Mediawiki table
 >> * link is inside a page included via IncludePage
 >> * etc.
 >> How should this be solved?
 >
 > Yes I can do that. There are two ways to format test, we are using the
 > fast one without link resolving here.
It would be really great if you can solve that.
 >> My users complain that Table of Contents is not correct when previewing.
 >>
 >> How should this be solved?
 >
 > Uuh, this is pretty hard when the headlines contains formatting,
 > because we look at
 > the already formatted part when parsing the headers.
This one is less important than the others.
Best regards,
Marc-Etienne
-- 
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Mar...@al...

2011年1月4日 Marc-Etienne Vargenau <Mar...@al...>:
> Le 03/01/2011 18:08, Reini Urban a écrit :
>> 2011年1月3日 Marc-Etienne Vargenau<Mar...@al...>:
>>> Hello Reini,
>>>
>>> I wish you a happy new year 2011!
>>
>> Thanks, to you also!
>>
>>> Could we have a short chat or telephone meeting to see what
>>> is needed to finalize Phpwiki 1.4.0?
>>
>> Can we do tomorrow?
>> I found some new ugly blockers and haven't found time yet to write them
>> down.
>
> Hello Reini,
>
> It is OK for me today. At what time should I call you?
> What number?
>
> Here are some point to discuss.
Can we please make these discussion public, on the mailinglist?
> == Questions ==
>
> * You said you had an article ''Introduction to semantic Web''. Could you
> please send it to me?
I only have some notes in the library,
but I gave 3 public talks about a short intro to semantic web, with phpwiki.
There is no written article though.
> * What about a demo site for Phpwiki?
Sure. The user who gave us a site did not have a working vhost setup.
But I had a look at free php hosters, and apparently there are some free
options.
> * PHP5?
We still use RHEL4, which has 4.3.9.
Most providers and conservative companies use Redhat or CentOS, which
is mostly still based on redhat 4.
So we have to stick to 4.3.9 until february 2011. My company uses
RHEL4 so I have to use it also, though it's a nightmare.
Then RHEL4 support ends.
With php5 we could add e.g. facebook connect, and better semantic web
libraries. SPARQL support e.g.
> * Could we have meetings on a regular basis (e.g every 2 months?)
Sure.
> == Bug tracker ==
>
> * 3041169 can be changed to fixed
> * 3024802 can be changed to fixed
> * 3022476 can be changed to fixed
> * 3018502 can be changed to fixed (please check, cannot reproduce)
> * 1906123 can be changed to fixed
> * 1847961 can be changed to fixed
> * 1811616 can be changed to fixed
> * 1683604 should be changed from wontfix to fixed
I gave you tracker premissions. Sorry I forgot. Better if your write
the descriptions
>
> == Blockers ==
>
> * AllPages does not work (with Pear)
> * WantedPages give too many pages (from interwiki map)
I had more:
My RHEL4 libmysql is broken with utf8, I just added a ticket.
The current solution is ugly.
> == Others ==
>
> * Minimizer for JS/CSS
> ** no "make clean" in themes
> ** "make clean" does not work in themes with no Javascript
> ** in MonoBook, IEFixes.js cannot be minimized, yuicompressor-2.4.2 gives
> syntax errors
I think we used another one before. minify or jsmin, forgot which exactly.
http://javascript.crockford.com/jsmin.html maybe.
Google seems to have a better minifier.
> == Help ==
>
> Could you help me to solve these problems?
>
> My users complain that BackLinks do not work when the text is handled via
> plugins:
> * link is inside a RichTable or Mediawiki table
> * link is inside a page included via IncludePage
> * etc.
> How should this be solved?
Yes I can do that. There are two ways to format test, we are using the
fast one without link resolving here.
> My users complain that Table of Contents is not correct when previewing.
>
> How should this be solved?
Uuh, this is pretty hard when the headlines contains formatting,
because we look at
the already formatted part when parsing the headers.
> I solved the fact that TOC was not correct when previewing an old release of
> the
> page but could not find a way to solve this one.
-- 
Reini Urban
http://phpwiki.org/      http://murbreak.at/

On 2010年11月17日 13:48:17 +0100, Marc-Etienne Vargenau
<Mar...@al...> wrote:
> 
> Hello,
> 
> Are you using Phpwiki 1.4.0RC1?
I'm using 1.3.14, the latest version in Gentoo portage.
I'm not sure if the ebuild is maintained anymore so my best bet is
probably to remove the ebuild and install from source.
Before I do that I'll see if I can make the change you suggest below in
main.php.
Thanks for the help,
Peter
> 
> Phpwiki 1.4.0RC1 should take care of this.
> 
> See:
> if (defined('E_STRICT')) // and (E_ALL & E_STRICT)) // strict php5?
> $ErrorManager->setPostponedErrorMask(E_NOTICE|E_USER_NOTICE|E_USER_WARNING|E_WARNING|E_STRICT|((check_php_version(5,3))
>
> ? E_Db/FileFinder.phpEPRECATED : 0));
> else
> $ErrorManager->setPostponedErrorMask(E_NOTICE|E_USER_NOTICE|E_USER_WARNING|E_WARNING);
> 
> in file lib/main.php
> 
> Best regards,

Le 17/11/2010 11:17, Peter Campion-Bye a écrit :
> Hi,
> Since updating php to version 5.3.3 my phpwiki is failing with errors
> such as this:
> lib/FileFinder.php:159 Error[8192]: Function ereg() is deprecated
>> From looking around on the web I see that it is possible to work
> around this by putting in -E_DEPRECATED somewhere, but I can't see
> where.
> Is it possible someone could provide a quick patch to put in
> -E_DEPRECATED and get me running again.
> I appreciate there may be other reasons it won't work with 5.3.3 and a
> longer term solution will be required, but if it's only a case of
> switching off the deprecated function errors then I'd rather go with
> that than downgrade php.
Hello,
Are you using Phpwiki 1.4.0RC1?
Phpwiki 1.4.0RC1 should take care of this.
See:
if (defined('E_STRICT')) // and (E_ALL & E_STRICT)) // strict php5?
$ErrorManager->setPostponedErrorMask(E_NOTICE|E_USER_NOTICE|E_USER_WARNING|E_WARNING|E_STRICT|((check_php_version(5,3)) 
? E_Db/FileFinder.phpEPRECATED : 0));
 else
$ErrorManager->setPostponedErrorMask(E_NOTICE|E_USER_NOTICE|E_USER_WARNING|E_WARNING);
in file lib/main.php
Best regards,
-- 
Marc-Etienne Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE
+33 (0)1 30 77 28 33, Mar...@al...

2010年11月17日 Peter Campion-Bye <pe...@pa...>:
> Since updating php to version 5.3.3 my phpwiki is failing with errors
> such as this:
> lib/FileFinder.php:159 Error[8192]: Function ereg() is deprecated
> >From looking around on the web I see that it is possible to work
> around this by putting in -E_DEPRECATED somewhere, but I can't see
> where.
> Is it possible someone could provide a quick patch to put in
> -E_DEPRECATED and get me running again.
> I appreciate there may be other reasons it won't work with 5.3.3 and a
> longer term solution will be required, but if it's only a case of
> switching off the deprecated function errors then I'd rather go with
> that than downgrade php.
The latest 1.4.0rc1 release as well as the code from svn with a few
more fixes handles those problems.
We want to bring out a new 1.4.0rc2, but I got one more blocking
bug in the backlink database handling (dba only I guess)
-- 
Reini Urban
http://phpwiki.org/      http://murbreak.at/

Hi,
Since updating php to version 5.3.3 my phpwiki is failing with errors 
such as this:
lib/FileFinder.php:159 Error[8192]: Function ereg() is deprecated
>From looking around on the web I see that it is possible to work 
around this by putting in -E_DEPRECATED somewhere, but I can't see 
where.
Is it possible someone could provide a quick patch to put in 
-E_DEPRECATED and get me running again.
I appreciate there may be other reasons it won't work with 5.3.3 and a 
longer term solution will be required, but if it's only a case of 
switching off the deprecated function errors then I'd rather go with 
that than downgrade php.
Thanks
Peter

2010年11月12日 Wes Deviers <yh...@gm...>:
> I've been trying to move an older phpwiki installation onto new hardware.
> Originally, I tried to just tar & copy, but that failed totally. So
> instead, I exported the entire thing to an archive zip, did a clean SVN pull
> (today) and imported the zip in. It's moving from Ubuntu 6.04 to 8.04, so
> PHP4 to PHP5. Also, it's moving from Postgres to Mysql. Should be
> unimportant.
>
> Anyway, it appeared to work fine, as it has in the past. But when I go to
> edit a page, I get blankness. Specifically, it's a completely blank page,
> without even basic HTML open/close, but with normal output headers. This is
> running on Apache 2.2.12, PHP 5.2.10. Using LDAP authentication (which
> works, except for bad ADMIN user interactions) just in case that matters.
>
> I tried hacking up the error handling code to get full PHP errors to
> display, but I did it very wrong and just broke things. Other pages dump
> errors but I can't read them. I've tried switching themes; certain themes
> seem to work better than others. I tried the most recent RC as a straight
> install with no SVN pull; same problem.
>
> Searching through the mailing list archives for "edit blank page" turns out
> to be...ineffective...
action=edit parses e.g. all plugins, and on any syntax error it will
fail with such a
blank page. sorry for the bad error handling.
you can try PluginManager to check that (with better error handling)
and you can also try to delete the caches. (toolbar, images)
the internal php format changed, so you will also get such an error.
-- 
Reini Urban
http://phpwiki.org/      http://murbreak.at/

Hi everybody,
I've been trying to move an older phpwiki installation onto new hardware.
Originally, I tried to just tar & copy, but that failed totally. So
instead, I exported the entire thing to an archive zip, did a clean SVN pull
(today) and imported the zip in. It's moving from Ubuntu 6.04 to 8.04, so
PHP4 to PHP5. Also, it's moving from Postgres to Mysql. Should be
unimportant.
Anyway, it appeared to work fine, as it has in the past. But when I go to
edit a page, I get blankness. Specifically, it's a completely blank page,
without even basic HTML open/close, but with normal output headers. This is
running on Apache 2.2.12, PHP 5.2.10. Using LDAP authentication (which
works, except for bad ADMIN user interactions) just in case that matters.
I tried hacking up the error handling code to get full PHP errors to
display, but I did it very wrong and just broke things. Other pages dump
errors but I can't read them. I've tried switching themes; certain themes
seem to work better than others. I tried the most recent RC as a straight
install with no SVN pull; same problem.
Searching through the mailing list archives for "edit blank page" turns out
to be...ineffective...
Any and all suggestions welcome : )
Thanks!
Wes D