Menu
▾
▴
phpwiki-talk
|
From: Reini U. <ru...@x-...> - 2004-02-23 23:05:39
|
Are we ready for the intermediate 1.3.8 release?
The only issues are longstanding minor problems with serial dumps on
windows only, but all other show stoppers has been been fixed to my
knowledge.
I leave PagePerm's as it is now. You can change it internally, but the
interface has to be improved, and is not tested enough. This should work
for 1.4.0
I wrote a ReleaseNote, we still have to change the src to disable DEBUG
and the version number.
Steve, if you make the release,
please change the version to 1.3.8, disable DEBUG, and tag the sources.
To be done for 1.4.0:
* improve WikiAdminSetAcl, test PagePerms.
* implement paging for long lists:
requires ->_backend->get_num_pages(),
and enable the limit support in PageList
just display prev + next buttons
* fix minor dumping problems.
* use lib/removepage for WikiAdminRemove
* check the sf.net patches and bug submssions.
ReleaseNote for 1.3.8:
This is the first release with the new WikiUser class and
page permissions. Full page permission support will be enabled
in the upcoming 1.4.0 release.
New Features:
* The long-awaited WikiUserNew class,
a OOP rewrite of the marginally enabled auth code, which does:
* optional external user authentification against databases,
LDAP, IMAP and Files, in spirit to libnss and linux PAM.
See doc/README.phpwiki-auth
* optionally read and store user preferences in a database. (not
in cookies or the users homepage)
* New PagePerm class, Solaris/Windows-style ACL for stricter
permissions per page. Translates original permissions
to default ACL's. (cannot be managed yet, => 1.4.0)
* Minor Pear DB update from Pear.
* PageList sortable by pagename, mtime and hits.
Working against paging support for longer lists (limit arg).
New layout for such pagelists (grid-style)
* New WikiAdmin plugins to administrate selectable pages
("Page Explorer"), for Rename, Search & Replace.
* New other plugins:
UpLoad: Basic UpLoad support by a special Upload: interwiki map
by NathanGass <ga...@io...>, ReiniUrban <ru...@x-...> and
qubit <rt...@da...>
IncludeSiteMap: A combination of IncludePage and SiteMap
RichTable: Allow rich formatting in table cells, See RichTablePlugin
by Sameer D. Sahasrabuddhe
* Basic Japanese language support (no pgsrc yet),
by Tadashi Jokagi <web...@el...>
* PhpWiki as PostNuke module improved, by Jason Potkanski (electrawn)
* Allow inlining of images from a InterWiki url, for Upload support
* [Upload:my_image.gif] inlines the image,
* Upload:my_image.gif shows a plain inter-wiki link,
* [what a pic|Upload:my_image.gif] shows a named inter-wiki
link to the gif
* [Upload:my_image.gif|what a pic] shows a inlined image
linked to the page "what a pic"
* New WikiGroup class enabled with the backends:
NONE, WIKIPAGE, DB, FILE, LDAP
(needed for page permissions in 1.4.0)
Internally:
* a session holds more user information than before.
* htmlarea3 was tested. Seems to be too complicated to fit
into the current usage policy. Only HTML can be written back from the
textarea, and a HTML => Wiki format converter seems to be hard
to write, esp. full roundtrips. Partial support (HTML PageType)
seems to be against PhpWiki spirit. Use Guiki instead for now.
* fpdf was tested to support PDF dumps (not yet enabled),
* A SpellCheck feature was tested (not yet enabled),
* moved interwiki.php code to PageType.php
* internal _AuthInfo plugin to see the current auth settings.
* intermediate InterWikiSearch revamp. (not yet working)
* working on a dynamic upgrader
(update pgsrc, enable new features, update deprecated features, ...)
* working on a dynamic installer
(initial work by electrawn for PostNuke)
* UserPreferences has some options enabled, which do not work yet
(notify by email, email check)
Fixed Bugs:
* Revived WikiAdminSelect and WikiAdminRemove,
* Fixed XHTML dumps (wrong basepage, recursion detection),
* ADODB limit code
ReiniUrban <ru...@x-...>
|
|
From: Dan F <dfr...@cs...> - 2004-02-24 03:03:31
|
Reini Urban wrote: > Are we ready for the intermediate 1.3.8 release? > I wrote a ReleaseNote, we still have to change the src to disable > DEBUG and the version number. > > Steve, if you make the release, > please change the version to 1.3.8, disable DEBUG, and tag the sources. Let me join malcolmr in saying: 1. PhpWiki has great potential. 2. Releasing something stable is good. Also, I would really like to use some of the things in 1.3.8, e.g. strong user authentication. I know people asking you to release without doing any work can be irritating, but you have to take it in the spirit given: you have an attentive user base. Dan |
|
From: <mal...@cs...> - 2004-03-17 00:58:01
|
On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote: > Reini Urban wrote: > >Are we ready for the intermediate 1.3.8 release? > > Let me join malcolmr in saying: > > 1. PhpWiki has great potential. > 2. Releasing something stable is good. > > Also, I would really like to use some of the things in 1.3.8, e.g. > strong user authentication. > > I know people asking you to release without doing any work can be > irritating, but you have to take it in the spirit given: you have an > attentive user base. Thankyou, Dan, for expressing this in a much nicer way than I did. Eagerly awaiting 1.4, Malcolm -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ "Blessed are those who mourn, for they will be comforted." -- Matt 5:4 |
|
From: <jw...@fi...> - 2004-03-17 08:33:32
|
Hello, I am starting a new phpwiki for newbies. I have always used the WikiName convention for page naming, but I was wondering what you guys think of the [ my page name ] convention. Is it very bad ? Is it correctly taken into account in the source code ? Should I stay as far as I can from it and stick to WikiNames ? Thanks for sharing your experience on that point J=E9r=F4me -----Message d'origine----- De=A0: php...@li... [mailto:php...@li...] De la part de Malcolm = Ross Kinsella Ryan Envoy=E9=A0: mercredi 17 mars 2004 01:58 =C0=A0: php...@li... Objet=A0: Re: [Phpwiki-talk] Ready for 1.3.8 ? On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote: > Reini Urban wrote: > >Are we ready for the intermediate 1.3.8 release? >=20 > Let me join malcolmr in saying: >=20 > 1. PhpWiki has great potential. > 2. Releasing something stable is good. >=20 > Also, I would really like to use some of the things in 1.3.8, e.g.=20 > strong user authentication. >=20 > I know people asking you to release without doing any work can be=20 > irritating, but you have to take it in the spirit given: you have an=20 > attentive user base. Thankyou, Dan, for expressing this in a much nicer way than I did. Eagerly awaiting 1.4, Malcolm --=20 Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ "Blessed are those who mourn, for they will be comforted." -- Matt = 5:4 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Phpwiki-talk mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |
|
From: Reini U. <ru...@x-...> - 2004-03-17 21:11:21
|
> On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote:
>>Reini Urban wrote:
>>>Are we ready for the intermediate 1.3.8 release?
>>
>>Let me join malcolmr in saying:
>>1. PhpWiki has great potential.
>>2. Releasing something stable is good.
>>
>>Also, I would really like to use some of the things in 1.3.8, e.g.
>>strong user authentication.
>>
>>I know people asking you to release without doing any work can be
>>irritating, but you have to take it in the spirit given: you have an
>>attentive user base.
The only remaining problem before releasing 1.3.8 is a gettext or
update_locale problem for foreign languages.
All other issues (besides running as CGI) has been resolved now.
The strange thing is that on most of my test setups everything works
okay, just on PhpWikiDemo it fails sometimes, sometimes it works.
Which lets me assume that it could be a preferences setting.
What is planned for the next releases up to 1.4.0
-------------------------------------------------
Page permissions editable:
* enable and simplify WikiAdminSetAcl, and probably WikiAdminChmod.
let the user harden the ACL's of some pages.
Default: loose permissions as before
Page permissions enforced:
* check in all actions, plugins and listers for access permissions.
(listers almost done)
WikiDB:
* update to the latest ADODB library (but not the session class)
* switch to FETCH_ROW
* check for the dirty ADODB mysql hacks
(INSERT ... SELECT)
* test SQLite and PHP 5.0.x
Plugins:
* WikiForum (almost the same as AddComments and WikiBlog)
* Amazon, Google API's (using SOAP)
* RateThisPage (user-specific and overall)
More Themes:
* nuke (a tiny-font three-column theme),
* crao (buttons as icons which need no translation, and
more sidebar tricks)
Localization updates:
* with the new _WikiTranslation and TranslateText features
hopefully some holes will get filled.
action=upgrade for database upgrades, pgsrc diffs and with verification.
(currently only pgsrc upgrade on missing pages)
I'm not sure the requested installer and WikiAuth split-up into seperate
files. Seperate UserPreferences classes are more important IMHO.
All this is not too much work. I think of about 2-3 weeks from
1.3.8 to 1.4.0
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: electron <ele...@mg...> - 2004-03-18 04:20:43
|
1.3.8 may be a week or less away, however, I doubt one could say 1.4.0 =
is
2-3 weeks away.
Enter the realist(tm):
Before 1.4.0, it is critically important that the only time dbtype is
checked is when wikidb is initialized. This may mean having to add some =
user
based functions to wikidb or moving wiki authentication to a separate =
layer.
Essentially, if I write an extension for wikidb (phADODB, which =
pnPhpWiki
uses to tap into postnuke), by checking elsewhere for dbtype I just lost
functionality!
An installer is useful because the whole point of our userbase is to be =
user
friendly. This includes the admins. You shouldn't need a $40 an hour
consultant to install phpwiki.
Defines suck. Defines are everywhere where they don't need to be. =
Index.php
is hugely bloated, complex and not documented well.
Finally, Documentation, Doc, and Doc!
There is no rush to get to 1.4.0. 1.4.0 should be a complete, pretty, =
easy
to install and easy to administer wiki miniCMS.=20
1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0.
-Jtp.
> On Mon, Feb 23, 2004 at 09:02:56PM -0600, Dan F wrote:
>>Reini Urban wrote:
>>>Are we ready for the intermediate 1.3.8 release?
>>
>>Let me join malcolmr in saying:
>>1. PhpWiki has great potential.
>>2. Releasing something stable is good.
>>
>>Also, I would really like to use some of the things in 1.3.8, e.g.=20
>>strong user authentication.
>>
>>I know people asking you to release without doing any work can be=20
>>irritating, but you have to take it in the spirit given: you have an=20
>>attentive user base.
The only remaining problem before releasing 1.3.8 is a gettext or=20
update_locale problem for foreign languages.
All other issues (besides running as CGI) has been resolved now.
The strange thing is that on most of my test setups everything works=20
okay, just on PhpWikiDemo it fails sometimes, sometimes it works.
Which lets me assume that it could be a preferences setting.
What is planned for the next releases up to 1.4.0
-------------------------------------------------
Page permissions editable:
* enable and simplify WikiAdminSetAcl, and probably WikiAdminChmod.
let the user harden the ACL's of some pages.
Default: loose permissions as before
Page permissions enforced:
* check in all actions, plugins and listers for access permissions.
(listers almost done)
WikiDB:
* update to the latest ADODB library (but not the session class)
* switch to FETCH_ROW
* check for the dirty ADODB mysql hacks
(INSERT ... SELECT)
* test SQLite and PHP 5.0.x
Plugins:
* WikiForum (almost the same as AddComments and WikiBlog)
* Amazon, Google API's (using SOAP)
* RateThisPage (user-specific and overall)
More Themes:
* nuke (a tiny-font three-column theme),
* crao (buttons as icons which need no translation, and
more sidebar tricks)
Localization updates:
* with the new _WikiTranslation and TranslateText features
hopefully some holes will get filled.
action=3Dupgrade for database upgrades, pgsrc diffs and with =
verification.
(currently only pgsrc upgrade on missing pages)
I'm not sure the requested installer and WikiAuth split-up into seperate =
files. Seperate UserPreferences classes are more important IMHO.
All this is not too much work. I think of about 2-3 weeks from
1.3.8 to 1.4.0
--=20
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Matthew P. <mp...@he...> - 2004-03-18 05:04:56
|
On Wed, Mar 17, 2004 at 10:18:26PM -0600, electron wrote: > An installer is useful because the whole point of our userbase is to be user > friendly. This includes the admins. You shouldn't need a $40 an hour > consultant to install phpwiki. Tell everyone to use Debian. <grin> Practically, PHPWiki is pretty simple to install. If someone's got an Apache webserver with PHP4 working already, chances are they're about 90 seconds away from a working PHPWiki install. Providing a "ready to go" apache.conf for inclusion would be the one big step (I can provide the one I use for Debian if anyone wants it). > Defines suck. Defines are everywhere where they don't need to be. Index.php > is hugely bloated, complex and not documented well. Index.php shouldn't be a .php file. PHP has a wonderful .ini parser, and nobody uses it! I'd recommend doing a switch (it might not be a 1.3 series thing, though) to a .ini config file, out of the web tree entirely. An autowriter should be easy enough - load up index.php, iterate through the define list, and write it all to an ini file. Lack of internal documentation on that will suck, though, but a default "edit-through" ini file should work well. > Finally, Documentation, Doc, and Doc! I *think* that most of the stuff people are interested in is documented inside the Wiki somewhere, but a lot of things just aren't easily accessible. > There is no rush to get to 1.4.0. 1.4.0 should be a complete, pretty, easy > to install and easy to administer wiki miniCMS. Does SF have the ability to group "tasks" into releases, for planning purposes? If everything were tracked there, it would make it easier for the externals like me to see how things are going. > 1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0. Erm, no. The 1.3 series should be bugfixes only. Even my SQLite stuff shouldn't really be released in a 1.3 series, unless it gets a *hell* of a lot of testing (which it will, shortly). We need to create a new 1.4 branch to make all these developmental changes on. Fork from the existing 1.3 tree and start hacking. Make those big changes like rewriting all the DB stuff. Nothing in there should necessarily be working particularly well, although keeping as much stuff working as possible is good, because then the bold people can run it for kicks. But 1.3 is not the place to be working towards 1.4, because then we either have no really new innovations in 1.4 (because we had to keep all the old crud working), or nothing works for a while in 1.3 (because things are being broken all the time and not everything is stable at the exact same time) or we don't make any releases (because nothing's working properly). But that opinion, of course, is as a rank outsider to PHPWiki, so it should be taken with the sachet of salt provided. <grin> - Matt |
|
From: Reini U. <ru...@x-...> - 2004-03-18 14:46:33
|
Matthew Palmer schrieb: > On Wed, Mar 17, 2004 at 10:18:26PM -0600, electron wrote: >>Defines suck. Defines are everywhere where they don't need to be. Index.php >>is hugely bloated, complex and not documented well. > > Index.php shouldn't be a .php file. PHP has a wonderful .ini parser, and > nobody uses it! I'd recommend doing a switch (it might not be a 1.3 series > thing, though) to a .ini config file, out of the web tree entirely. An > autowriter should be easy enough - load up index.php, iterate through the > define list, and write it all to an ini file. Lack of internal > documentation on that will suck, though, but a default "edit-through" ini > file should work well. > >>Finally, Documentation, Doc, and Doc! > I *think* that most of the stuff people are interested in is documented > inside the Wiki somewhere, but a lot of things just aren't easily > accessible. > >>There is no rush to get to 1.4.0. 1.4.0 should be a complete, pretty, easy >>to install and easy to administer wiki miniCMS. Well, the "easy to install" thing is controversial. Let's discuss a ini-style config. For all my other projects I use simple ini files, because they are language independent, and can be moved away from the project tree. (to /etc/ e.g.) Personally I prefer like the current way, esp. for wikifarms or multilingual sites, like PhpWikiDemo. index.php is easy to include and override behind the master script, a phpwiki.ini not. Why another parser? Just the db and admin password exposure is problematic. Can somebody setup a PhpWiki:IniStyleConfig page for 1.4.0? With pro's and contra's. > Does SF have the ability to group "tasks" into releases, for planning > purposes? If everything were tracked there, it would make it easier for the > externals like me to see how things are going. > >>1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0. > Erm, no. The 1.3 series should be bugfixes only. Even my SQLite stuff > shouldn't really be released in a 1.3 series, unless it gets a *hell* of a > lot of testing (which it will, shortly). sqlite is only included as experimental backend, to attrack people to test it. For sure it's not a supported backend. But we have to start to do it. > We need to create a new 1.4 branch to make all these developmental changes > on. Fork from the existing 1.3 tree and start hacking. Make those big > changes like rewriting all the DB stuff. Nothing in there should > necessarily be working particularly well, although keeping as much stuff > working as possible is good, because then the bold people can run it for > kicks. But 1.3 is not the place to be working towards 1.4, because then we > either have no really new innovations in 1.4 (because we had to keep all the > old crud working), or nothing works for a while in 1.3 (because things are > being broken all the time and not everything is stable at the exact same > time) or we don't make any releases (because nothing's working properly). 1.3.8 is basically a test release for 1.4.0 with enforced page permissions (this is the real major change), the new auth and pref layout, paging support and some DB enhancements. The new DB enhancements are no big rewrite, just an minor update from the ADODB mainline, to support all other databases with adodb also, nuke integration, and esp. to make use of the php_adodb.(so|dll), so we need the ADODB classes instead of the functions. In fact it's more like a necessary ADODB cleanup. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Matthew P. <ma...@he...> - 2004-03-19 00:19:55
|
Reini Urban said: > Personally I prefer like the current way, esp. for wikifarms or > multilingual sites, like PhpWikiDemo. index.php is easy to include and > override behind the master script, a phpwiki.ini not. Why another > parser? Just the db and admin password exposure is problematic. > Can somebody setup a PhpWiki:IniStyleConfig page for 1.4.0? New config parser, define()ator, and documentation? I'd put my hand up for it, except that I can't guarantee I'll have the time. Expect it when it drops onto here. <g> - Matt |
|
From: <mal...@cs...> - 2004-03-18 22:57:38
|
On Wed, Mar 17, 2004 at 10:18:26PM -0600, electron wrote: > > An installer is useful because the whole point of our userbase is to be user > friendly. This includes the admins. You shouldn't need a $40 an hour > consultant to install phpwiki. Indeed. I balked at installing 1.3.7 when I saw the following message: // IMPORTANT NOTE: Use of the ***configurator.php*** to generate an // index.php is depreciated, because it is out of date and a new // configuration system is in the works (see the config directory, not // finished yet though). DO compare or diff the configurator's output // against this file if you feel you must use it to generate an // index.php! I would really like to use PhpWiki, but I have better things to do with my life than manually edit configuration files written in a language I do not understand. Malcolm -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ "Blessed are the peacemakers, for they will be called children of God." -- Matt 5:9 |
|
From: Matthew P. <ma...@he...> - 2004-03-19 00:08:44
|
Malcolm Ross Kinsella Ryan said: > Indeed. I balked at installing 1.3.7 when I saw the following message: > > // IMPORTANT NOTE: Use of the ***configurator.php*** to generate an // > index.php is depreciated, because it is out of date and a new > // configuration system is in the works (see the config directory, not > // finished yet though). DO compare or diff the configurator's output > // against this file if you feel you must use it to generate an > // index.php! > > I would really like to use PhpWiki, but I have better things to do > with my life than manually edit configuration files written in a > language I do not understand. It's not as if the configuration file is excruciatingly difficult to read. The use of define() does weirden things up a bit, though, I agree. Would a nicely formatted and readable INI file suit better, or are you really deeply attached to the GUI config tool? - Matt |
|
From: <mal...@cs...> - 2004-03-18 23:07:13
|
On Thu, Mar 18, 2004 at 04:04:20PM +1100, Matthew Palmer wrote: > > > 1.3.8 Should proceed to 1.3.9 and implement a roadmap to 1.4.0. > > Erm, no. The 1.3 series should be bugfixes only. Even my SQLite stuff > shouldn't really be released in a 1.3 series, unless it gets a *hell* of a > lot of testing (which it will, shortly). > > We need to create a new 1.4 branch to make all these developmental changes > on. Erm, no. The odd numbered branches are development releases in which we add new features. The even numbered branches are stable releases which only include bugfixes. Please, please, let 1.4 be a stable branch. It's been a very long time since us users have had a version of PhpWiki in which bugs are being fixed at a faster rate than they are being created. 1.3 has many cool features that I long to try out, but not until I can be sure that it will be stable, and remain that way. Once you've released 1.4, by all means start work on 1.5 and add all the crazy features you can imagine. Malcolm (Self-appointed PhpWiki curmudgeon) -- Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/ "Blessed are the poor in spirit, for theirs is the kingdom of heaven." -- Matt 5:3 |
|
From: Matthew P. <ma...@he...> - 2004-03-18 23:59:56
|
Malcolm Ross Kinsella Ryan said: > Erm, no. The odd numbered branches are development releases in which we > add new features. The even numbered branches are stable releases which > only include bugfixes. OK, my mistake on that one. Is PHPWiki trying to overtake Debian as having the "slowest release process, ever", then? - Matt |
|
From: electron <ele...@mg...> - 2004-02-24 06:34:44
|
To be done for 1.4.0:
* improve WikiAdminSetAcl, test PagePerms.
* implement paging for long lists:
requires ->_backend->get_num_pages(),
and enable the limit support in PageList
just display prev + next buttons
* fix minor dumping problems.
* use lib/removepage for WikiAdminRemove
* check the sf.net patches and bug submssions.
My additions:
* Trim WikiUserNew so its not calling itself for upgrading. Possibly split
it to a WikiAuth folder/backend style ala WikiDB
* Move Admin/PW out index.php and into the DB. Create a "superuser" group.
* Rip out any place except WikiDB where we are checking DBParams for dbtype
(breaks portability)
* Move diff.php to a plugin and add some requested features. (colorization)
* Native XML dumping. Create a wiki schema if none exists.
* Clean UserPreferences.tmpl into the plugin.
* Try and make more plugins use templating.
* Touch as many todos and fixmes as possible.
* More dynamic configuration and installer stuff.
* Update Doc, Doc Doc...and more Doc!
* Consider a better translation system.
* Clean up and organize sourceforge.net site.
And not necessarily in that order.
New Features:
* The long-awaited WikiUserNew class,
a OOP rewrite of the marginally enabled auth code, which does:
* optional external user authentification against databases,
LDAP, IMAP and Files, in spirit to libnss and linux PAM.
See doc/README.phpwiki-auth
* optionally read and store user preferences in a database. (not
in cookies or the users homepage)
|
|
From: Reini U. <ru...@x-...> - 2004-02-24 14:44:00
|
I found and fixed another error in action=upload with win 32 only. But found another one with merge edit then. Will be fixed soon. electron schrieb: > To be done for 1.4.0: > * improve WikiAdminSetAcl, test PagePerms. > * implement paging for long lists: > requires ->_backend->get_num_pages(), > and enable the limit support in PageList > just display prev + next buttons > * fix minor dumping problems. > * use lib/removepage for WikiAdminRemove > * check the sf.net patches and bug submssions. > > My additions: > > * Trim WikiUserNew so its not calling itself for upgrading. Possibly split > it to a WikiAuth folder/backend style ala WikiDB This is the best method I came up with, supporting all the wanted features. > * Move Admin/PW out index.php and into the DB. Create a "superuser" group. This was voted down many times before. Simplicity. Most people use just gdbm. > * Rip out any place except WikiDB where we are checking DBParams for dbtype > (breaks portability) Sure. > * Move diff.php to a plugin and add some requested features. (colorization) > * Native XML dumping. Create a wiki schema if none exists. > * Clean UserPreferences.tmpl into the plugin. > * Try and make more plugins use templating. > * Touch as many todos and fixmes as possible. > * More dynamic configuration and installer stuff. > * Update Doc, Doc Doc...and more Doc! Sure. > * Consider a better translation system. Suggestions? > * Clean up and organize sourceforge.net site. Steve. > And not necessarily in that order. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Arnaud F. <ar...@cr...> - 2004-02-24 17:41:18
|
Yet another suggestion : Make a "format" directory where you store plugins to handle ouput format. Then it will be easier to add new output formats without hacking the core of phpwiki. -- Arnaud Fontaine Jabber: sh...@ra... ICQ: 3504789 |
|
From: Reini U. <ru...@x-...> - 2004-02-24 18:07:31
|
Arnaud Fontaine schrieb:
> Make a "format" directory where you store plugins to handle ouput
> format.
>
> Then it will be easier to add new output formats without hacking the
> core of phpwiki.
This doesn't fit into our plugin architecture.
It would fit to PageType subclassing, where we define the format method
for various types.
Output formats are:
(divided into screen and filedump. printer via special
printer stylesheet)
WikiHTML, DumpHTML, XML (not yet), PDF (not yet), MIME, plain file,
RSS
Now used special PageTypes are:
wikitext (=WikiHTML), interwikimap, blog,
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: John K. <li...@ke...> - 2004-02-24 08:13:02
|
At 12:05 am +0100 24/2/04, Reini Urban wrote: >Are we ready for the intermediate 1.3.8 release? Wow - phpwiki's looking better all the time. Great work guys :) John. |
|
From: Reini U. <ru...@x-...> - 2004-02-24 17:54:06
|
Steve, I think we are ready now for 1.3.8. I just wrote another simple plugin to avoid caching of certain dynamic plugins, called NoCache. This should be added to ReleaseNotes also. See below. Reini Urban schrieb: > Are we ready for the intermediate 1.3.8 release? > The only issues are longstanding minor problems with serial dumps on > windows only, but all other show stoppers has been been fixed to my > knowledge. fixed. > I leave PagePerm's as it is now. You can change it internally, but the > interface has to be improved, and is not tested enough. This should work > for 1.4.0 > > I wrote a ReleaseNote, we still have to change the src to disable DEBUG > and the version number. > > Steve, if you make the release, > please change the version to 1.3.8, disable DEBUG, and tag the sources. > > To be done for 1.4.0: > * improve WikiAdminSetAcl, test PagePerms. > * implement paging for long lists: > requires ->_backend->get_num_pages(), > and enable the limit support in PageList > just display prev + next buttons > * fix minor dumping problems. > * use lib/removepage for WikiAdminRemove > * check the sf.net patches and bug submssions. > > > ReleaseNote for 1.3.8: > > This is the first release with the new WikiUser class and > page permissions. Full page permission support will be enabled > in the upcoming 1.4.0 release. > > New Features: > * The long-awaited WikiUserNew class, > a OOP rewrite of the marginally enabled auth code, which does: > > * optional external user authentification against databases, > LDAP, IMAP and Files, in spirit to libnss and linux PAM. > See doc/README.phpwiki-auth > * optionally read and store user preferences in a database. (not > in cookies or the users homepage) > > * New PagePerm class, Solaris/Windows-style ACL for stricter > permissions per page. Translates original permissions > to default ACL's. (cannot be managed yet, => 1.4.0) > * Minor Pear DB update from Pear. > * PageList sortable by pagename, mtime and hits. > Working against paging support for longer lists (limit arg). > New layout for such pagelists (grid-style) > * New WikiAdmin plugins to administrate selectable pages > ("Page Explorer"), for Rename, Search & Replace. > * New other plugins: > UpLoad: Basic UpLoad support by a special Upload: interwiki map > by NathanGass <ga...@io...>, ReiniUrban <ru...@x-...> and > qubit <rt...@da...> > IncludeSiteMap: A combination of IncludePage and SiteMap > RichTable: Allow rich formatting in table cells, See RichTablePlugin > by Sameer D. Sahasrabuddhe Nocache: Prevent certain pages from caching. WikiPoll: Simple configurable poll > * Basic Japanese language support (no pgsrc yet), > by Tadashi Jokagi <web...@el...> > * PhpWiki as PostNuke module improved, by Jason Potkanski (electrawn) > * Allow inlining of images from a InterWiki url, for Upload support > * [Upload:my_image.gif] inlines the image, > * Upload:my_image.gif shows a plain inter-wiki link, > * [what a pic|Upload:my_image.gif] shows a named inter-wiki > link to the gif > * [Upload:my_image.gif|what a pic] shows a inlined image > linked to the page "what a pic" > * New WikiGroup class enabled with the backends: > NONE, WIKIPAGE, DB, FILE, LDAP > (needed for page permissions in 1.4.0) > > Internally: > * a session holds more user information than before. > * htmlarea3 was tested. Seems to be too complicated to fit > into the current usage policy. Only HTML can be written back from the > textarea, and a HTML => Wiki format converter seems to be hard > to write, esp. full roundtrips. Partial support (HTML PageType) > seems to be against PhpWiki spirit. Use Guiki instead for now. > * fpdf was tested to support PDF dumps (not yet enabled), > * A SpellCheck feature was tested (not yet enabled), > * moved interwiki.php code to PageType.php > * internal _AuthInfo plugin to see the current auth settings. > * intermediate InterWikiSearch revamp. (not yet working) > * working on a dynamic upgrader > (update pgsrc, enable new features, update deprecated features, ...) > * working on a dynamic installer > (initial work by electrawn for PostNuke) > * UserPreferences has some options enabled, which do not work yet > (notify by email, email check) > > Fixed Bugs: > * Revived WikiAdminSelect and WikiAdminRemove, > * Fixed XHTML dumps (wrong basepage, recursion detection), > * ADODB limit code * Fixed "\r\r\n" EOL on serial dumps on Windows servers. * Workaround for uploading problems on certain environments. * POST->GET args handling improved to get rid of warnings (sortby buttons and others) > ReiniUrban <ru...@x-...> -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Dan F <dfr...@cs...> - 2004-03-09 17:12:13
|
Reini Urban wrote: > Steve, > I think we are ready now for 1.3.8. So any updated plans for releasing 1.3.8? Are there things people could help with? Again, I am not demanding any particular release time, and I'm grateful for the existence of phpwiki. I'd just like to make sure that releasing doesn't fall off the radar, and I've seen a lot of non-release traffic lately (including my own). Dan -- Dan Frankowski dfr...@cs... 612-626-8396 |
|
From: Reini U. <ru...@x-...> - 2004-03-09 17:38:47
|
Dan F schrieb: > Reini Urban wrote: >> Steve, >> I think we are ready now for 1.3.8. > > So any updated plans for releasing 1.3.8? Are there things people could > help with? > > Again, I am not demanding any particular release time, and I'm grateful > for the existence of phpwiki. I'd just like to make sure that releasing > doesn't fall off the radar, and I've seen a lot of non-release traffic > lately (including my own). As soon as auth and prefs work for other people, esp. on the two sf.net installations. http://phpwiki.sf.net/demo and http://phpwiki.sf.net/test on my other test installations it works fine. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: <ce...@da...> - 2004-03-09 18:28:28
|
I am working on french translation. When it will be OK, must I use the CVS to submit the files or use another way? Don't wait for me for the 1.3.8. Is there any french speakers here? To validate my translation and test? Cédric -- > informaticien qui tire à l'arc ou archer qui informatise? > http://plcoder.net |
|
From: Reini U. <ru...@x-...> - 2004-03-09 19:15:32
|
Cédric Girard schrieb: > I am working on french translation. When it will be OK, must I use the CVS > to submit the files or use another way? Put it either into the sf.net patch tracker (preferred), or sent it to this list. > Don't wait for me for the 1.3.8. > Is there any french speakers here? To validate my translation and test? I can do the tests. The other translators are in the fr.po header, with email. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Roland <rol...@fr...> - 2004-03-10 12:55:32
|
Reini Urban wrote: > Cédric Girard schrieb: >> I am working on french translation. When it will be OK, must I use the CVS >> to submit the files or use another way? > > Put it either into the sf.net patch tracker (preferred), or sent it to > this list. > > > Don't wait for me for the 1.3.8. >> Is there any french speakers here? To validate my translation and test? Si tu veux je peux te faire une relecture, je n'ai pas le temps en ce moment de poursuivre la trad... > I can do the tests. > The other translators are in the fr.po header, with email. |
|
From: Arnaud F. <ar...@cr...> - 2004-03-14 10:10:49
|
Le mer 10/03/2004 =E0 13:43, Roland a =E9crit : > >> Is there any french speakers here? To validate my translation and test= ? >=20 > Si tu veux je peux te faire une relecture, je n'ai pas le temps en ce=20 > moment de poursuivre la trad... Je peux aussi relire et filer un coup de main. Tu peux aussi poster les trad. des pgsrc sur CraoWiki ... la trad. collaborative marche bien l=E0 bas :) (http://wiki.crao.net/) --=20 Arnaud Fontaine Jabber: sh...@ra... ICQ: 3504789 |
Thanks for helping keep SourceForge clean.
X