Menu
▾
▴
phpwiki-talk
|
From: Carsten K. <car...@us...> - 2003-02-20 01:38:23
|
Thanks for the patch Jean-Philippe.
However, it appears there is another problem: xgettext (from
locale/Makefile) is not extracting the string in this line of
JavaScript from signin.tmpl:
document.write(' <?= _("Sign in:") ?>');
Hmm... anyone have any ideas to fix or work around this?
(Jean-Philippe's patch only fixes fr/LC_MESSAGES/phpwiki.php, doesn't
fix the fr.po and fr/LC_MESSAGES/phpwiki.mo files or other languages).
Carsten
On Wednesday, February 19, 2003, at 07:19 pm, Jean-Philippe Georget
wrote:
> Hi,
>
>
> A minor diff for locale/fr/LC_MESSAGES/phpwiki.php to support last
> modification of themes/default/templates/signin.tmpl
>
>
> Hope that help.
>
>
> <phpwiki.php.diff>
>
>
>
> --
> Jean-Philippe Georget
> jpg...@ou... - http://jpgeorget.ouvaton.org/
|
|
From: Jeff D. <da...@da...> - 2003-02-20 03:03:24
|
> However, it appears there is another problem: xgettext (from
> locale/Makefile) is not extracting the string in this line of
> JavaScript from signin.tmpl:
>
> document.write(' <?= _("Sign in:") ?>');
>
> Hmm... anyone have any ideas to fix or work around this?
Oh.
A hack would be to do:
<?php
$sign_in = _("Sign in:");
?>
<!-- stuff -->
document.write(' <?= $sign_in ?>');
Speaking of breaking things...
I've been working on several fairly major changes/enhancements.
o As promised years ago, I've just about gotten cached markup working.
(The transformed text of the most recent version of each page
is cached ... this results in a factor of 2-3 (sometimes more) speedup
on larger pages.
o As a side effect (again, as promised years ago) this eliminates
the need for a separate ExtractWikiPageLinks(). (A really good thing).
This broke a lot of stuff and required fairly major changes to some
parts of the code:
o I've severely refactored the stuff in PageType.php, also
plugin/WikiBlog
has been refactored beyond recognition.
o I'm sure I've broken lots of other things.
I'm about ready to check all this into CVS. (Probably some time
tomorrow...)
If anybody wants me to wait a bit before breaking the CVS code, now's
the time to speak up!
Jeff
|
|
From: Carsten K. <car...@us...> - 2003-02-20 04:22:47
|
No objections from me at all to refactoring of PageType, I admit it was most hackish. I had some changes to WikiBlog but nothing special, instead I look forward to see what you've done with it :) The html caching sounds very exciting too! Carsten On Wednesday, February 19, 2003, at 10:03 pm, Jeff Dairiki wrote: > Speaking of breaking things... > > I've been working on several fairly major changes/enhancements. > > o As promised years ago, I've just about gotten cached markup working. > (The transformed text of the most recent version of each page > is cached ... this results in a factor of 2-3 (sometimes more) > speedup > on larger pages. > > o As a side effect (again, as promised years ago) this eliminates > the need for a separate ExtractWikiPageLinks(). (A really good > thing). > > This broke a lot of stuff and required fairly major changes to some > parts of the code: > > o I've severely refactored the stuff in PageType.php, also > plugin/WikiBlog > has been refactored beyond recognition. > > o I'm sure I've broken lots of other things. > > I'm about ready to check all this into CVS. (Probably some time > tomorrow...) > > If anybody wants me to wait a bit before breaking the CVS code, now's > the time to speak up! > > Jeff |
|
From: Reini U. <ru...@x-...> - 2003-02-20 07:33:47
|
Jeff Dairiki schrieb:
>>However, it appears there is another problem: xgettext (from
>>locale/Makefile) is not extracting the string in this line of
>>JavaScript from signin.tmpl:
>>
>> document.write(' <?= _("Sign in:") ?>');
>>
>>Hmm... anyone have any ideas to fix or work around this?
>
>
> Oh.
>
> A hack would be to do:
>
> <?php
> $sign_in = _("Sign in:");
> ?>
> <!-- stuff -->
> document.write(' <?= $sign_in ?>');
>
>
>
>
> Speaking of breaking things...
>
> I've been working on several fairly major changes/enhancements.
>
> o As promised years ago, I've just about gotten cached markup working.
> (The transformed text of the most recent version of each page
> is cached ... this results in a factor of 2-3 (sometimes more) speedup
> on larger pages.
>
> o As a side effect (again, as promised years ago) this eliminates
> the need for a separate ExtractWikiPageLinks(). (A really good thing).
>
> This broke a lot of stuff and required fairly major changes to some
> parts of the code:
>
> o I've severely refactored the stuff in PageType.php, also
> plugin/WikiBlog
> has been refactored beyond recognition.
>
> o I'm sure I've broken lots of other things.
>
> I'm about ready to check all this into CVS. (Probably some time
> tomorrow...)
>
> If anybody wants me to wait a bit before breaking the CVS code, now's
> the time to speak up!
Please do so. Good stuff.
I'm also refactoring my UserAuth stuff, as promised years :) ago.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Jeff D. <da...@da...> - 2003-02-20 16:59:34
|
On Thu, 20 Feb 2003 08:34:11 +0100
Reini Urban <ru...@x-...> wrote:
> Please do so. Good stuff.
All righty. Expect it later today.
> I'm also refactoring my UserAuth stuff, as promised years :) ago.
Ooh. Very good.
I've a couple comments/suggestions, I suspect you might already have
thought of these, but I'd thought I'd toss them out.
1. Each of the authentication methods and means of storing/retrieving
user information (i.e. prefs, password, etc...) should be encapsulated
in an object.
I.e. introduce a new virtual base class called AuthDB. I, obviously
haven't thought this out too fully, but something like.
// Return codes. Note that you can check for success
// by casting to int: if ((int)$db->checkPassword(...))...
define ('AUTHDB_OK', "1 OK");
define ('AUTHDB_BADUSER', "0 Bad User");
define ('AUTHDB_BADPASSWORD', "0 Bad Password");
// AuthDB doesn't support the requested operation.
define ('AUTHDB_NOTSUPPORTED', "0 Not Supported");
class AuthDB {
// Get name of authentication method.
function getName() { return get_class($this); // or something ? }
// Returns AUTH_LEVEL, or one of
AUTHDB_{BADUSER,BADPASSWORD,NOTSUPPORTED}
//
function checkPassword($userid, $password) { return AUTHDB_NOTSUPPORTED;
}
function setPassword($userid, $oldpw, $newpw) { return
AUTHDB_NOTSUPPORTED; }
// ... this part is a little fuzzier as to exact API...
function createUser($userid, $user_data) { return
AUTHDB_NOTSUPPORTED; }
function getUserData($userid) { return AUTHDB_NOTSUPPORTED; }
function updateUserData($userid, $user_ata) { return
AUTHDB_NOTSUPPORTED; }
// ...
}
There would be a subclass of AuthDB for each type of authentication.
(Including AuthDBAdmin (for authentication vs the admin name and pw
in index.php) and AuthDBBogo.)
Then, e.g. to check passwords, instead of giant nested ifs which need
to be adjusted every time someone wants to add a new authentication
method:
class WikiUser {
...
function _pwcheck($user, $pw) {
global $AuthMethods;
foreach ($AuthMethods as $db) {
$authlevel = $db->checkPassword($user, $pw);
if ((int)$authlevel)
return $authlevel;
}
return WIKIAUTH_ANON;
}
}
2. Probably we need to identify and handle two different kinds of prefs.
There are some which should definitely be storable in a cookie, e.g.
for anonymous users --- things like date-formatting preference,
and edit area size, (and default user name).
Things like password and e-mail are more tightly associated with
an _authenticated_ user. These, of course, should not be stored
in cookies... I think we should start calling them user_data
instead of prefs.
Of course, users might want to store prefs as part of their user_data.
(It's unclear to me which should take precedence if prefs are available
both from a cookie and from $user_data['prefs']...)
2a.When refactoring make sure that it's easy to drop back to only
allowing BOGO-authentication. I had to comment out a lot of
code (and munge some templates pretty heavily) to get this to work
and look reasonably clean...
Many wikis will want to remain (in the wiki tradition) open, with
no user registration.
2b.Please make it easy to disable the auto-generation of all the fancy
user sub-pages. I can see where some might like them, but to me
they seem very non-wiki-ish...
Whew... that's a load off my chest. Sorry ... I didn't mean to
unload on you like that. :-)
Jeff
PS: Is the current user authentication code working at all? I notice
there's been a number of questions about it on the SourceForge forums.
E.g. http://sourceforge.net/forum/message.php?msg_id=1889421 (and
others). You might want to post a note over there to let people know
the
status. (I would do it, but I'm unsure of the status.)
|
|
From: Jeff D. <da...@da...> - 2003-02-21 04:33:41
|
On Thu, 20 Feb 2003 08:59:32 -0800 Jeff Dairiki <da...@da...> wrote: > On Thu, 20 Feb 2003 08:34:11 +0100 > Reini Urban <ru...@x-...> wrote: > > > Please do so. Good stuff. > > All righty. Expect it later today. All righty indeed. I've just checked in the latest hacks. The only thing I know for sure that will break is your InterWikiMap. Now, the InterWikiMap has to have meta-data specifying that it is of pagetype interwikimap. The only way currently to set this meta-data is by loading a page (e.g. from zip or pgsrc). So if you should load the latest pgsrc/InterWikiMap (or just start with a virgin wiki) your InterWikiMap should work again... |
|
From: Reini U. <ru...@x-...> - 2003-02-21 06:38:56
|
Jeff Dairiki schrieb: > All righty indeed. I've just checked in the latest hacks. Whow! Now this thing should be fast enough. |
|
From: Reini U. <ru...@x-...> - 2003-02-21 06:35:07
|
Jeff Dairiki schrieb:
> On Thu, 20 Feb 2003 08:34:11 +0100
> Reini Urban <ru...@x-...> wrote:
>>Please do so. Good stuff.
>>I'm also refactoring my UserAuth stuff, as promised years :) ago.
>
>
> Ooh. Very good.
>
> I've a couple comments/suggestions, I suspect you might already have
> thought of these, but I'd thought I'd toss them out.
>
> 1. Each of the authentication methods and means of storing/retrieving
> user information (i.e. prefs, password, etc...) should be encapsulated
> in an object.
>
> I.e. introduce a new virtual base class called AuthDB. I, obviously
> haven't thought this out too fully, but something like.
>
> // Return codes. Note that you can check for success
> // by casting to int: if ((int)$db->checkPassword(...))...
> define ('AUTHDB_OK', "1 OK");
> define ('AUTHDB_BADUSER', "0 Bad User");
> define ('AUTHDB_BADPASSWORD', "0 Bad Password");
>
> // AuthDB doesn't support the requested operation.
> define ('AUTHDB_NOTSUPPORTED', "0 Not Supported");
>
> class AuthDB {
>
> // Get name of authentication method.
> function getName() { return get_class($this); // or something ? }
>
> // Returns AUTH_LEVEL, or one of
> AUTHDB_{BADUSER,BADPASSWORD,NOTSUPPORTED}
> //
> function checkPassword($userid, $password) { return AUTHDB_NOTSUPPORTED;
> }
> function setPassword($userid, $oldpw, $newpw) { return
> AUTHDB_NOTSUPPORTED; }
>
> // ... this part is a little fuzzier as to exact API...
> function createUser($userid, $user_data) { return
> AUTHDB_NOTSUPPORTED; }
> function getUserData($userid) { return AUTHDB_NOTSUPPORTED; }
> function updateUserData($userid, $user_ata) { return
> AUTHDB_NOTSUPPORTED; }
> // ...
> }
>
> There would be a subclass of AuthDB for each type of authentication.
> (Including AuthDBAdmin (for authentication vs the admin name and pw
> in index.php) and AuthDBBogo.)
>
>
> Then, e.g. to check passwords, instead of giant nested ifs which need
> to be adjusted every time someone wants to add a new authentication
> method:
>
> class WikiUser {
> ...
> function _pwcheck($user, $pw) {
> global $AuthMethods;
> foreach ($AuthMethods as $db) {
> $authlevel = $db->checkPassword($user, $pw);
> if ((int)$authlevel)
> return $authlevel;
> }
> return WIKIAUTH_ANON;
> }
> }
>
>
> 2. Probably we need to identify and handle two different kinds of prefs.
> There are some which should definitely be storable in a cookie, e.g.
> for anonymous users --- things like date-formatting preference,
> and edit area size, (and default user name).
>
> Things like password and e-mail are more tightly associated with
> an _authenticated_ user. These, of course, should not be stored
> in cookies... I think we should start calling them user_data
> instead of prefs.
>
> Of course, users might want to store prefs as part of their user_data.
> (It's unclear to me which should take precedence if prefs are available
> both from a cookie and from $user_data['prefs']...)
>
> 2a.When refactoring make sure that it's easy to drop back to only
> allowing BOGO-authentication. I had to comment out a lot of
> code (and munge some templates pretty heavily) to get this to work
> and look reasonably clean...
>
> Many wikis will want to remain (in the wiki tradition) open, with
> no user registration.
Sure. Only optional.
> 2b.Please make it easy to disable the auto-generation of all the fancy
> user sub-pages. I can see where some might like them, but to me
> they seem very non-wiki-ish...
ok.
> PS: Is the current user authentication code working at all? I notice
> there's been a number of questions about it on the SourceForge forums.
>
> E.g. http://sourceforge.net/forum/message.php?msg_id=1889421 (and
> others). You might want to post a note over there to let people know
> the
> status. (I would do it, but I'm unsure of the status.)
Ok, I'll do.
The current status is that:
Works for me, but not in CVS (disabled there),
and just for my limited set of needed options:
mysql auth with a user table with password.
CREATE TABLE users (
userid char(48) binary NOT NULL UNIQUE,
passwd char(48) binary default '*',
PRIMARY KEY (userid)
) TYPE=MyISAM;
but I will test with that now:
CREATE TABLE users (
userid char(48) binary NOT NULL UNIQUE,
passwd char(48) binary default '*',
pref text NULL default '',
PRIMARY KEY (userid)
) TYPE=MyISAM;
$DBAuthParams['auth_dsn'] = $DBParams['dsn'];
$DBAuthParams['pref_select'] = 'SELECT pref FROM users WHERE
userid="$userid"';
$DBAuthParams['pref_update'] = 'UPDATE users SET pref="$pref_blob" WHERE
userid="$userid"';
$DBParams['dbtype'] = 'SQL';
I'll rewrite it with the abstract base class AuthDB, as you suggested.
Of course the current status (bogo) will be the default auth method.
And I want to test it with phpnuke and other frameworks also
before I commit.
groups and page permissions later.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Jean-Philippe G. <jpg...@ou...> - 2003-03-22 18:03:45
|
Hi,
I want to use PhpWiki with another language.
I configure PhpWiki with index.php but the HomePage stay in english.
in lib/config.php I have to use somethnig like :
if (!defined('HOME_PAGE'))
define('HOME_PAGE', _("HomePageLocalized"));
Is there a more easy way to do this ?
--
Jean-Philippe Georget
jpg...@ou... - http://jpgeorget.ouvaton.org/
|
×
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