phpwiki-talk Mailing List for PhpWiki (Page 15)

Reini Urban a écrit :
> Marc-Etienne Vargenau schrieb:
>> Update of /cvsroot/phpwiki/phpwiki/themes/wikilens/pgsrc
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31755/wikilens/pgsrc
>>
>> Log Message:
>> Directory /cvsroot/phpwiki/phpwiki/themes/wikilens/pgsrc added to the repository
> 
> I have removed all of these empty and optional theme pgsrc dirs.
> If there's some code failing, fix the function instead.
Hello Reini,
No problem. I had added them because I got a warning.
Regards,
Marc-Etienne
-- 
================================================================== ------
| Marc-Etienne Vargenau | / \
| Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE | / /|'` \
| +33 (0)1 30 77 28 33, Mar...@al... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

Marc-Etienne Vargenau schrieb:
> Update of /cvsroot/phpwiki/phpwiki/themes/wikilens/pgsrc
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31755/wikilens/pgsrc
> 
> Log Message:
> Directory /cvsroot/phpwiki/phpwiki/themes/wikilens/pgsrc added to the repository
I have removed all of these empty and optional theme pgsrc dirs.
If there's some code failing, fix the function instead.
wikilens and MonoBook are actually themes where such pages could be 
actually added.
MonoBook needs a Template/Talk
wikilens needs a LeftbarContent
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Sabri LABBENE a écrit :
> Reini Urban wrote:
> [...]
>> There are currently 4 branches besides trunk.
>>
>> release-1_2-branch/ 	 (active for 1.2.x)
>> jeffs_hacks-branch/ 	 (closed, the beginning of 1.3.x)
>> release-1_2_4/ 	 (a mistake, will be deleted)
>> wikiteam/ (some very early 1.03 refactoring)
> 
> On which branch sould we contribute if any ?
trunk
Marc-Etienne
-- 
================================================================== ------
| Marc-Etienne Vargenau | / \
| Alcatel-Lucent France, Route de Villejust, 91620 NOZAY, FRANCE | / /|'` \
| +33 (0)1 30 77 28 33, Mar...@al... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

Reini Urban wrote:
[...]
>There are currently 4 branches besides trunk.
>
>release-1_2-branch/ 	 (active for 1.2.x)
>jeffs_hacks-branch/ 	 (closed, the beginning of 1.3.x)
>release-1_2_4/ 	 (a mistake, will be deleted)
>wikiteam/ (some very early 1.03 refactoring)
On which branch sould we contribute if any ?
Thanks,
-- Sabri.

Marc-Etienne wrote:
>Reini Urban a écrit :
>> 
>> The conversion from CVS to SVN is finished. Please do not commit 
>> anything to CVS anymore.
>
>Hello Reini,
>
>This is really great. Thank you very much.
>
>I just made my first check-in in Subversion from work.
Me too.
Thanks Reini !
-- Sabri.

Reini Urban a écrit :
> 
> The conversion from CVS to SVN is finished. Please do not commit
> anything to CVS anymore.
Hello Reini,
This is really great. Thank you very much.
I just made my first check-in in Subversion from work.
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... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

