Revision [2597]

This is an old revision of WikkaDevelopment made by JsnX on 2004-11-28 22:53:59.

 

Wikka Development

Last edited by JsnX:
small cleanup
Sun, 28 Nov 2004 22:53 UTC [diff]

CategorySystemOverhaul


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 2004

[for the next minor release]

[for the next major release]
DarTar






My Mistake. I set the CSS to display the Text Black on Black

Usergroups. So i can create a group of users, and just write that group into the ACLs...

Clever new user! Yes, definitely needed; a simple existsPage() function would be nice, the current DB access methods are a little bit heavy for that; I was just trying to do that! --JW
Oh, that was me. Sorry. I did it to bring this shortcoming to Jason's attention, and then was interrupted by a phonecall from my wife and kid (who, unfortunately, until the house sells still live in Thunder Bay) that went on for over an hour and I just forgot to add a note to the "bugs" page. Feel free to erase the username. -- GmBowen
LOL! Nice variant of my favorite "running off to catch the train" scenario; you got your point across nicely though ;-) --JW
For wikka.php:
<?php
        /**
         * Check by name if a page exists.
         *
         * @author      {@link http://wikka.jsnx.com/JavaWoman JavaWoman}
         * @copyright   Copyright &copy; 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';
    ?>

and change if on the next line to elseif. That should do it, I think. -- JavaWoman

Is this being, or has it been, incorporated into wikka as "standard"?? And, just a comment, if someone has been modding their own version of wikka, line counts such as in the above usage, make it difficult to make the modification...I personally find it more useful if the lines above and below where the addition is to occur are listed. -- GmBowen (aka mike)
Mike, I simply refer to the line number in the current official release. It's not hard to find even if you have a modded version (like I do!) if you simply keep around a copy of the current original as well: that way you'll always know how and where your version differs from the release. --JavaWoman

OR

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:
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)


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


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



There are 8 comments on this page. [Show comments]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki