Menu
▾
▴
phpwiki-talk
|
From: Steven M. <st...@mu...> - 2002-01-12 01:32:09
|
Thanks for the help Jeff and Lawrence. At 11:59 11/01/02 -0800, you wrote: >On Fri, 11 Jan 2002 19:33:25 -0000 >"Lawrence Akka" <Law...@th...> wrote: > > > Actually, Jeff, if you delete HomePage, all the Virgin pages are >reloaded > >Aha! Yes, of course. I think Lawrence has got it :-) Someone (16-181.E.dial.o-tel-o.net/212.144.16.181) deleted the contents of HomePage and saved the changes. It then seems that if HomePage is either empty or not present (I'm not even sure if there is a distinction between these two), then all the original files are loaded from pgsrc. When I was upgrading from 1.2 to 1.3, I had problems importing serialised files, so instead I overwrote the files in pgsrc which were either new, or updated from the 1.2 base package. Then when I first started PhpWiki the files were loaded properly. Since then I had simply forgotten about them, but when the HomePage was emptied today, these were reloaded. Fortunately the replacement files in pgsrc were loaded on top of the existing (more up to date pages), so I lost nothing. All I had to do was bring every page, which was in the 1.2 wiki but had been updated since it was imported, back one version. Since my Wiki is small this was not major undertaking and is now complete. I agree that this is an undesirable feature, so while there are long term solutions for this, in the short term I think some remedial action is necessary on any "live" PhpWiki 1.3 sites. One possibility is to lock the HomePage, but I would rather not do that for my site, and also I can't unlock locked pages (has this been fixed, I'm using quite an old version with a few random patches?). My solution has been to empty all contents from pgsrc, except from HomePage itself, then if HomePage is deleted, it will be replaced by the original, but no other pages are affected. Also I set the pgsrc/HomePage to contain a message stating the site was undergoing technical difficulties and to contact me, hence if HomePage is wiped I would hopefully get an email, then I could restore HomePage and the rest of the Wiki would be unchanged. Do you think it would be worthwhile to send out a "security announcement" or similar covering this feature? While my Wiki is small, if this were to happen to a large Wiki then there would be a lot of work restoring it. I know there aren't that many 1.3 Wikis about, and they should be regularly backed up, but there are a few out there and this feature allows a malicious user to cause a significant amount of damage to the site. This is just a suggestion so feel free to ignore it. Also does anyone know how 1.2 will respond to this type of action? I have no idea who deleted HomePage, I don't know anyone on that ISP. I'm also not sure whether they made a mistake or were being malicious, although the fact that he/she deleted the HomePage twice does make me suspicious. Never mind, no harm done. >When one upgrades to a new release of PhpWiki, in general one does not >want to replace most of the pgsrc. On the other hand, sometimes upgrading >PhpWiki will break some of the "magic pages" (PhpWikiAdministration, >RecentChanges, TitleSearch, etc...) If each page in the distributed pgsrc >had a pgsrc_version meta-data, then there could be an option to only >update the page if the pgsrc_version is greater than that currently in the >database. (The "major" part of pgsrc_version should be incremented when >there are functional changes to the page, the "minor" version gets bumped >everytime the pgsrc is modified.) This would be a very good feature. When upgrading from 1.2 to 1.3 I spent some time working out which pages in my 1.2 wiki should be transferred over, which should be replaced by those in the 1.3 package, and those which should be based on 1.3 pages, but have the same changes added to them which I had made to the 1.2 pages. Any features which would help in this process would be greatly appreciated. Thanks again, Steven. -- email: st...@mu... web: http://www.murdomedia.net/ PGP/GnuPG keys: http://www.murdomedia.net/keys.html |
|
From: Jeff D. <da...@da...> - 2002-01-12 02:27:02
|
On Sat, 12 Jan 2002 01:31:59 +0000 "Steven Murdoch" <st...@mu...> wrote: > Do you think it would be worthwhile to send out a "security announcement" > or similar covering this feature? I think you just announced it. :-) A public wiki is a public wiki. By definition, anyone is allowed to edit it. An attacker could write a fairly trivial script which would overwrite every page in your wiki (repeatedly). The only real defense against this is good backups. (Furthermore, 1.3 is really, truly still alpha code --- even more reason for backups.) I make daily backups of my wikis, and suggest that everyone who runs a wiki with anything important on it should do the same. I suppose we should add a note in the README. On the other hand, this certainly is a bug, and it does provide an entirely too easy way to trash a wiki. Lawrence's suggestion of implementing an "undo" function which would undo all recent edits from a particular host would help in this situation. Your fix of removing all but HomePage from pgsrc is a good one. Alternatively, to get the same effect without deleting files: (after the wiki is initialized) one can edit index.php as set PGSRC to "pgsrc/HomePage". > Also does anyone know how 1.2 will respond to this type of action? I think 1.2 is safe. (Blank pages are not treated as "deleted" in 1.2.) |
|
From: Adam S. <ad...@pe...> - 2002-01-13 01:34:00
|
> (Furthermore, 1.3 is really, truly still alpha code --- even more reason > for backups.) something i'd been thinking about. i'd like to see a stable release of 1.3 in the nearish (weeks to months?) future as it has a lot of features and improvements in it that i'd like to use, but i need something that has been cleaned up and debugged a little more then the current alpha? what are peoples thoughts on the timeline for this? do we have a tenative roadmap for what features we're trying to get ready for the next stable release? adam. |
|
From: Reini U. <ru...@x-...> - 2002-01-13 12:51:31
|
Adam Shand schrieb: > what are peoples thoughts on the timeline for this? do we have a > tenative roadmap for what features we're trying to get ready for the > next stable release? imho it's almost ready. 1-2 weeks? -- Reini Urban http://atelier.akbild.ac.at/ (soon) http://xarch.tu-graz.ac.at/home/rurban/ (big) http://tv.mur.at/ (kulturelles) |
|
From: Jeff D. <da...@da...> - 2002-01-13 18:38:46
|
On Sun, 13 Jan 2002 12:51:26 +0000 "Reini Urban" <ru...@x-...> wrote: > Adam Shand schrieb: > > what are peoples thoughts on the timeline for this? do we have a > > tenative roadmap for what features we're trying to get ready for the > > next stable release? Are we talking about try to release a useable 1.3.x "development snapshot", or are we talking about a 1.4 release? (A 1.4 release implies that there will one more branch of code for us to maintain.) > > imho it's almost ready. 1-2 weeks? Maybe, if we declare a feature freeze, and only work on testing, fixing bugs, and a strict set of tasks deemed necessary for release. Off the top of my head, some things I think we really need before a 1.4 release: Forms based login. We don't necessarily have to implement any more functionality than we have now (admin login & bogo-login), but the HTTP-auth based login mechanism is not available to everyone, and I think we need to get to where every wiki admin can use the admin functions on their wiki. I'd like to clean up the default phpwiki.css a bit. Either implement a kludgy fix for known PEAR bugs (I think probably by including our own version of PEAR code in the distrib) or convert to ADODB (or some other) not-so-buggy DB lib. More testing. We/I really need to write more (some) unit tests, etc... (I have a hard time getting very enthusiastic about it though, so don't hold your breath...) Code cleanup. Experimental, not-fully functional code (mostly I'm thinking plug-ins here) should be removed from (or disabled in) the stable dist. There's some other code (e.g. lib/Toolbar.php) that's still in transition --- it would be nice to stabilize these before a release. So, I guess I think we can do it but it will take a deliberate decision to do so, as well as a fair amount of effort. I guess the fact that we've already converted the PhpWiki wiki to 1.3 indicates that it is time... |
|
From: Adam S. <ad...@pe...> - 2002-01-13 21:29:14
|
> Are we talking about try to release a useable 1.3.x "development > snapshot", or are we talking about a 1.4 release? (A 1.4 release implies > that there will one more branch of code for us to maintain.) i was talking about a 1.4 release, something that people could use in production services. i'm really enjoying watching the improvements being made in the 1.3 tree though. this was more a question of "should i wait for 1.4 or should i just plunge in and deal with 1.3 cause 1.4 is a long way away :-). > Forms based login. We don't necessarily have to implement any more > functionality than we have now (admin login & bogo-login), but the > HTTP-auth based login mechanism is not available to everyone, and I think > we need to get to where every wiki admin can use the admin functions on > their wiki. i think this would be very nice to have. when this happens does that mean that we will be storing metadata about usernames? eg. could the config file now contain an list of usernames that have admin privledges? > More testing. We/I really need to write more (some) unit tests, etc... > (I have a hard time getting very enthusiastic about it though, so don't > hold your breath...) i'm not (much of) a programmer, but i will be happy to install and test everything i can think of. > Code cleanup. Experimental, not-fully functional code (mostly I'm > thinking plug-ins here) should be removed from (or disabled in) the stable > dist. There's some other code (e.g. lib/Toolbar.php) that's still in > transition --- it would be nice to stabilize these before a release. yep i think that'd be cool. as a side note, i was quietly (and slowly) working on an upload file mechanism when i saw a discussion on this on the wiki which involved restructuring the wikidb. my simple approach to the problem was to write two plugins. UploadFile which allows a file to be uploaded to PageName/filename via a simple form, and another plugin called ShowAttachments which shows all the files attached to the current page (by simply doing a listing of the directory which matches the current page name). is it worth me continuing to work on this? the idea discussed on the wiki seemed much more complete but also like it was probably a ways off in the future. > So, I guess I think we can do it but it will take a deliberate decision to > do so, as well as a fair amount of effort. I guess the fact that we've > already converted the PhpWiki wiki to 1.3 indicates that it is time... fwiw, the other things i'd like to see would be: * allow html on locked pages (useful for the admin to embed forms etc) * standardize on a wiki syntax. if we're going to change the standard wiki syntax (i think some of the discussions on this were a "good thing") then the sooner those changes are made the better (saving painful upgrades for people in the future. once again, that's for all the hard work guys, phpwiki is great! adam. |
|
From: <ph...@de...> - 2002-01-28 18:45:02
|
On 13 Jan 2002 13:28:56 -0800, Adam Shand <ad...@pe...> wrote: => i was talking about a 1.4 release, something that people could use in => production services. i'm really enjoying watching the improvements => being made in the 1.3 tree though. this was more a question of "should => i wait for 1.4 or should i just plunge in and deal with 1.3 cause 1.4 is => a long way away :-). I've been wrestling with the same question for some time now and it sounds like 1.3 is the answer as 1.4 has more to do. As a wiki-lover and user (and not one of the developers), I'd like to see freezing 1.3.x and rolling it to 1.4, dropping status/support from 1.2 and moving to release of 1.4 as non-alpha code. Thanks to all for such a great system. Cheers, - Don |
|
From: Preston L. B. <pre...@sp...> - 2002-01-28 19:17:13
|
Anyone running phpwiki on Win32? If so what versions of phpwiki, PHP and (perhaps) MySQL are you using? Running the latest phpwiki with PHP 4.1.0 caused a fault in PHP(!). Running with the newer Versions I'm using (unsuccessfully) on Windows 2000: PHP 4.1.1 mysql Ver 11.15 Distrib 3.23.47, for Win95/Win98 (i32) Error from running PhpWiki 1.2.2: ----- Warning: Failed opening 'lib/mysql.php' for inclusion (include_path='..') in C:\tools\phpwiki-1.2.2\lib\config.php on line 111 Fatal error: Call to undefined function: opendatabase() in C:\tools\phpwiki-1.2.2\index.php on line 14 ----- Error from running PhpWiki 1.3.2: ----- Fatal error: Failed opening required 'lib/ErrorManager.php' (include_path='..') in C:\tools\phpwiki-1.3.2\lib\prepend.php on line 11 ----- Is there a problem with include_path on Win32? I did pull out the current PHP sources from CVS to take a look. Punted after looking at the PHP build workspace/project. Too much rework needed... :). |
|
From: Reini U. <ru...@x-...> - 2002-01-29 00:03:47
|
"Preston L. Bannister" schrieb: > Anyone running phpwiki on Win32? If so what versions of > phpwiki, PHP and (perhaps) MySQL are you using? yes, runs fine on apache-1.3.20 / php-4.0.6 / mysql-3.23.40-max-nt and on on the newest setup msvc apache-1.3.22 / php-4.1.1 (much faster) but fails on the pear session lib with mysql, so i think that there's is a bug in the php mysql session code in 4.1.x. with fs-sessions it works fine. It does work on the latest cygwin apache setup, but I couldn't yet compile libmysql for a newer cygwin. I cvs up daily and it it always runs fine. > Running the latest phpwiki with PHP 4.1.0 caused a fault in PHP(!). -- Reini Urban http://atelier.akbild.ac.at/ (soon) http://xarch.tu-graz.ac.at/home/rurban/ (big) http://tv.mur.at/ (kulturelles) |
|
From: Carsten K. <car...@ma...> - 2002-01-28 23:43:03
|
I'm not sure what the general consensus is about moving to a 1.4 release version. From my view the only remaining requirement I'd like to see met before a 1. 4 release, is updated locale translations. German is complete but Swedish, Dutch, Italian are still at a 1.2 level or slightly above. I don't think an incomplete French translation should hold up a 1.4 release, really it's work has just begun (so there's no need to rush that one). The new block parser and New Wiki Markup is in progress. What else do we have going before another 1.3 release or a 1.4 release? (I'm not necessarily pushing for a 1.4 release myself, just responding to Don's q.) Carsten On Monday, January 28, 2002, at 01:44 pm, ph...@de... wrote: > On 13 Jan 2002 13:28:56 -0800, Adam Shand > <ad...@pe...> wrote: > => i was talking about a 1.4 release, something that people could use in > => production services. i'm really enjoying watching the improvements > => being made in the 1.3 tree though. this was more a question of "should > => i wait for 1.4 or should i just plunge in and deal with 1.3 cause 1.4 > is > => a long way away :-). > > I've been wrestling with the same question for some time > now and it sounds like 1.3 is the answer as 1.4 has more to do. > > As a wiki-lover and user (and not one of the developers), > I'd like to see freezing 1.3.x and rolling it to 1.4, dropping > status/support from 1.2 and moving to release of 1.4 as non-alpha > code. > > Thanks to all for such a great system. > > Cheers, > > - Don |
|
From: Reini U. <ru...@x-...> - 2002-01-29 00:07:24
|
Carsten Klapp schrieb: > I'm not sure what the general consensus is about moving to a 1.4 release > version. not now, after the recent changes. > From my view the only remaining requirement I'd like to see met before a 1. > 4 release, is updated locale translations. German is complete but Swedish, > Dutch, Italian are still at a 1.2 level or slightly above. I don't think > an incomplete French translation should hold up a 1.4 release, really it's > work has just begun (so there's no need to rush that one). > > The new block parser and New Wiki Markup is in progress. yes, this is very new and should settle a bit. > What else do we have going before another 1.3 release or a 1.4 release? -- Reini Urban http://atelier.akbild.ac.at/ (soon) http://xarch.tu-graz.ac.at/home/rurban/ (big) http://tv.mur.at/ (kulturelles) |
|
From: Adam S. <ad...@pe...> - 2002-01-29 01:04:04
|
> > The new block parser and New Wiki Markup is in progress. > > yes, this is very new and should settle a bit. i just wanted to say thanks to everyone. i just checked the new block parser out yesterday and it's amazing, i especially like the new table syntax. thanks! adam. |
|
From: Jeff D. <da...@da...> - 2002-01-29 05:00:29
|
> From my view the only remaining requirement I'd like to see met before a 1.> 4 release, is updated locale translations. German is complete but Swedish,> Dutch, Italian are still at a 1.2 level or slightly above. I don't think > an incomplete French translation should hold up a 1.4 release, really it's > work has just begun (so there's no need to rush that one). Actually, the translations are the one thing that, I think, shouldn't hold up the release. It's great if the translations are up-to-date, but, if I were a translator, I would wait for a stable release _before_ really working hard to clean up the translations. The translations can always be updated in 1.4.n. > The new block parser and New Wiki Markup is in progress. Yes, and I've just about got a new inline markup parser working too. I think we should wait awhile (month or two?) to make sure we all agree on just what the new markup syntax should be. |
|
From: <ph...@de...> - 2002-01-29 18:56:31
|
On Mon, 28 Jan 2002 21:00:22 -0800, Jeff Dairiki <da...@da...> wrote: => Yes, and I've just about got a new inline markup parser working too. => I think we should wait awhile (month or two?) to make sure we all agree => on just what the new markup syntax should be. <groan>. Looks like it's 1.3.x for my base now (and a bunch of hacking ahead, to be forever cemented-in). Has 1.3.x been updated to not require PHP module authentication for some of us on shared servers who use PHP running CGI "wrapped" for security? I love phpWiki but I sure wish we could have more "stable" versions and a less lengthy open-for-development alpha code stretch. I don't mean to be rude, I really do thank everyone very much for all their efforts on behalf of the unwashed WikiMasses like me, but how about putting new major markup changes into the next major release level? This is such a great system, it's hard to wait for months to be able to grab a stable version to use as a base for real life. Guess I shouldn't look the gifthorse in the mouth but alpha code is only fun for the developers. Please forgive the rant. Thanks, - Don |
|
From: Adam S. <ad...@pe...> - 2002-01-29 21:04:29
|
> I love phpWiki but I sure wish we could have more > "stable" versions and a less lengthy open-for-development alpha > code stretch. I don't mean to be rude, I really do thank everyone > very much for all their efforts on behalf of the unwashed > WikiMasses like me, but how about putting new major markup > changes into the next major release level? nnnoooooooo! :-) 1.3 really hasn't been around that long. i think getting the wiki markup and new parsing engine going is an important thing to happen before another stable release. otherwise it's just that many more people that are going to have to go through a major overhaul on their web site. > This is such a great system, it's hard to wait for months > to be able to grab a stable version to use as a base for real > life. Guess I shouldn't look the gifthorse in the mouth but > alpha code is only fun for the developers. i have yet to put phpwiki into production for myself but i've played with it a lot and run several 1.3 wiki's for other people and its been pretty uneventful. also upgrading is fairly painless, if you keep all the libs out of the DocumentRoot (which you should do anyway) and use a seperate directory for your databases (or use sql). just untar the source into /var/lib/phpwiki-1.3.4 (or whatever) and then change the pointers in index.php to point to the new location. if it causes problems just roll back. if you want to be really careful copy index.php to testwiki.php and change that first. that way you can test it out without interrupting your live wiki. i know it's not ideal, and i'm looking forward to a stable release as well, but *good things* are happening, lets not ruin our wonderful developers momentum :-) adam. |
|
From: <ph...@de...> - 2002-01-29 22:12:14
|
On 29 Jan 2002 13:03:16 -0800, Adam Shand <ad...@pe...> wrote: => nnnoooooooo! :-) 1.3 really hasn't been around that long. i think => getting the wiki markup and new parsing engine going is an important => thing to happen before another stable release. otherwise it's just that => many more people that are going to have to go through a major overhaul => on their web site. OK, you're probably right. => i have yet to put phpwiki into production for myself but i've played => with it a lot and run several 1.3 wiki's for other people and its been => pretty uneventful. Uneventful is nice especially when it's still labeled as alpha code. => also upgrading is fairly painless, <snip step by step> Thanks for the instructions, appreciated. => i know it's not ideal, and i'm looking forward to a stable release as => well, but *good things* are happening, lets not ruin our wonderful => developers momentum :-) Well, that's really the ultimate criterion: I do _not_ want to do anything to stifle or trip-up the developers. I wasn't really going to post and perhaps I shouldn't have. It is a great little app; I'd just like to get it into some sort of stable production on a couple of things without missing too much of the future and without waiting too long. <sigh> Thanks to all the developers. phpWiki is great and getting even better thanks to your efforts - they are appreciated. Take your time, anytime next week will be fine <g>. Cheers, - Don |
|
From: <ph...@de...> - 2002-01-29 22:25:51
|
On Tue, 29 Jan 2002 11:47:15 -0800, Jeff Dairiki <da...@da...> wrote: => The latest CVS code (as of last week, I think) should work. I have not => tested it (except under mod_php), nor have I heard any reports (success or => failure) about it. Thanks, but I get nervous about "latest CVS" copies. I can barely spell CVS and I really don't know when to dip into that river, nor what to expect. => (There's still no real user authentication. But bogo-logins (or signins) => and admin logins should work...) Ok, thanks. => I'm not sure I understand the rest of your comments. Sorry. => I get the idea that you are not happy with the current state of PhpWiki affairs, Just the release schedule and that's just chomping at the bit on my part. Open-ended feature sets make me nervous when I'm an expectant enduser. => but I don't think I understand why very well. Could you try restating your => complaints/suggestions/requests? I have no complaints whatsoever, you folks have done a terrific job with phpWiki and I love the install I've hacked from the 1.2 path. On requests: I was pushing for a stable release soon, as it sounds to me like a whole new great-leap-forward is happening now ... exciting but linear-time-consuming is how it sounds. I have to pick something fairly soon as a new stable base to then include some of my enduser-specific hacks from 1.2 and I'm not as likely to be able to do this line-in-the-sand again for some quite a period of time. Suggestions: ignore me and stay creative. I'll find a way to get by. I'll just grumble to myself about how the world could be a better place if volunteer,non-paid phpWiki developers would just take even less time sleeping and spend more time coding like they should <g>. Thanks for everything, - Don |
|
From: Steve W. <sw...@pa...> - 2002-01-29 22:35:16
|
On Tue, 29 Jan 2002 ph...@de... wrote:
> I have no complaints whatsoever, you folks have done a
> terrific job with phpWiki and I love the install I've hacked from
> the 1.2 path.
I'm sure all the developers appreciate this, Don! Thanks.
> On requests: I was pushing for a stable release soon, as
> it sounds to me like a whole new great-leap-forward is happening
> now ... exciting but linear-time-consuming is how it sounds.
>
> I have to pick something fairly soon as a new stable base
> to then include some of my enduser-specific hacks from 1.2 and
> I'm not as likely to be able to do this line-in-the-sand again
> for some quite a period of time.
>
> Suggestions: ignore me and stay creative. I'll find a
> way to get by. I'll just grumble to myself about how the world
> could be a better place if volunteer,non-paid phpWiki developers
> would just take even less time sleeping and spend more time
> coding like they should <g>.
And I'm sure they appreciate the humor :-)
It's an understatement to say I've admin'd this project loosely over the
last six or so months (even an understatement to say I've admin'd it!) But
I've really enjoyed all the energy being poured into PhpWiki and I'm
reluctant to stop it now with milestones and release dates. However, it's
not too farfetched to agree on what features we will wait for before 1.4
is released (2.0 is more likey the version number).
That said, are we ready for a 1.3.3 yet before the new parser is
incorporated?
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
|
|
From: Reini U. <ru...@x-...> - 2002-01-30 01:34:08
|
Steve Wainstead schrieb: > That said, are we ready for a 1.3.3 yet before the new parser is > incorporated? sure. the new parser works fine enough for me, the interface also. i would consider it stable enough, BUT ... (you know Jeff and Carsten) they are in terrible good flux now and a lot of plugin's are still waiting. re parser: still missing are block level tags, like <nowiki> linebreak(s) </nowiki> and such, for easily pasting code. BTW: I use the daily updated alpha CVS version for my stable and public wiki. there's no major error or flaw, it's just getting and better. -- Reini Urban http://atelier.akbild.ac.at/ (soon) http://xarch.tu-graz.ac.at/home/rurban/ (big) http://tv.mur.at/ (kulturelles) |
|
From: Carsten K. <car...@ma...> - 2002-01-29 22:35:47
|
Hi Don, The latest 1.3 uses a regular web page with an input form for logins instead of the old http authentication method. As before, only the admin has a password. Does this address the authentication problem with the cgi version of php you had? What kind of hacks do you have in your 1.2, anything worth sharing? Or any new features we might consider adding in at some point? :-) Carsten On Tuesday, January 29, 2002, at 05:25 pm, ph...@de... wrote: > > I have to pick something fairly soon as a new stable base > to then include some of my enduser-specific hacks from 1.2 and > I'm not as likely to be able to do this line-in-the-sand again > for some quite a period of time. |
|
From: <ph...@de...> - 2002-01-30 00:24:40
|
On Tue, 29 Jan 2002 17:35:26 -0500, Carsten Klapp <car...@ma...> wrote: => The latest 1.3 uses a regular web page with an input form for logins => instead of the old http authentication method. As before, only the admin => has a password. Does this address the authentication problem with the cgi => version of php you had? Sorry, haven't really looked too terribly closely at the details of 1.3 as I was waiting with hope for the next release and 1.3 has so far always been referred to as alpha code. My current phpWiki uses straight standard Apache .htaccess control for http server access to the entire site (directory level) and also separately for more limited access to the admin.php file itself. BTW, I was looking to tack on a front end for user verification and really liked the way it looked as running inside PostNuke (www.postnuke.org). For several reasons (including use on shared servers), I'm restricted to PHP as CGI as a standard but I run it "wrapped" under my user to closely control its use by Apache. => What kind of hacks do you have in your 1.2, anything worth sharing? Or any => new features we might consider adding in at some point? Thanks for asking. Most of what I've done is user-specific style, layout and formatting, with a few minor hack bits thrown in for navigation as well. Nothing really that ports, I'm afraid. Look and feel stuff. Biggest formatting change is to move almost all the links etc to the left side of each page (table) which makes the wiki easier to navigate IMO, especially for new visitors. Whitespace and page blocking is important IMO, the standard Wiki is too text-dense on the page. Sorry I don't have a publicly visible example of my formatting changes at the moment. One complaint I encountered with my user base was that the navigation (outside of the wiki text itself) was not up to their expectations and not standardized. The other "complaint" was that it was just too egalitarian: "whaddayamean I can just type in changes to this page right here and now?" Cheers, - Don |
|
From: Adam S. <ad...@pe...> - 2002-01-30 00:58:06
|
> Thanks for asking. Most of what I've done is > user-specific style, layout and formatting, with a few minor hack > bits thrown in for navigation as well. Nothing really that ports, > I'm afraid. Look and feel stuff. would you mind mailing a url to a screenshot or something? i'm curious what you've done. > Biggest formatting change is to move almost all the links > etc to the left side of each page (table) which makes the wiki > easier to navigate IMO, especially for new visitors. Whitespace > and page blocking is important IMO, the standard Wiki is too > text-dense on the page. Sorry I don't have a publicly visible > example of my formatting changes at the moment. i run a public wiki and had similar complaints from users and concerns from myself. one of the biggest things i didn't/don't like was that with the standard wiki "look and feel" is that there is no site consistancy. it's very space efficient which is great when you are are familiar with the site but for people who found a page on our site from another site (or google) they had no idea what we, as a whole, were about and there was no immediately obvious way for them to find out. you can see the really ugly hack i did to moinmoin here: http://www.personaltelco.net/ my long term goal on what i will do is have a a small navigation bar across the top and bottom (edit, like pages, spell check, attach file etc) and then down teh side have the equivelent of slashboxes for these things: * if not logged in get an intro to wiki box (welcome, yes your supposed to be able to edit the pages and please do ... responsibly). * if they are logged in the get the last X number of recent changes or maybe full recent changes or recent edits. * the X most popular wiki pages * the list of categories on the wiki (eg CategoryCategory) other ideas for boxes: * relevant rss/rdf feeds from other sites (weblogs, wiki's etc) * a page status box (number of pages, hits/minute/etc ... geek stuff) * maybe a calendar with upcoming events * maybe a list of the X most active wiki users (friendly competition can be a good motivator :-) * an rdf/rss of the last X messages from our mailing list (i don't know why no one has written a parser for mailman yet) * a unified recent changes for all of the other community networking groups * recent changes from our node map database * the list goes on and on :-) ideally all of these boxes would be imported from rss/rdf sources and parsed with something like fase4php. even more ideally all of this would be configurable on a per user basis (to control which or if there are any boxes). so ... there's my grand scheme of things that i'm slowly working towards, i'd love to hear about what you're trying to achive and what you've done so far to get there. our wiki is a crucial part of the personal telco community (in someways it's built stronger ties then our mailing list, though it has built much fewer). it's also our main presence to the world which is important as well. adam. |
|
From: <ph...@de...> - 2002-01-30 18:32:20
|
On 29 Jan 2002 16:56:52 -0800, Adam Shand <ad...@pe...> wrote: => would you mind mailing a url to a screenshot or something? i'm curious => what you've done. <snip> => i run a public wiki and had similar complaints from users and concerns => from myself. one of the biggest things i didn't/don't like was that => with the standard wiki "look and feel" is that there is no site => consistancy. it's very space efficient which is great when you are are => familiar with the site but for people who found a page on our site from => another site (or google) they had no idea what we, as a whole, were => about and there was no immediately obvious way for them to find out. => you can see the really ugly hack i did to moinmoin here: => http://www.personaltelco.net/ You did a very nice job with yours and one can see by the content how well it's working for you. My changes don't improve over yours, except perhaps in one area: I use a light pastel type color for the background on the left column, the right title area, the bottom non-content area, *and* a small right hand empty column (tables) to visually frame the content - this "pops" the content up into view more and pushes the non-content back down a bit as well, and it gives more white space all around the content, making it appear less dense (which is a good thing). I really like what you've done. Your cute little icons are nice as well and you might add a little "home" icon for your front page (as I think many folks like to start over easily from deep within content - and yes i did the same logo link in the upper left corner but you need to know that's a home link - what a long parenthetical comment, oh well....). Only other thing I did was to put two very prominent EditText-type links in the left column to make it real easy and obvious how to update the page. You did a nice consistent job with the edit page as well. It seems like no matter what one does however, it's still much too geeky. Finally, (with your indulgence) I like your logo but if it were mine I'd shrink it down a bit to take up less of the prime screen area. It does provide a good graphic consistency from one page to the next. I like what you've done and gotten a couple ides for some that I'd like to do as well. I'll see where the "stable" daily CVS is on the day I pull the phpwiki-lottery handle and go from there. Thanks for the link. i think it helps to see how different folks are formatting Wikis. I completely agree with your other comments on look-and-feel. Cheers, - Don |
|
From: Lawrence A. <la...@us...> - 2002-01-14 18:19:20
|
At 21:28 13/01/2002, Adam Shand wrote: > > So, I guess I think we can do it but it will take a deliberate decision to > > do so, as well as a fair amount of effort. I guess the fact that we've > > already converted the PhpWiki wiki to 1.3 indicates that it is time... > >fwiw, the other things i'd like to see would be: > > * allow html on locked pages (useful for the admin to embed forms etc) > * standardize on a wiki syntax. if we're going to change the standard > wiki syntax (i think some of the discussions on this were a "good > thing") then the sooner those changes are made the better (saving > painful upgrades for people in the future. Yes please (the latter)! I would not like to see a release with the old syntax, if we are then going to convert to the new syntax. Better to get all major changes out of the way at once I have done a large amount of thinking (but not much coding) about parsers etc, and the way in which NewWikiMarkup could be implemented. I have even tried to create (not very successfully) a BNF syntax for WikiMarkup. I would be happy to help with the code. Lawrence |
|
From: Jeff D. <da...@da...> - 2002-01-14 19:57:24
|
On Mon, 14 Jan 2002 18:19:16 +0000 "Lawrence Akka" <la...@us...> wrote: > At 21:28 13/01/2002, Adam Shand wrote: > > > * standardize on a wiki syntax. if we're going to change the standard> > wiki syntax (i think some of the discussions on this were a "good> > thing") then the sooner those changes are made the better (saving> > painful upgrades for people in the future. If we are going to make major changes to the syntax (i.e. changes which aren't more-or-less backward compatible with the current syntax) I think this is going to take quite a bit longer than a couple-three weeks to do right. (If making a big switch like that, it should be done right: lots of alpha/beta testing before switching syntax in a stable release.) > I have done a large amount of thinking (but not much coding) about parsers > etc, and the way in which NewWikiMarkup could be implemented. I have even > tried to create (not very successfully) a BNF syntax for WikiMarkup. I > would be happy to help with the code. Let's hear/see your ideas (and or code). (Maybe post them here, or start (yet )a(nother) wiki page...) If we want a 1.4 release within weeks however, I suspect the only workable plan is to stick with the current transform code. Incremental, backward-compatible markup "improvements" (e.g. *bold*, and probably even <pre></pre>) could probably be hacked into the current transform code in that timeframe. Also, if we want a 1.3 release within weeks, we will have to decide to do it. I'm going to start a page at http://phpwiki.sf.net/phpwiki/Release1.4 in order to take a bit of a vote on how soon and what features should be in the next release. |
×
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