2008年8月21日 Reini Urban <ru...@x-...>:
> 2008年8月21日 Reini Urban <ru...@x-...>:
>> We are in the preparation for the next release 1.3.15 (planned for
>> about middle to end of september)
>> and before we will do the following steps:
>>
>> * Convert the sf.net CVS repo to SVN.
>> This works now elegantly because sf.net provides rsync access to the CVSROOT.
>> This enables vargenau and rurban to commit / sync from work behind a
>> http proxy.
>> Before we had to take back or changes home and commit / sync from home.
>
> I want to do this now, so please stop changing anything in CVS, as
> this will get lost.
> I'll announce when svn will be ready.
The conversion from CVS to SVN is finished. Please do not commit
anything to CVS anymore.
Info:
https://sourceforge.net/svn/?group_id=6121
Browse:
http://phpwiki.svn.sourceforge.net/viewvc/phpwiki/
Checkout read-only:
svn co https://phpwiki.svn.sourceforge.net/svnroot/phpwiki phpwiki
Checkout read-write to phpwiki-svn:
svn co --username rurban
https://phpwiki.svn.sourceforge.net/svnroot/phpwiki phpwiki-svn
> BTW: The new tools will go to the old admin dir. We already had a
> bunch of 1.2.x utils there for the same purpose. I'll do that during the import
Done.
There are currently 4 branches besides trunk.
release-1_2-branch/ 	 (active for 1.2.x)
jeffs_hacks-branch/ 	 (closed, the beginning of 1.3.x)
release-1_2_4/ 	 (a mistake, will be deleted)
wikiteam/ (some very early 1.03 refactoring)
Maybe we will be tempted to start some db and template_lite
refactoring (a la wikilens)
in new branches.
Issues:
On cygwin (1.5 and 1.7 also) the initial checkout misses some overlong
russian filenames in the old 1.2 branch.
svn: Can't open file 'phpwiki-svn/branches/release-1_2-branch/locale/ru/pgsrc/.s
vn/tmp/text-base/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%D0A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%B0.svn-base':
File name too long
svn: Can't open file
'phpwiki-svn/branches/release-1_2-branch/locale/ru/pgsrc/.svn/tmp/text-base/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%B0.svn-base':
File name too long
svn: Can't open file 'phpwiki-svn/branches/release-1_2-branch/locale/ru/pgsrc/.s
vn/tmp/text-base/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%D0A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%B0.svn-base':
File name too long
svn: Can't open file 'phpwiki-svn/branches/release-1_2-branch/locale/ru/pgsrc/.s
vn/tmp/text-base/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%B0.svn-base':
File name too long
svn: Can't open file 'phpwiki-svn/branches/release-1_2-branch/locale/ru/pgsrc/.s
vn/tmp/text-base/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%B0.svn-base':
File name too long
svn: Can't open file 'phpwiki-svn/branches/release-1_2-branch/locale/ru/pgsrc/.s
vn/tmp/text-base/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%A2%D0%B5%D0%BA%D1%81%D1%82%D0%B0.svn-base':
File name too long
On Cygwin 1.7 at least the trunk checks out fine.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

2008年8月21日 Reini Urban <ru...@x-...>:
> We are in the preparation for the next release 1.3.15 (planned for
> about middle to end of september)
> and before we will do the following steps:
>
> * Convert the sf.net CVS repo to SVN.
> This works now elegantly because sf.net provides rsync access to the CVSROOT.
> This enables vargenau and rurban to commit / sync from work behind a
> http proxy.
> Before we had to take back or changes home and commit / sync from home.
I want to do this now, so please stop changing anything in CVS, as
this will get lost.
I'll announce when svn will be ready.
BTW: The new tools will go to the old admin dir. We already had a
bunch of 1.2.x utils
there for the same purpose. I'll do that during the import
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Reini Urban a écrit :
> We are in the preparation for the next release 1.3.15 (planned for
> about middle to end of september)
> and before we will do the following steps:
> 
> * Check and finish Wikicreole integration.
Hello,
I have committed all of my Wikicreole work now, except the new
CreateToc plugin that accepts the Wikicreole headers. Will be
done soon.
It needs some serious testing.
Current status, in the order of the Wikicreole 1.0 spec:
**bold** and //italics//: not done. Can't find the right regexp.
headings: fully implemented "==" to "====="
works with Mediawiki syntax (optional '='s at the end of line)
In the spec, the parsing of headers is "optional".
I have implemented parsing of headers.
links: fully implemented; extra ']' displayed (should be easy
to fix)
paragraphs: of course :-)
line breaks: fully implemented
unordered lists: implemented, no change from classic Phpwiki
ordered lists: implemented but wrong numbering, no change
from classic Phpwiki
horizontal rule: implemented, no change from classic Phpwiki
inline image: implemented (experimental)
alt is implemented
activated only if ENABLE_MARKUP_TEMPLATE is true
this in almost the same syntax as Mediawiki templates that
were already present in Phpwiki.
I have done the following:
{{foo}} and {{foo|bar=xxx}} are treated as templates
{{foo.png}} and {{foo.png|bar}} are treated as Wikicreole
images because of the '.png' suffix.
The allowed suffixes are: .png, .jpg, .jpeg, .gif
tables:
completely implemented when used with an explicit plugin
call
works without explicit plugin call only if table is
followed by '?>'
we have to find the right regexp to end a table
(first line where the first non-space character is
not a pipe?)
Preformatted: implemented
does not work when there is an empty line between {{{
and }}}
Escape character: implemented, no change from classic Phpwiki
Creole additions
Plug-in: not done
Monospace and superscript: not done. Can't find the right regexp.
Subscript: implemented
Underline: conflicts with Phpwiki old syntax
Please test and give your feedback.
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... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

