Comparing revisions for WikkaDevelopment

===== Wikka Development =====

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]
- please give us back the "no cache" option on edit pages :)
- bugfix preventing creation of pages with invalid names (well done, but see my [[WikkaBugs note]]);
- 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;
- if people find it useful, include the ##lastedit.php## miniaction (I've moved the style attributes to a dedicated ##.lastedit## class in wikka.css);
- the ##header## running on this server has been [[WikkaSkinSelector modified]] for testing skins. The previous version of the header should be distributed until skins are under development;
[for the next major release]
- skins (with new [[WikkaSkinOptimization css template]]);
- [[HelpInfo documentation]] shipped with the installation;

- if the sourceforge-files are at date, you could think about changing the link at the end of setup.php :-)
- You mean the links to OK, I'll see if I can change these. :) -- JsnX

- 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.

- if someone finds the failure quick; //Underline in headers// would also be nice (WikkaBugs, Category Users as an example)
- OK. I did not know what you were talking about before, because Firefox was rendering it correctly for me. But I just took a glance at it now in IE, and I think I see what the problem is. The problem instigator is the colon on that line. As soon as the colon is removed it works fine. So, the next question is: why is it causing a problem? And the answer is, the formatter sees the colon and thinks we are trying to specify an Interwiki link. If we really trace the problem we find that this can be traced back to JavaWoman! :) Take a look at her suggestions to fix interwiki links on WikkaBugsResolved. Here's the regular expression recommended to match interwiki links: ---
%% "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:]\S*\b|". %%
After the colon it's matching anything not whitespace. Hmm, fine and dandy, but as we see it matches the underscore and things get messed up.
Here's what I changed it to:
%% "\b[A-Z,ÄÖÜ][A-Z,a-z,ÄÖÜ,ßäöü]+[:](?![=_])\S*\b|". %%
I'm using negative lookahead to say that I don't want it to match an equal sign or underscore. You guys know I'm dangerous with regular expressions, so if someone can explain to me why this is a bad idea and recommend another solution, I'm listening. However I should note, the interwiki problem is still resolved and the underline problem is fixed also, so it seems successful.

Note to JavaWoman: I'm playfully teasing when I point the blame at you. You're solution to the interwiki problem is still appreciated. -- JsnX
~~~''I know you're teasing :) Just go with your solution and see how it goes, we can always change it again after all. Mine was just a quick fix anyway - I'd really like to do a complete overhaul of all the regular expressions - but later (when I'm done with the other stuff I'm working on). --JavaWoman''

- I have no chance of testing it, so if anyone could tell me, if //Strikethrough rendering// works (see WikkaCSS) - just curios
- I haven't tested this yet either. I'll check it out, but I'm not sure if it will make this upcoming release. -- JsnX

- by the way, what about a highlighter-format? .highlight isn't used :-)

- for privacy reasons, i would like to see an addition about wikiping on RecentChanges (see SuggestionBox)
- Just my two euro-cents :-) NilsLindenberg

- ++When a read ACL is set in a way that a user cannot read a page, currently a empty page is displayed. It would be nice if there was a way to define a Page that is displayed instead of the empty page.++
~ My Mistake. I set the CSS to display the Text Black on Black

- Yet another idea from me:
~Usergroups. So i can create a group of users, and just write that group into the ACLs...

- New usernames should be checked against existing page names. This was prompted by a new user named 'HomePage'.
~~''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)<?php
* Check by name if a page exists.
* @author {@link JavaWoman}
* @copyright Copyright © 2004, Marjolein Katsma
* @license 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);
return ($count > 0) ? TRUE : FALSE;
~~For **##actions/usersettings.php##** - insert after line 151:%%(php)<?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)

- 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.
- Another user has to go back through his code and incorporate the changes made by the first user.

~~''**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" 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)

- 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''

==Low 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''

===== Wikka Development =====
{{lastedit show="3"}}

>>**See also**
- WikkaBetaFeatures of this wiki
- [[Docs:WikkaReleaseNotes Older Releases]]
- [[SuggestionBox Suggestions]]
- [[CodeContributions Contributions from users]]

====The next release====
//the following things will be added/updated/fixed in the next release//

===Feature Additions===

===Bug fixes===


===For the next minor release===

==SQL instructions in seperate file==
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 (DarTar)
~&God idea. I'll look into the implementation.... (JsnX)

===For the next major 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

Your thoughts about PagedComments? (DarTar)

[[TestSkin user skins]] (with new [[WikkaSkinOptimization css template]]); (DarTar)

WikkaDocumentation shipped with the installation (or maybe [[IncludeRemote not]]); (DarTar)


===Need to be done===

~-**install.php** does not remove /actions/wakkabug.php
~-On the install page, there should be a trailing "/" at the end of the base URL. Without it, css and other stuff won't work. It happened on two separate shared hosts running red hat/cpanel setup. (RyanKnoll (2005-02-05 08:09:24) copied from WikkaInstallation --Nils)

~- (499) RE for InterWiki link not the same as in (formatter) wakka.php

~- (3) check for valid page name should be done only for new pages (done??)

~- (5?) header is missing xml-declaration: echo '<?xml version="1.0" encoding="iso-8859-1"?>';
~- (9?) html tag is missing xhtml-declaration: <html xmlns="">

~- **mychanges** does not really sort by last change (see SandBox)
~-**newpage**: badly written (no input validation (will break if no page name submitted); superfluous hidden field used to detect submitted state; invalid XHTML): rewrite if we need it at all (note: mentioned on WikkaBugsResolved with a code change but this change isn't present in! So it's not resolved, and unchanged from I think it's much better to remove it though.---
~~&''Well, I think I'd suggest adding it to the 3rd party plugin directory then. Although for you sorts that action doesn't seem necessary, for the community of kids that I work with, it's something that I anticipate will be the main way they make pages at first. By all means improve the action so that it cannot be blank (I raised this initially I think), and that so a regex checks for camelcasing, but I think it should be available somewhere & the 3rd party plugins directory would suit.'' -- GmBowen
~~&How hard is it for them to learn to use a Wiki in a Wiki-way? There are already two ways to create a page - referring to one and then creating it from the missing link being the best (and easiest) and it will not leave any orphans (which should be discouraged anyway!); this is not that hard (no URLs, no code, just using the Wiki). Surely highschool kids can learn //something// - don't underestimate them. ;-) --JW
~~&''Oh, I don't underestimate them, they can learn the "normal" way of making a page. But the create page action is a good scaffold towards that....and scaffolding is important. Also, I'm working on a separate environment for grade 6/7/8...for those age groups it'll be even more useful. And, in my experience with people playing with this wiki (my undergrads), many people start with making orphaned pages, and then organize them so they're unorphaned and can find them more easily. ''//(HOW do they make orphaned pages then? The newpage action actually encourages making orphaned pages, something that should be avoided. If they're not using a newpage action then obviously they don't need that to create orphans. :))//'' As for using the normal wiki-way to create pages, I'm a pretty competent computer nerd and I found (and find) the normal way of making wiki pages awkward. If I want to start a new page for some reason, having to open another page to write the name, save it, and then click on the link to go to the new page to edit it is "annoying" in that it takes so much work. ''//(But it's the only way to ensure the page will not be orphaned to begin with. Wikis are about interlinking pages easily, orphans don't have a place in that.)//'' Kids (and other users I would argue) will want to start a new page like they do in a word or two clicks only (and in my environment the URL bar is hidden, so they can't do it that way). ''//(Where "will want" suggests assumption rather than research - if they can learn to use a word processor they //certainly// can learn to use a Wiki. A Wiki **is not** a word processor - why should it work the same? It would create an incorrect mental model. Creating links is about the **easiest** part of using a Wiki - and the most essential!)//'' Wiki-think is that you make structure as you make content (that's essentially what you're describing). But many people don't work (or think) that way....disparate content first, then structure it....I know numerous academics that write that way in fact. (In fact, on this site I make a new page first, get it the way I want, and then go and add links.....I just use the URL bar to do it) The "make new page" action allows wikka to support both sorts of approaches, and that means more appealing to more people. ''//(But Wikka should not **encourage** creating orphans - which is what the newpage action does - and if you really must Wikka //already// supports it: you can use the address bar to make a new URL. That's sufficient.)//'' An old DOS program, Tornado notes, worked this way too. You added bunches of content that you could search on, but in use you then added keywords (like we do in wikka with categories) to provide organizational structure in searches. --GmBowen''
~- **image** does not have alt required (necessary for valid XHTML; no default should be provided); a specified blank value (zero or more spaces) should be accepted as given. Also remove the meaningless default title attribute value: use no title unless specified as an action code.---
~&''To present it a different way, My understanding of why the alt tag is needed is because it is picked up by screen readers (literally, readers) to assist visually impaired people with "reading" the page...I suspect that's one of the reasons that it's in the standards in the first place.'' -- GmBowen

Valid XHTML :: Valid CSS: :: Powered by WikkaWiki