phpwiki-talk Mailing List for PhpWiki

Le 25/05/2010 15:55, Reini Urban a écrit :
> Marc-Etienne,
>
> Why did go berserk and removed the getVersion API?
> Subversion id's still provide the only hint on versions for installed
> plugins.
Hello Reini,
We now have a unique identifier for all Phpwiki, including
plugins.
It was confusing for users that getVersion returned
different numbers in PluginManager.
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 25/05/2010 15:49, ru...@us... a écrit :
> Revision: 7444
> http://phpwiki.svn.sourceforge.net/phpwiki/?rev=7444&view=rev
> Author: rurban
> Date: 2010年05月25日 13:49:31 +0000 (2010年5月25日)
>
> Log Message:
> -----------
> provide missing css source
>
> Modified Paths:
> --------------
> trunk/themes/Sidebar/sidebar.css
Hello Reini,
Thank you for this missing file.
I still have the following problems with the minimizer for JS/CSS:
* no "make clean" in themes directory
* "make clean" does not work in themes with no Javascript
* in MonoBook, IEFixes.js cannot be minimized, yuicompressor-2.4.2 gives 
syntax errors
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...

Hi Reini,
On 17/05/2010 21:17, Reini Urban wrote:
>
> Making a new major release is not that easy as most possible cfg's
> have to be tested,
> I found some bugs lately, but didn't find those you found yet.
>
> The new default theme - a new Sidebar based upon Monobook - is still
> not finished.
> Otherwise it should be stable enough.
>
> I had some eye problem (ophthalmitis) in the last two weeks so I'm not
> very fast.
> Hope this over soon.
Sorry to hear that, I hope you'll get well soon!
Are the blocking issues in the bug tracker? I don't mind having a look 
at some if that would help moving things forward. I think there's some 
good stuff in svn, and phpwiki _does_ deserve a new release.
Regards,
Sébastien.

On 18/05/2010 11:24, Manuel Vacelet wrote:
> On Mon, May 17, 2010 at 8:53 PM, Sébastien Le Callonnec<sl...@ya...> wrote:
>> One remaining question, though (probably a FAQ, actually): is there a
>> way of not importing the PhpWiki "core" pages? When exporting, I
>> usually do a full dump, which contains PhpWikiAdministration and all the
>> Help pages, etc. but I don't to import them back, as I may be losing the
>> changes done to these pages as part of the upgrade.
>>
>> Any obvious way of achieving this?
>
> Hi Sebastien,
>
> To handle this case we had to develop a script that remove from within
> this archive all pages with "The PhpWiki team" as author and without
> modification (and maybe pages that are only modified by "The PhpWiki
> team").
>
> I don't have it right now but I could had a look in my archives sometime,
> Manuel
>
Hi Manuel,
Good one, this does the trick indeed. There are still a few "Help" 
files left behind, so I did the following:
rm -f Help*
grep -l "author=The%20PhpWiki%20programming%20team" * | xargs rm -f
Thanks a mil,
Sébastien.

On Mon, May 17, 2010 at 8:53 PM, Sébastien Le Callonnec <sl...@ya...> wrote:
> I've finally been able to import all my pages!!
>
> The last hurdle was that I was trying to export iso-8859-1 pages and
> import them into a utf-8 phpwiki setup: all the pages with non-ASCII
> characters were not being imported because the pagename was not
> converted into utf-8 after the urldecode when importing. A quick change
> to force the pagename to utf-8, and that's it!
>
> One remaining question, though (probably a FAQ, actually): is there a
> way of not importing the PhpWiki "core" pages? When exporting, I
> usually do a full dump, which contains PhpWikiAdministration and all the
> Help pages, etc. but I don't to import them back, as I may be losing the
> changes done to these pages as part of the upgrade.
>
> Any obvious way of achieving this?
Hi Sebastien,
To handle this case we had to develop a script that remove from within
this archive all pages with "The PhpWiki team" as author and without
modification (and maybe pages that are only modified by "The PhpWiki
team").
I don't have it right now but I could had a look in my archives sometime,
Manuel

I've finally been able to import all my pages!!
The last hurdle was that I was trying to export iso-8859-1 pages and 
import them into a utf-8 phpwiki setup: all the pages with non-ASCII 
characters were not being imported because the pagename was not 
converted into utf-8 after the urldecode when importing. A quick change 
to force the pagename to utf-8, and that's it!
One remaining question, though (probably a FAQ, actually): is there a 
way of not importing the PhpWiki "core" pages? When exporting, I 
usually do a full dump, which contains PhpWikiAdministration and all the 
Help pages, etc. but I don't to import them back, as I may be losing the 
changes done to these pages as part of the upgrade.
Any obvious way of achieving this?
Thanks,
Seb
On 14/05/2010 08:22, Sébastien Le Callonnec wrote:
> Hi,
>
>
> I have been looking into problems with some dumped archives which could
> not be imported back into phpwiki.
>
> After some investigation, I have isolated the problem to
> ParseMimeMultipart in ziplib.php; the preg_match was exiting too early.
> The regexp looks ok, but for big archives (whether it is a medium-size
> page with lots of revisions, or a huge file with a couple of revisions),
> preg_match seems to be failing.
>
> It turns out it looks like I'm hitting the pcre backtrack/recursion
> limit. Increasing the values of pcre.backtrack_limit and
> pcre.recursion_limit in php.ini as per
> http://ie.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit
> seems to do the trick, but I was wondering if anybody has hit this issue
> before? I have quite large archives to import, and I am not sure
> whether preg_match is able to cope with them, even with the increased
> values.
>
>
> Thanks,
> Sébastien.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Hi,
I have been looking into problems with some dumped archives which could 
not be imported back into phpwiki.
After some investigation, I have isolated the problem to 
ParseMimeMultipart in ziplib.php; the preg_match was exiting too early. 
 The regexp looks ok, but for big archives (whether it is a medium-size 
page with lots of revisions, or a huge file with a couple of revisions), 
preg_match seems to be failing.
It turns out it looks like I'm hitting the pcre backtrack/recursion 
limit. Increasing the values of pcre.backtrack_limit and 
pcre.recursion_limit in php.ini as per 
http://ie.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit 
seems to do the trick, but I was wondering if anybody has hit this issue 
before? I have quite large archives to import, and I am not sure 
whether preg_match is able to cope with them, even with the increased 
values.
Thanks,
Sébastien.

Hi Marc-Etienne
No problem at all, in fairness it was a big lengthy email!! ;-)
I agree with Charles, phpWiki could do with a new major release that replaces the current stable one that's a bit old now.
I imagine most of the users would get to phpWiki through sourceforge, and seeing that the first version to come up is 1.2.11 cut in 2008, they more than likely pass their way.
Regards,
Sebastien.
> 
> Sébastien LE CALLONNEC a écrit :
> Hi Marc-Etienne,
> 
> As 
> stated in my email, everything "is based on the current source code from svn 
> trunk" since the "current" version (1.3.14) doesn't work out of the box. 
> You can also see this from the patch as it indicates the rev. number it's been 
> generated from.
> 
> 
> Regards,
> 
> Sebastien.
Hello Sébastien,
I am sorry, I did not read you e-mail 
> carefully enough.
I will have a look at your patches.
In fact, I 
> am mostly using Phpwiki integrated with
Gforge/Fusionforge so I do not use 
> the automatic
configuration (my configuration is in the "g" 
> file).
Best regards,
Marc-Etienne
-- 
Marc-Etienne 
> Vargenau
Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, 
> FRANCE
+33 (0)1 30 77 28 33, 
> ymailto="mailto:Mar...@al..." 
> href="mailto:Mar...@al...">Mar...@al...
------------------------------------------------------------------------------
_______________________________________________
Phpwiki-talk 
> mailing list
> href="mailto:Php...@li...">Php...@li...
> href="https://lists.sourceforge.net/lists/listinfo/phpwiki-talk" target=_blank 
> >https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
 

Sébastien LE CALLONNEC a écrit :
> Hi Marc-Etienne,
> 
> As stated in my email, everything "is based on the current source code from svn trunk" since the "current" version (1.3.14) doesn't work out of the box. You can also see this from the patch as it indicates the rev. number it's been generated from.
> 
> 
> Regards,
> Sebastien.
Hello Sébastien,
I am sorry, I did not read you e-mail carefully enough.
I will have a look at your patches.
In fact, I am mostly using Phpwiki integrated with
Gforge/Fusionforge so I do not use the automatic
configuration (my configuration is in the "g" file).
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...

Charles Sprickman a écrit :
> I was not aware there was anything newer - I'll try the svn version.
> 
> Any chance someone will cut a release from this anytime soon?
> 
Reini, can you please answer this?
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...

Reini Urban a écrit :
> 2010年5月4日 <var...@us...>:
>> Revision: 7378
>> http://phpwiki.svn.sourceforge.net/phpwiki/?rev=7378&view=rev
>> Author: vargenau
>> Date: 2010年05月04日 13:49:26 +0000 (2010年5月04日)
>>
>> Log Message:
>> -----------
>> Add Gforge Wiki Configurator
>>
>> Added Paths:
>> -----------
>> trunk/wikiadmin.php
> ..
>> +require_once dirname(__FILE__)."/../../env.inc.php";
>> +require_once $gfwww.'include/pre.php';
> 
> This might be useful for gforge, but is not save for phpwiki to
> install in general.
> ../../env.inc.php might be any path which we are not allowed to use.
> 
> - Cannot this be moved to a .htaccess protected path?
> - Can it be made downloadable extra for GForge users?
> 
> We cannot ship this here in the default tar.gz.
Hello Reini,
This was already true before with the file "g" that is the main entry
point for Phpwiki in Gforge and has the same includes.
The simplest way is to not ship these files in Phpwiki
and to ship them with Gforge/Fusionforge.
How can we coordinate to ship Phpwiki 1.4.0RC as soon as
possible? I still have some questions to be answered
before releasing it.
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...

2010年5月4日 <var...@us...>:
> Revision: 7378
>     http://phpwiki.svn.sourceforge.net/phpwiki/?rev=7378&view=rev
> Author:  vargenau
> Date:   2010年05月04日 13:49:26 +0000 (2010年5月04日)
>
> Log Message:
> -----------
> Add Gforge Wiki Configurator
>
> Added Paths:
> -----------
>  trunk/wikiadmin.php
..
> +require_once dirname(__FILE__)."/../../env.inc.php";
> +require_once $gfwww.'include/pre.php';
This might be useful for gforge, but is not save for phpwiki to
install in general.
../../env.inc.php might be any path which we are not allowed to use.
- Cannot this be moved to a .htaccess protected path?
- Can it be made downloadable extra for GForge users?
We cannot ship this here in the default tar.gz.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/