Sabri LABBENE a écrit :
> 
> Still another issue in TOC titles.
> When you try to escape a wikiword in a heading title, the "~" char will 
> be displayed in the title inside the TOC.
Hello,
The problem is even worse than that. See Help page.
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... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

We are in the preparation for the next release 1.3.15 (planned for
about middle to end of september)
and before we will do the following steps:
* Convert the sf.net CVS repo to SVN.
This works now elegantly because sf.net provides rsync access to the CVSROOT.
This enables vargenau and rurban to commit / sync from work behind a
http proxy.
Before we had to take back or changes home and commit / sync from home.
* Add a tools directory for external tools, like an open office
converter, MS office converters,
daily backup cronjob scripts, db repair helpers, fixperms.sh,
passencrypt.php and such.
* Check and finish Wikicreole integration.
* Check the new EditToolbar features, and there are still some missing.
* Replace the Sidebar theme with a new one, based on MonoBook.
 i.e. merge the AVL theme (internal MonoBook derivate with
customizable box states) with Sidebar
* fix postgresql
* Rename should check existing subpages and rename these also.
* clarify issues with pagenames: "," breaks PageList. Escape with "~" or "\"?
* fix Wikiwys with prettyurl, link labels and killing plugin args.
/blank.htm should be properly relative.
* check if session php-5.2 is fixed
Other tasks which will probably not get finished in time are:
* phpwiki.org: enable 1.3.15 on sf.net with wiki//index.php/urls
* more meta stuff: OpenSearch, format=dc (Dublin Core)
* format=mm (FreeMind) for RecentChanges, SemanticWeb's and simple PageList's.
 See http://wikkawiki.org/FreeMind. Maybe format=mmap for the
commercial MindMap.
* format=printable (?) for non js/dom
* WatchList (?)
* ImportMediaWiki, ImportRdf, ImportOwl, ExportMediaWiki, ExportRdf, ExportOwl
* WikiUser/OpenID (from DokuWiki) - Status::in_work
* GeSHi Highlighter plugin
* Spellcheck AJAX backend (see DokuWiki)
Contributors welcome.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

On Wed, Aug 20, 2008 at 2:41 PM, Sabri LABBENE <sab...@gm...>wrote:
>
>
> On Wed, Aug 20, 2008 at 1:58 PM, Marc-Etienne Vargenau <
> Mar...@al...> wrote:
>
>> Sabri LABBENE a écrit :
>> > Marc-Etienne Vargenau wrote:
>> >> The numbering bug is corrected.
>> >>
>> >> // $Log: CreateToc.php,v $
>> >> // Revision 1.43 2008年08月19日 18:29:12 vargenau // Correct TOC
>> >> numbering
>> >
>> > Oh! Good catch !
>> > Thanks for the fix.
>> >
>> >> I have also added letter and roman numbering. Enjoy!
>> >
>> > And how we use them (letters and roman numbers) ?
>> > May be it's a good idea to update the help page :)
>>
>> Hello Sabri,
>>
>> In fact I updated the documentation before I released
>> the code :-)
>>
>>
>> http://phpwiki.cvs.sourceforge.net/phpwiki/phpwiki/pgsrc/Help%252FCreateTocPlugin?r1=1.5&r2=1.6
>>
>> Great !
>
Still another issue in TOC titles.
When you try to escape a wikiword in a heading title, the "~" char will be
displayed in the title inside the TOC.
Cheers,
-- Sabri.

On Wed, Aug 20, 2008 at 1:58 PM, Marc-Etienne Vargenau <
Mar...@al...> wrote:
> Sabri LABBENE a écrit :
> > Marc-Etienne Vargenau wrote:
> >> The numbering bug is corrected.
> >>
> >> // $Log: CreateToc.php,v $
> >> // Revision 1.43 2008年08月19日 18:29:12 vargenau // Correct TOC
> >> numbering
> >
> > Oh! Good catch !
> > Thanks for the fix.
> >
> >> I have also added letter and roman numbering. Enjoy!
> >
> > And how we use them (letters and roman numbers) ?
> > May be it's a good idea to update the help page :)
>
> Hello Sabri,
>
> In fact I updated the documentation before I released
> the code :-)
>
>
> http://phpwiki.cvs.sourceforge.net/phpwiki/phpwiki/pgsrc/Help%252FCreateTocPlugin?r1=1.5&r2=1.6
>
> Great !
Thanks,
-- Sabri.

Sabri LABBENE a écrit :
> Marc-Etienne Vargenau wrote:
>> The numbering bug is corrected.
>>
>> // $Log: CreateToc.php,v $
>> // Revision 1.43 2008年08月19日 18:29:12 vargenau // Correct TOC 
>> numbering
> 
> Oh! Good catch !
> Thanks for the fix.
> 
>> I have also added letter and roman numbering. Enjoy!
> 
> And how we use them (letters and roman numbers) ?
> May be it’s a good idea to update the help page :)
Hello Sabri,
In fact I updated the documentation before I released
the code :-)
http://phpwiki.cvs.sourceforge.net/phpwiki/phpwiki/pgsrc/Help%252FCreateTocPlugin?r1=1.5&r2=1.6
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... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

Marc-Etienne Vargenau wrote:
>Sabri LABBENE a écrit :
>> Marc-Etienne Vrgenau a écrit : 
>> I am currently working on CreateToc plugin so that the
>> Wikicreole headers are taken into account.
>> 
>> While you're in, could you please check if there is 
>something wrong in 
>> numbering code! There is a bug in CreateToc plugin 
>numbering. I can't 
>> find the exact scenario to reproduce it. What is happening is that 
>> top level sections numbers are sometimes like X.X while they 
>should be X.
>> I didn't tried the new creole markup yet. I use '!' for headings.
>
>Hello Sabri,
>
>The numbering bug is corrected.
>
>// $Log: CreateToc.php,v $
>// Revision 1.43 2008年08月19日 18:29:12 vargenau // Correct TOC 
>numbering
Oh! Good catch !
Thanks for the fix.
>I have also added letter and roman numbering. Enjoy!
And how we use them (letters and roman numbers) ?
May be it’s a good idea to update the help page :)
Best Regards,
-- Sabri.

Sabri LABBENE a écrit :
> Marc-Etienne Vrgenau a écrit : 
> I am currently working on CreateToc plugin so that the
> Wikicreole headers are taken into account.
> 
> While you're in, could you please check if there is something wrong in 
> numbering code! There is a bug in CreateToc plugin numbering. I can't 
> find the exact scenario to reproduce it. What is happening is that top 
> level sections numbers are sometimes like X.X while they should be X.
> I didn't tried the new creole markup yet. I use '!' for headings.
Hello Sabri,
The numbering bug is corrected.
// $Log: CreateToc.php,v $
// Revision 1.43 2008年08月19日 18:29:12 vargenau
// Correct TOC numbering
I have also added letter and roman numbering. Enjoy!
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... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

Reini Urban a écrit :
> Marc-Etienne Vargenau schrieb:
>> Update of /cvsroot/phpwiki/phpwiki/lib
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8075
>>
>> Modified Files:
>> 	InlineParser.php 
>> Log Message:
>> Implemented Wikicreole syntax for preformatted text
> 
> We should add all Wikicreole syntax extensions behind 
> ENABLE_MARKUP_WIKICREOLE and make it default = true.
Hello Reini,
How should this be done in such a code:
class Markup_linebreak extends SimpleMarkup
{
 var $_match_regexp = "(?: (?<! %) %%% (?! %) | \\\\\\\\ | <(?:br|BR)> )";
 function markup ($match) {
 return HTML::br();
 }
}
i.e. to differentiate between
"(?: (?<! %) %%% (?! %) | \\\\\\\\ | <(?:br|BR)> )"
and
"(?: (?<! %) %%% (?! %) | <(?:br|BR)> )"
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... | | /'| ' |
================================================================== \ |/ /
| L'essence des Mathématiques est dans leur liberté. | \ /
| Georges Cantor | ------
==================================================================

