Menu
▾
▴
phpwiki-talk
|
From: Reini U. <ru...@x-...> - 2005-06-21 05:48:19
|
Perry Lorier schrieb: > Hi! We're from the WLUG Wiki, and are mostly the people that run and > maintain the WLUG Wiki. We're keen on merging our code base upstream so > we can end up running the most recent version of the software, and so we > can contribute to the maintree our (numerous!) local changes. > > However we've had a lot of trouble upgrading to the latest versions. For > instance, we support IPv6 throughout, and the latest versions have a > field in the database for an IP address which is only 15 charactors > long, where IPv6 addresses can be (and surprisingly often are) 39 > charactors long. Ok, will be fixed in CVS. Thanks for the hint. What else? > We're keen to work with some phpwiki developer(s) (which at the moment > appears to be you) to add our features upstream, and fix the problems we > were having upgrading. Are you keen on working on this with us? or can > you point us at someone who is? Sure. phpwiki-talk is good for talking about patches and problems. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Perry L. <pe...@co...> - 2005-06-21 10:04:30
|
Reini Urban wrote: Thanks for the reply, I see you've added the list so I'll reply to "everyone" :) The "WLUG Wiki" I'm talking about is http://www.wlug.org.nz/ which is a an old version of phpwiki that we have hacked at now for a couple of years. Some of our features have been merged upstream (eg, utf8 support). Some of upstreams features have been back ported (eg bug fixes to NewMarkup). > Perry Lorier schrieb: > >> Hi! We're from the WLUG Wiki, and are mostly the people that run and >> maintain the WLUG Wiki. We're keen on merging our code base upstream >> so we can end up running the most recent version of the software, and >> so we can contribute to the maintree our (numerous!) local changes. >> >> However we've had a lot of trouble upgrading to the latest versions. >> For instance, we support IPv6 throughout, and the latest versions have >> a field in the database for an IP address which is only 15 charactors >> long, where IPv6 addresses can be (and surprisingly often are) 39 >> charactors long. > > > Ok, will be fixed in CVS. Thanks for the hint. > What else? We couldn't get BogoLogin to ever direct you to a login page. With our current version if you aren't logged in and you attempt to edit a page you get taken to a page that asks you for your username, you enter it, and then it continues with whichever action you needed to be logged in for. The version we were trying with would return with "You are not logged in". This I think was the major problem that prevented us migrating last time we tried (all the other problems we solved one way or another). The database upgrade wasn't smooth, although we attribute this to us using a "beta" CVS version. We ended up doing the database migration by hand -- it wasn't hard once we figured out what was going on. We're just about to try again and see how far we can get. We'll be sure to let everyone know of our progress. >> We're keen to work with some phpwiki developer(s) (which at the moment >> appears to be you) to add our features upstream, and fix the problems >> we were having upgrading. Are you keen on working on this with us? or >> can you point us at someone who is? > > Sure. > phpwiki-talk is good for talking about patches and problems. Cool. I didn't realise that any of the lists were still active. Subscribed. A (non comprehensive/slightly out of date) list of our changes can be seen at http://www.wlug.org.nz/WlugWikiConversion#hdr_modifications_we_have_made If anyone's keen on seeing how we did things a current tarball is available at http://www.wlug.org.nz/archive/phpwiki-20050621.tar.gz feel free to poach ideas (esp if you split them out to patches to commit upstream!) We hope to split out patches to merge upstream ourselves eventually. |
|
From: Matt B. <ma...@ma...> - 2005-06-21 22:34:51
|
Hi everyone,=20
On Tue, 2005-06-21 at 22:04 +1200, Perry Lorier wrote:
> We're just about to try again and see how far we can get. We'll be sure
> to let everyone know of our progress.
OK. My first attempt at doing this was going to take the following form
1) Install vanilla phpwiki 1.3.11_rc3
2) Export (zip dump) from current WLUG wiki
3) Import via zip dump into phpwiki 1.3.11_rc3
4) Attempt to port all our modifications / plugins forward to 1.3.11_rc3
such that they are in a state to be potentially forwarded upstream.=20
I've run into a few problems however.=20
I'm doing all of the following on a Debian Sarge system using the
packaged Apache2 and PHP4 binaries.=20
* To get phpwiki to run, I had to modify my include path to point
directly to the PEAR dir inside the phpwiki source. Not doing this
caused an error about a redeclared DB class, presumably a conflict
between my system PEAR and phpwiki's PEAR. Is this a known problem on
Debian Sarge?
* Database logging doesn't work with postgresql (due to use of the
DELAYED keyword which is only supported by MySQL) and we don't want it
anyway. However there doesn't appear to be any way to disable this by
default. The logical action to my mind would be to set ACCESS_LOG_SQL=3D0
in config.ini, however the IniConfig parser appears to set all
uninitialised variables in the config file to 0 which then leads to
ACCESS_LOG_SQL being set to it's default value of 2. To get around this
I have created the patch below which allows the user to specify
ACCESS_LOG_SQL=3D-1 in config.ini to prevent database logging
--- phpwiki-1.3.11/lib/IniConfig.php 2005-04-09 06:11:50.000000000
+1200
+++ phpwiki/lib/IniConfig.php 2005-06-21 23:48:19.000000000 +1200
@@ -383,6 +383,8 @@
if (!empty($rs['ACCESS_LOG_SQL'])) {
if (!in_array(DATABASE_TYPE, array('SQL','ADODB')))
define('ACCESS_LOG_SQL', 0);
+ if ($rs['ACCESS_LOG_SQL']=3D=3D-1)
+ define('ACCESS_LOG_SQL', 0);
}
// SQL defaults to ACCESS_LOG_SQL =3D 2
else {
* Using precached HTML (WIKIDB_NOCACHE_MARKUP) results in errors of the
following type when I try and view any page in the wiki
Fatal Error:
lib/WikiDB/backend/PearDB.php:1014: Error: wikidb_backend_peardb_pgsql:
fatal database error=20
* DB Error: unknown error
* (UPDATE page SET cached_html=3D'x=C3=9A=C2=9D=E2=80=9D=C3=8Fn=C3=9B=
0=0C=C3=86=C3=AF}
* A=0F=C2=B0Z=C3=8E=C2=BFV=C3=892d=1B=E2=80=A0=1D=C2=B65H=C2=B7=C3=B6=
=18(6=1B=13=C2=B5%CR=C5=A1=14E=C3=9E}=E2=80=9Dlg;=C3=9A=3D
$=E2=82=AC-=C5=A1=C3=BC=C3=B1=C3=A3''=C3=9EI1=E2=80=98=C3=9C[=C2=A5=
=C3=9D=E2=80=9C=C2=B1=15=C3=A4=1EN=C5=BE=C3=8B=E2=80=98|s=E2=80=99=0E=C2=B6=
=C3=BE=C2=B5=06>=C2=BF=E2=80=9Cb&y=C2=AD=C3=B6=10=C5=BE=C2=B7G|=C3=86&.=E2=
=80=98og''o)p=C2=A7=1C
To make the wiki work I have to set WIKIDB_NOCACHE_MARKUP =3D true in
config.ini. This looks like phpwiki is trying to insert bogus values
into the HTML cache.=20
* My first attempt at importing from the zip dump didn't succeed. Lots
of errors were encountered regarding diff merging between page
revisions. This resulted in only the very first revision (ie, not what
is currently displayed in the WLUG wiki) being imported into my new
wiki.=20
Any help with these above problems would be much appreciated and would
help us in our quest to get more in line with upstream PHPwiki.=20
Kind Regards
--=20
Matt Brown
ma...@ma...
Mob +64 275 611 544 www.mattb.net.nz
|
|
From: Reini U. <ru...@x-...> - 2005-06-22 09:24:11
|
> OK. My first attempt at doing this was going to take the following form > > 1) Install vanilla phpwiki 1.3.11_rc3 > 2) Export (zip dump) from current WLUG wiki > 3) Import via zip dump into phpwiki 1.3.11_rc3 > 4) Attempt to port all our modifications / plugins forward to 1.3.11_rc3 > such that they are in a state to be potentially forwarded upstream. good, just CVS HEAD would be better. > I've run into a few problems however. > > I'm doing all of the following on a Debian Sarge system using the > packaged Apache2 and PHP4 binaries. > > * To get phpwiki to run, I had to modify my include path to point > directly to the PEAR dir inside the phpwiki source. Not doing this > caused an error about a redeclared DB class, presumably a conflict > between my system PEAR and phpwiki's PEAR. Is this a known problem on > Debian Sarge? I don't know for Debian, because we don't care for specific distros, but if the installed system pear DB is too old it is recommended to use ours. There's no way to check the version number beforehand. pear is not well designed. > * Database logging doesn't work with postgresql (due to use of the > DELAYED keyword which is only supported by MySQL) and we don't want it > anyway. This was fixed some weeks ago. Please try current CVS instead or the nightly snapshot from the webpage. > However there doesn't appear to be any way to disable this by > default. The logical action to my mind would be to set ACCESS_LOG_SQL=0 > in config.ini, however the IniConfig parser appears to set all > uninitialised variables in the config file to 0 which then leads to > ACCESS_LOG_SQL being set to it's default value of 2. To get around this > I have created the patch below which allows the user to specify > ACCESS_LOG_SQL=-1 in config.ini to prevent database logging Oops, I'll check why ACCESS_LOG_SQL=0 fails for you. This should not happen. > * Using precached HTML (WIKIDB_NOCACHE_MARKUP) results in errors of the > following type when I try and view any page in the wiki > > Fatal Error: > lib/WikiDB/backend/PearDB.php:1014: Error: wikidb_backend_peardb_pgsql: > fatal database error > > * DB Error: unknown error > * (UPDATE page SET cached_html='xÃÂâÃnÃ0 Ãï} > * A°ZÿVÃ2dâ ¶5H·ö(6µ%CRÅ¡EÃ}âlg;à > $â¬-šüñã''ÃI1âÃ[Â¥Ãâ±ä NžÃâ|sâ¶þµ>¿âb&yÂöž·G|Ã&.âog''o)p§ > > To make the wiki work I have to set WIKIDB_NOCACHE_MARKUP = true in > config.ini. This looks like phpwiki is trying to insert bogus values > into the HTML cache. cached_html is gzipped. So postgresql has problems with binary data. I'll fix that. > * My first attempt at importing from the zip dump didn't succeed. Lots > of errors were encountered regarding diff merging between page > revisions. This resulted in only the very first revision (ie, not what > is currently displayed in the WLUG wiki) being imported into my new > wiki. These are just warnings. Diff merging is not too clever. You may want to overwrite all or merge manually. We just provide the basic docs and needed action pages so normally it's safe to overwrite all. Just the HomePage should be merged. -- Reini Urban http://phpwiki.org/ http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Reini U. <ru...@x-...> - 2005-07-01 05:23:46
|
Reini Urban schrieb: >>* Using precached HTML (WIKIDB_NOCACHE_MARKUP) results in errors of the >>following type when I try and view any page in the wiki >> >>Fatal Error: >>lib/WikiDB/backend/PearDB.php:1014: Error: wikidb_backend_peardb_pgsql: >>fatal database error >> >> * DB Error: unknown error >> * (UPDATE page SET cached_html='xÚÂâ€ÃnÛ0 Æï} >> * A°ZοVÉ2d†¶5H·ö(6µ%CRÅ¡EÞ}â€lg;Ú >>$€-šüñã''ÞI1‘Ü[¥Ó±ä NžË‘|s’¶þµ>¿“b&yÂöž·G|Æ&.‘og''o)p§ >> >>To make the wiki work I have to set WIKIDB_NOCACHE_MARKUP = true in >>config.ini. This looks like phpwiki is trying to insert bogus values >>into the HTML cache. I've found the PEAR pgsql problem. PEAR DB does not escape binary data with pg_escape_string(). I've checked in a fix. I believe ADODB does that right - at least it uses pg_escape_string(), but haven't tested that yet. > cached_html is gzipped. > So postgresql has problems with binary data. I'll fix that. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Reini U. <ru...@x-...> - 2005-06-22 17:19:48
|
Perry Lorier schrieb: > A (non comprehensive/slightly out of date) list of our changes can be > seen at > http://www.wlug.org.nz/WlugWikiConversion#hdr_modifications_we_have_made > > We hope to split out patches to merge upstream ourselves > eventually. I love this diff: http://www.wlug.org.nz/WlugWikiConversion?action=diff "... the committee has decided not to pursue the MediaWiki option further at this time ... " "The remainder of this page remains for hysterical reference." The last time I merged wlug upstream (2003-01-07) I used your soap support and I tried the GoogleGreeting (I like it) and the ExternalReferrers idea, but didn't succeeded yet properly. postgresql is very important to be improved. Thanksfully you use it in production. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Matt B. <ma...@ma...> - 2005-06-22 10:27:23
|
On Wed, 2005-06-22 at 11:24 +0200, Reini Urban wrote:
> good, just CVS HEAD would be better.
OK. I can do that.
> I don't know for Debian, because we don't care for specific distros, but
> if the installed system pear DB is too old it is recommended to use ours.
> There's no way to check the version number beforehand. pear is not well
> designed.
Heh, well we'll blame Debian for now and I'll keep my custom include
path, that seems to work fine.
> This was fixed some weeks ago. Please try current CVS instead or the
> nightly snapshot from the webpage.
Pleased to confirm CVS HEAD logs to postgres fine.
> Oops, I'll check why ACCESS_LOG_SQL=0 fails for you.
> This should not happen.
Appreciated :)
> cached_html is gzipped.
> So postgresql has problems with binary data. I'll fix that.
Cool.
> These are just warnings. Diff merging is not too clever.
> You may want to overwrite all or merge manually.
> We just provide the basic docs and needed action pages so normally
> it's safe to overwrite all. Just the HomePage should be merged.
Hmm, they seem like more than warnings. Examples pasted below
AFSNotes
from MIME file AFSNotes content is identical to current version 1 - no new revision created
AFSNotes
from MIME file AFSNotes has edit conflicts - skipped Sorry, cannot merge.
AFSNotes
from MIME file AFSNotes has edit conflicts - skipped Sorry, cannot merge.
AFSNotes
from MIME file AFSNotes has edit conflicts - skipped Sorry, cannot merge.
AFSNotes
from MIME file AFSNotes has edit conflicts - skipped Sorry, cannot merge.
AFSNotes
from MIME file AFSNotes has edit conflicts - skipped Sorry, cannot merge.
AFSNotes
from MIME file AFSNotes has edit conflicts - skipped Sorry, cannot merge.
AFSNotes
from MIME file AFSNotes has edit conflicts - skipped Sorry, cannot merge.
>From the page history on www.wlug.org.nz/AFSNotes you can see that there
are 8 versions currently in the wiki. Exporting to zip dump and then
importing into my test wiki only generates the first revision and the
errors above.
Are you saying that the zip dump method isn't able to import the page history correctly?
Is there a better way to do this? I might try a direct database dump /
import, but I thought the database fields had changed which might cause
problems?
Thanks for your help.
Kind Regards
--
Matt Brown
ma...@ma...
Mob +64 275 611 544 www.mattb.net.nz
|
|
From: Matt B. <ma...@ma...> - 2005-06-22 12:18:17
|
On Wed, 2005-06-22 at 22:26 +1200, Matt Brown wrote: > Is there a better way to do this? I might try a direct database dump / > import, but I thought the database fields had changed which might cause > problems? Hate to reply to myself, but I found a way to successfully import the data. pg_dump -a -dD -O wiki > wiki-mattb.sql Where wiki was the name of the database all the current wiki data is in. The -dD flags are important as it enables output of the column names. This avoids triggering an error on the import into the page table as there is a new column there. It's very very slow to import the 3000+ pages we have via this method, but it worked :) Now on to porting all our other changes up to HEAD. Regards -- Matt Brown ma...@ma... Mob +64 275 611 544 www.mattb.net.nz |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X