Revision [2985]
This is an old revision of WikkaDevelopment made by JamesMcl on 2004-12-08 21:54:18.
Wikka Development
CategorySystemOverhaul
Things in the next release
I'm planning on putting out a small bugfix release within the next few days. If you have something that you would like to see in this release, make a note here and I'll take a look at it. -- JsnX, 26 Nov 2004Things to be fixed before releasing wikka-1.1.6.0:
Here's some sparse thoughts from a first test of the beta version:- We should update the infos on syntax highlighting in the default FormattingRules page
- Why not adding ReleaseNotes as a default page (or at least the section on what's new in the last version). As an alternative, (minimal solution) we might add a link to the ReleaseNotes page on the wikka server;
- We should create a default page called WikkaDocumentation containing the following code (in the future it will contain the actual documentation or a plugin to fetch remote documentation):
===== Wikka Documentation ===== A comprehensive and up-to-date documentation on Wikka Wiki can be found on the [[http://wikka.jsnx.com/HelpInfo main Wikka server]]
- I propose we update the default HomePage to display the version number, a ReleaseNotes what's new link pointing to the ReleaseNotes and a link to WikkaDocumentation. Here's my source code proposal for the new default HomePage
=====Welcome to your Wikka site! ===== Thanks for installing [[Wikka:HomePage WikkaWiki]]! This site is running on version [[ReleaseNotes 1.1.6.0]] Double-click on this page or click on the "edit page" link at the bottom to get started. Also don't forget to visit the [[Wikka:HomePage WikkaWiki website]]! Useful pages: FormattingRules, WikkaDocumentation, OrphanedPages, WantedPages, TextSearch.
- BTW a stupid action for printing in the body of a page the current Wikka version as declared in the config file might be useful;
- If Nils is ready with the new version in a couple of days, replace the current FormattingRules with an more structured page.
- Do we still need two different actions colour/color ? I would drop the British one.
- Shouldn't we announce in the ReleaseNotes that the raw handler has been modified?
- bug: the feedback action still contains bad code that prevents it from working on installs with no rewriterules: the <form> tag must be replaced with the appropriate call to $this->FormOpen():
original
$form = '<p>Fill in the form below to send us your comments:</p>
<form method="post" action="'.$this->tag.'?mail=result">
Name: <input name="name" value="'.$_POST["name"].' "type="text" /><br />
Email: <input name="email" value="'.$_POST["email"].'" type="text" /><br />
Comments:<br />
<textarea name="comments" rows="15" cols="45">'.$_POST["comments"].'</textarea><br />
<input type="submit" value="Send" />
</form>';
<form method="post" action="'.$this->tag.'?mail=result">
Name: <input name="name" value="'.$_POST["name"].' "type="text" /><br />
Email: <input name="email" value="'.$_POST["email"].'" type="text" /><br />
Comments:<br />
<textarea name="comments" rows="15" cols="45">'.$_POST["comments"].'</textarea><br />
<input type="submit" value="Send" />
</form>';
modified
$form = '<p>Fill in the form below to send us your comments:</p>'.
$this->FormOpen().
'\nName: <input name="name" value="'.$_POST["name"].'" type="text" /><br />'.
'\n<input type="hidden" name="mail" value="result">'.
'\nEmail: <input name="email" value="'.$_POST["email"].'" type="text" /><br />'.
'\nComments:<br />\n<textarea name="comments" rows="15" cols="40">'.$_POST["comments"].'</textarea><br / >'.
'\n<input type="submit" value="Send"/>'.
$this->FormClose();
$this->FormOpen().
'\nName: <input name="name" value="'.$_POST["name"].'" type="text" /><br />'.
'\n<input type="hidden" name="mail" value="result">'.
'\nEmail: <input name="email" value="'.$_POST["email"].'" type="text" /><br />'.
'\nComments:<br />\n<textarea name="comments" rows="15" cols="40">'.$_POST["comments"].'</textarea><br / >'.
'\n<input type="submit" value="Send"/>'.
$this->FormClose();
original
if ($_GET["mail"]=="result") {
modified
if ($_POST["mail"]=="result") {
-- DarTar, 08 Dec 04
[for the next minor release]
- please give us back the "no cache" option on edit pages :)
- Right now, no pages are being cached. So what you really want is for caching to be brought back, with the option to disable it on certain pages, right? It's quite a few changes, so it probably won't be in the upcoming minor release. -- JsnX
- for ease of development, I'd move the SQL instructions for creating the default tables and pages during setup to two external .sql files, the first for table structure, the second for data;
- Good idea. I'll look into the implementation....
- please add ModRewrite in code as a default. --JamesMcl
- Please be more specific. Wikka already works with or without ModRewrite. -- JsnX
- Jason, as I understand it, we have to add a .htaccess file with the code shown in the ModRewrite page.
- Couldn't the wikka installation include this as default and individuals change the config if they didn't want to use the feature rather than the other way around. --JamesMcl
- The .htaccess file is created during the installation, are you experiencing any problem with rewrite rules? --DarTar
- Yes, DarTar it didn't work for me. I notice that the ModRewrite code has been changed recently though. I just thought that the working code could be placed in the installation. Another thought, do you have to change your config file to point to HomePage rather than wikka.php?wakka=HomePage in addition to changing the .htaccess file. If so, then its my fault that it isn't working and I apologise --JamesMcl
- As a general rule you don't need to change anything, just accept the default options set by the installer. I have several local distibutions of wikka installed on my machine, either with or without RR. Here's how the config files look like:
RR on
"root_page" => "HomePage", "base_url" => "http://wokka/", "rewrite_mode" => "1",
RR off
"root_page" => "HomePage", "base_url" => "http://test/wikka-1.1.6.0b/wikka.php?wakka=", "rewrite_mode" => "0",
Hope this helps -- DarTar
- I contacted my isp and they advised me to use
-
/home/www/user/wikka/
- Didn't work though --JamesMcl
[for the next major release]
- skins (with new WikkaSkinOptimization css template);
- HelpInfo documentation shipped with the installation (or maybe IncludeRemote not);
- the whole config thing is something which should be taken care of in my mind, but a look at WikkaBugs array-merge would be nice.
- Can you be more specific about what you mean by "the whole config thing"? I'll throw in the "$wakkaConfig = array();" line. Just not sure what else you mean.
- by the way, what about a highlighter-format? .highlight isn't used :-)
Ideas
Save Pages to PDF Format
Page output to an Adobe pdf file using FPDF.E-mail this page facility
--JamesMcl
Usergroups
Yet another idea from me:
Usergroups. So i can create a group of users, and just write that group into the ACLs...
- Take a look at GroupManagement (which doesn't seem to be finished)"In work" for Wikka-pages
Add a page property, 'Status' [?] that can be used to facilitate code development within Wikka. Imagine a very basic CVS system. A user can change the status to "In use' while considering improvements to the code, and then change it to 'Available' when done. This may prevent this scenario:- Multiple users see the same code and concurrently start working on changes.
- One user posts his changes.
- Another user posts his changes without realizing that the code had been updated.
OR
- Another user has to go back through his code and incorporate the changes made by the first user.
Comments:
Dangerous! Consider the following scenario: user has been hard at work all week, now it's Friday afternoon and there's some time to do an edit or three. User opens each page in a browser tab, marking all three as "in use" and starts to edit them. Clickety-click. Suddenly user realises he has to run to catch the train home. Run! On the train, user realises the three pages are still open in the browser and "in use". "No matter", thinks our user, "it's always quiet during the weekend and I'll get back to it first thing Monday morning. On Sunday afternoon, user plays soccer, as he always does, and breaks a leg, which he usually doesn't do. User is transported to hospital where he has to stay for four weeks. ... A bit exceptional maybe - but what do you do with "dangling in uses" and when (how) are they considered "dangling" in the first place? --JW
Good point, but this modification would be only an informational resource to facilitate user communication. Techically, users could still update the page any time they wanted. It would just be a courtesy to hold back if you saw that a page was 'in use.' I didn't mention it above, but I planned to also add a field that would timestamp when the status was last changed. So in your scenario, we would see that the page had been marked as 'in use' for several days and feel free to ignore it. However, this does bring up the idea that it would be good to also have a 'note' box available for updating the page status -- used for comments such as, "should have the code updated within a few hours." Better now? -- JsnX
I've got code/table changes done that indicate if anybody (other than oneself) opened the page to "edit" in the last 15 minutes. It's on an iteration that isn't "live" right now (it's part of an earlier installation of wikka that we just haven't brought the code forward from yet), but I can make it that way so you can test out the functionality if you want. Since much of our site will be geared towards small teams doing collaborative editing, it was designed so that editing conflicts would not occur. Let me know if you want me to get it installed at a test site. -- GmBowen
I agree, it's an important issue (some Wakka forks have already addressed the problem of concurrent editing) -- DarTar
JsnX: If it's purely informational, that's better; I thought the intention was some kind of locking. So you'd have something like:
- state: in use | available
- timestamp: in use since
- note: applies to the in use state only
Then - would the state apply to the logical page or to a particular version? If the latter, what happens if a page is reverted to that version? What happens to the state when another user goes ahead and edits the page anyway?
And I still think you'd need some kind of admin function to "clear" dangling in use states that are older than xx minutes/hours/days.
GmBowen: is yours completely automatic or user-initiated? What happens in the run off to catch the train scenario? -- JavaWoman
(i) it's purely informational, not a "lock"...it sets a red exclamation mark beside the page name at the top if the "edit" link (or double click) has been used in the last 15 minutes by anybody other than yourself (ii) it's automatic (iii) the "train scenario" can't happen. It doesn't check if "saved" or not, just whether an edit was started in the last 15 minutes. This means that if the person doing the edit hasn't saved in the last 15 minutes when editing then the exclamation mark isn't activated for another user. But, people should save edits every 15 minutes anyways methinks. It's not "foolproof", but was meant to avoid many sorts of common editing conflicts on collaborative documents. It's not a very "big" edit of the wikka code actually. The edit.php script timestamps the most recent version of the page when it is activated, and there's a small addition to header.php that checks when the page is loaded to see if the current time is < 15 minutes from that timestamp & if so shows an exclamation mark. Finally, there's a small linked graphic that "refreshes" the page beside "homepage" and the "edit" link (essentially, it's just a link to the page itself) so a user can check the edit status before deciding to edit it themselves. For server load reasons I decided to not have an automatic check (once every 5 minutes for example) since most people read & don't edit much of the time so it made sense more to encourage people to check edit status themselves. Of course, it would also be possible to have edit.php check to see if the file was edited in last 15 minutes and if so, ask the user if they wanted to continue with their own edit. Hmmm...I'll have to think about that. As it sits it worked pretty well when tested (but remember, I'm into small group collaborative writing tasks....I'm not sure how it would work if the pages were "open" to everyone). It originally took me several hours to write the code myself, but I'm sure it would take JW or DarTar or Jason maybe 30 minutes....and the code would probably be more efficient (I'm not a real coder remember :-( ) -- GmBowen (aka Mike) (I've now provided my code & mods @ [GmBowenRecentEditCheck] for people to play with)
Searching (in) comments
Add the ability to 'search for all comments by user X'. How this might be useful: I want to find a comment by JavaWoman (really?), but I can't remember which page it was on -- she's quite prolific! -- (I admit I'm easily distracted. What am I doing here, now!? :)) so I use this new function to list all of her comments.
Yes. And related: an extension of this or the general search function to search by comments content (in addition to page name or page content) would, I think, be also useful. --JW
Agreed. -- JsnX
Nice idea :). For comments by user X (and, why not, mods by user X) we could imagine something similar to Google syntax for site-restricted queries. E.g.: I18n user:JavaWoman. The scope of the query (pages, mods, comments, anywhere) should be settable as a radio button (similar to Google's restrict search options). FYI, Comments by user X, Pages owned by user X and Changes done by user X were already partially addressed by the following action proposals: UserCommentsAction, UserPagesAction, UserChangesAction -- DarTar
In general....given the complexity (and utility) of some of the conversations now happening in the comments, I think that we should consider either (i) the current textsearch being expanded to include the comments, or (ii) a separate action be written directed at searching the comments table (possibly an easier route). The latter might mean we consider renaming the search pages to SearchText, SearchTextExtended & SearchComments. [I now realize that this "search comments" feature is a "lost" feature. I realize now that earlier versions of this wiki had the comments stored in the pages table and were therefore searched. When they were moved to a separate table, the ability to search comments was lost. (Update: See my GmBowen directory for a (temporary) solution for this....even separates results for comments & pages into two columns) A separate action to list all comments by a user would also be useful. In a related comment on the comments, and given my arguments about the complexity of conversations in some of the comment threads now, I suggest that we also consider developing code for threaded discussions in the comments....which I think will considerably enrich collaborative efforts (such as we engage in). -- GmBowen
Order of the text-search
It would be good if the text-search would be sorted in some way. If I search for example for "GmBowen", a page with the exact match (his userpage) should be on the top of the results. The next results perhaps in alphabetical order? --NilsLindenbergLow priority:
- Add fields to the 'users' table [?] to track when RecentChanges and RecentlyCommented were last viewed. Then RecentChanges and RecentlyCommented can by modified to highlight new items since the user last viewed the page.
If it's only for highlighting, OK, but I'm not waiting for that. If it's for filtering, please no. I quite often trace back several days to re-review pages or comments --JW
OK. Point taken. I was considering doing some form of filtering, but will now only consider higlighting, as requested. -- JsnX
I totally agree with JW's point -- DarTar
Actually, I could imagine separate functionality with filtering being useful on a busy site, but then as, say, UnseenChanges and UnseenComments - in addition to the current "Recent" functionality; that way the semantics of "recent" would not be changed. But I agree it's low priority. --JavaWoman
Implemented
This was added to Wikka in version 1.1.6.0.
- New usernames should be checked against existing page names. This was prompted by a new user named 'HomePage'.
For wikka.php:
<?php
/**
* Check by name if a page exists.
*
* @author {@link http://wikka.jsnx.com/JavaWoman JavaWoman}
* @copyright Copyright © 2004, Marjolein Katsma
* @license http://www.gnu.org/copyleft/lesser.html GNU Lesser General Public License
* @version 1.0
*
* @access public
* @uses Wakka::Query()
*
* @param string $page page name to check
* @return boolean TRUE if page exists, FALSE otherwise
*/
function ExistsPage($page)
{
$count = 0;
$query = "SELECT COUNT(tag)
FROM ".$this->config['table_prefix']."pages
WHERE tag='".mysql_real_escape_string($page)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
?>
/**
* Check by name if a page exists.
*
* @author {@link http://wikka.jsnx.com/JavaWoman JavaWoman}
* @copyright Copyright © 2004, Marjolein Katsma
* @license http://www.gnu.org/copyleft/lesser.html GNU Lesser General Public License
* @version 1.0
*
* @access public
* @uses Wakka::Query()
*
* @param string $page page name to check
* @return boolean TRUE if page exists, FALSE otherwise
*/
function ExistsPage($page)
{
$count = 0;
$query = "SELECT COUNT(tag)
FROM ".$this->config['table_prefix']."pages
WHERE tag='".mysql_real_escape_string($page)."'";
if ($r = $this->Query($query))
{
$count = mysql_result($r,0);
mysql_free_result($r);
}
return ($count > 0) ? TRUE : FALSE;
}
?>
For actions/usersettings.php - insert after line 151:
<?php
if ($this->ExistsPage($name))
$error = 'Sorry, this ""WikiName"" is reserved for a page. Please choose a different name';
?>
if ($this->ExistsPage($name))
$error = 'Sorry, this ""WikiName"" is reserved for a page. Please choose a different name';
?>
and change if on the next line to elseif. That should do it, I think. -- JavaWoman
CategoryDevelopment