Marc-Etienne Vargenau schrieb:
> Update of /cvsroot/phpwiki/phpwiki/lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8075
> 
> Modified Files:
> 	InlineParser.php 
> Log Message:
> Implemented Wikicreole syntax for preformatted text
We should add all Wikicreole syntax extensions behind 
ENABLE_MARKUP_WIKICREOLE and make it default = true.
> if (ENABLE_MARKUP_COLOR and !$non_default)
> $this->_addMarkup(new Markup_color);
> + // Markup_wikicreole_preformatted must be before Markup_template_plugin
> + $this->_addMarkup(new Markup_wikicreole_preformatted);
> if (ENABLE_MARKUP_TEMPLATE and !$non_default)
> $this->_addMarkup(new Markup_template_plugin);
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Am Donnerstag 14 August 2008 schrieb Reini Urban:
>
> Until I can fix that, can you try the other DATABASE_TYPE = ADODB
> I'm mainly working with ADODB, and backport changes after a while to
> the more stable SQL with the PearDB backend.
>
> The constraint is question is CHECK (latestminor >= latestmajor).
> Maybe you should disable this constraint, but first I want to reproduce
> and debug that.
>
> Which postgresql version exactly?
> I use 7.4.19, 8.2.9 and 8.3.3, but only occasionally.
Reini,
thanks for the quick answer.
I'm using a debian Etch server still running "Postgresql 7.4.17".
I want to avoid to install more software-packages on this machine, just to 
keep the installed software-base low. But if this is the way to go, I 
have to think of it. But as edits in the wiki are made mostly by myself 
it's not so urgent to solve this error.
Please let me know if I can support you in debugging by by providing 
informations or anything else.
REgards Sven

Sven Roederer schrieb:
> Hi,
> 
> I started using phpwiki some years ago, as it was the first system which I 
> easily integrated into my running software (LDAP-auth; Postgres).
> Some months ago (in 2007) I upgraded to version 1.3.14, according to the 
> steps in the manual.
> In case I remember correctly since this upgrade I've some trouble with 
> editing some pages of the wiki.
> My problem is the following:
> The not working pages behaves 
> as "https://www.roederer.dhs.org/wiki/index.php/EinkaufsListe" 
> (https://www.roederer.dhs.org/wiki/index.php/Knowledge
> is a working page). I can only save edits of this page when they are 
> marked as "minor change". When this marking is not done (automatically or 
> manually) I get the following error-msg:
> -----------------------------------------------------------------------------
> Fatal Error:
> lib/WikiDB/backend/PearDB.php:1059 Error: wikidb_backend_peardb_pgsql: 
> fatal database error 
> DB Error: constraint violation
> (INSERT INTO recent (id, latestversion, latestmajor, latestminor) SELECT 
> id, MAX(version), MAX(CASE WHEN minor_edit=0 THEN version END), MAX(CASE 
> WHEN minor_edit<>0 THEN version END) FROM version WHERE id=553 GROUP BY 
> id [nativecode=ERROR: new row for relation "recent" violates check 
> constraint "1ドル"])
> 
> Fatal PhpWiki Error
> lib/WikiDB/backend/PearDB.php:1059 Error: wikidb_backend_peardb_pgsql: 
> fatal database error 
> DB Error: constraint violation
> (INSERT INTO recent (id, latestversion, latestmajor, latestminor) SELECT 
> id, MAX(version), MAX(CASE WHEN minor_edit=0 THEN version END), MAX(CASE 
> WHEN minor_edit<>0 THEN version END) FROM version WHERE id=553 GROUP BY 
> id [nativecode=ERROR: new row for relation "recent" violates check 
> constraint "1ドル"])
> -----------------------------------------------------------------------------
> 
> As written by the databse-engine, there is a constraint violation. 
> 
> Can anyone give me a hint how to fix this? As I'm not familar with the 
> internal database-organization.
> 
> Kind regards 
> Sven
Hi Sven,
This is clearly an error with the very new postgresql schema.
I just looked and it looks like that all the new stricter checks and 
optimizations features for postgresql are not yet enabled in the release
and the page save method (set_versiondata) is using the generic version.
Until I can fix that, can you try the other DATABASE_TYPE = ADODB
I'm mainly working with ADODB, and backport changes after a while to the 
more stable SQL with the PearDB backend.
The constraint is question is CHECK (latestminor >= latestmajor).
Maybe you should disable this constraint, but first I want to reproduce 
and debug that.
Which postgresql version exactly?
I use 7.4.19, 8.2.9 and 8.3.3, but only occasionally.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Hi,
I started using phpwiki some years ago, as it was the first system which I 
easily integrated into my running software (LDAP-auth; Postgres).
Some months ago (in 2007) I upgraded to version 1.3.14, according to the 
steps in the manual.
In case I remember correctly since this upgrade I've some trouble with 
editing some pages of the wiki.
My problem is the following:
The not working pages behaves 
as "https://www.roederer.dhs.org/wiki/index.php/EinkaufsListe" 
(https://www.roederer.dhs.org/wiki/index.php/Knowledge
 is a working page). I can only save edits of this page when they are 
marked as "minor change". When this marking is not done (automatically or 
manually) I get the following error-msg:
-----------------------------------------------------------------------------
Fatal Error:
lib/WikiDB/backend/PearDB.php:1059 Error: wikidb_backend_peardb_pgsql: 
fatal database error 
 DB Error: constraint violation
 (INSERT INTO recent (id, latestversion, latestmajor, latestminor) SELECT 
id, MAX(version), MAX(CASE WHEN minor_edit=0 THEN version END), MAX(CASE 
WHEN minor_edit<>0 THEN version END) FROM version WHERE id=553 GROUP BY 
id [nativecode=ERROR: new row for relation "recent" violates check 
constraint "1ドル"])
Fatal PhpWiki Error
lib/WikiDB/backend/PearDB.php:1059 Error: wikidb_backend_peardb_pgsql: 
fatal database error 
 DB Error: constraint violation
 (INSERT INTO recent (id, latestversion, latestmajor, latestminor) SELECT 
id, MAX(version), MAX(CASE WHEN minor_edit=0 THEN version END), MAX(CASE 
WHEN minor_edit<>0 THEN version END) FROM version WHERE id=553 GROUP BY 
id [nativecode=ERROR: new row for relation "recent" violates check 
constraint "1ドル"])
-----------------------------------------------------------------------------
As written by the databse-engine, there is a constraint violation. 
Can anyone give me a hint how to fix this? As I'm not familar with the 
internal database-organization.
Kind regards 
Sven

[oops, wrong list initially]
Reini Urban schrieb:
> Philip J. Hollenback schrieb:
>> Please approve the message I posted to phpwiki-talk a couple days ago:
> 
> Sorry, I don't see your message in my admin interface which goes back to 
> middle of July.
> 
>> Begin forwarded message:
>>> From: "Philip J. Hollenback" <ph...@po...>
>>> Date: August 10, 2008 9:39:01 AM PDT
>>> To: php...@li...
>>> Subject: forum.php spam pages
>>>
>>> I've got my phpwiki (www.hollenback.net) locked to all users except 
>>> myself for adding or editing pages. However, some spammer continues 
>>> to exploit some phpwiki bug or error in my config to create bogus 
>>> forum.php pages. These pages just contain lists of spam lnks. One 
>>> gets created about once a week.
>>>
>>> Is anyone else seeing this, and any suggestion for how I can fix it? 
>>> I know this is vague but I'm not sure where the hole is. I've had my 
>>> wiki running for quite a while with no problems so my first suspicion 
>>> is this is exploiting a hole in phpwiki.
Please remove lib/plugin/AddComment.php,
lib/plugin/WikiBlog.php and lib/plugin/WikiForum.php.
These plugins can be used by spammers.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Sabri LABBENE schrieb:
> Reini Urban wrote:
>> I'd need a new feature to seperate wiki pages between public 
>> and non-public, so that an external tool can make daily public 
>> copies of certain pages, either static or to some external 
>> wiki from within an intranet wiki.
>> And purge non-public pages and versions which were formerly public.
>>
>> Some kind of simple review process, not as complicated as 
>> ModeratedPage, similar to locked.
>> Just a new WikiDB_Page key "public", similar to "locked", with 
>> a checkbox below Locked in action=edit.
>>
>> Should I do that in the public version or just privately?
>> I think of adding a config.ini key like ENABLE_PAGEPUBLIC, 
>> default disabled. A better name would be appreciated.
>>
>> Or do we need more such page attributes, so that a generic 
>> plugin interface to editpage buttons and logic is needed?
> 
> I think it should be a page attribute just like 'locked'.
> 
>> I tough of support for more markup types, which need a 
>> pulldown instead of a checkbox (creole, mediawiki), but this 
>> is too complicated, technically and for the user, so I 
>> rejected that idea. WikiCreole should be supported as addon 
>> automatically and for Mediawiki or other syntax we'd need some 
>> external importer + exporter.
> 
> +1 for importer/exporter/converter solution. Supporting more markups would
> make the parser much more complicated and not easily maintenable! 
> 
>> Ratings are supported by the RateIt plugin which can be added 
>> to the editpage template if wanted.
>> More page attributes such as public in principal also, but 
>> because it is so simple I thought of adding it directly to 
>> lib/editpage.php optionally.
> 
> Yes, good idea.
I coded it now this way, and will test it a bit in the next week.
Just editpage.php and the editpage.tmpl template are affected besides 
config.ini.
I still have to add some code to PageList to support info=public in 
pagelists like AllPages, and maybe we still need a simple ListPublic 
plugin to be able to massedit it.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Reini Urban wrote:
>I'd need a new feature to seperate wiki pages between public 
>and non-public, so that an external tool can make daily public 
>copies of certain pages, either static or to some external 
>wiki from within an intranet wiki.
>And purge non-public pages and versions which were formerly public.
>
>Some kind of simple review process, not as complicated as 
>ModeratedPage, similar to locked.
>Just a new WikiDB_Page key "public", similar to "locked", with 
>a checkbox below Locked in action=edit.
>
>Should I do that in the public version or just privately?
>I think of adding a config.ini key like ENABLE_PAGEPUBLIC, 
>default disabled. A better name would be appreciated.
>
>Or do we need more such page attributes, so that a generic 
>plugin interface to editpage buttons and logic is needed?
I think it should be a page attribute just like 'locked'.
>I tough of support for more markup types, which need a 
>pulldown instead of a checkbox (creole, mediawiki), but this 
>is too complicated, technically and for the user, so I 
>rejected that idea. WikiCreole should be supported as addon 
>automatically and for Mediawiki or other syntax we'd need some 
>external importer + exporter.
+1 for importer/exporter/converter solution. Supporting more markups would
make the parser much more complicated and not easily maintenable! 
>Ratings are supported by the RateIt plugin which can be added 
>to the editpage template if wanted.
>More page attributes such as public in principal also, but 
>because it is so simple I thought of adding it directly to 
>lib/editpage.php optionally.
Yes, good idea.
-- Sabri.

I'd need a new feature to seperate wiki pages between public and
non-public, so that an external tool
can make daily public copies of certain pages, either static or to
some external wiki from within an intranet wiki.
And purge non-public pages and versions which were formerly public.
Some kind of simple review process, not as complicated as
ModeratedPage, similar to locked.
Just a new WikiDB_Page key "public", similar to "locked", with a
checkbox below Locked in action=edit.
Should I do that in the public version or just privately?
I think of adding a config.ini key like ENABLE_PAGEPUBLIC, default
disabled. A better name would be appreciated.
Or do we need more such page attributes, so that a generic plugin
interface to editpage buttons
and logic is needed?
I tough of support for more markup types, which need a pulldown
instead of a checkbox (creole, mediawiki),
but this is too complicated, technically and for the user, so I
rejected that idea. WikiCreole should be supported
as addon automatically and for Mediawiki or other syntax we'd need
some external importer + exporter.
Ratings are supported by the RateIt plugin which can be added to the
editpage template if wanted.
More page attributes such as public in principal also, but because it
is so simple I thought of adding
it directly to lib/editpage.php optionally.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/