Revision history for WikkaDevelopment


Revision [22999]

Last edited on 2016-05-20 07:38:44 by JavaWoman [Replaces old-style internal links with new pipe-split links.]
Additions:
- [[Docs:WikkaReleaseNotes | Older Releases]]
- [[SuggestionBox | Suggestions]]
- [[CodeContributions | Contributions from users]]
[[TestSkin | user skins]] (with new [[WikkaSkinOptimization | css template]]); (DarTar)
WikkaDocumentation shipped with the installation (or maybe [[IncludeRemote | not]]); (DarTar)
Deletions:
- [[Docs:WikkaReleaseNotes Older Releases]]
- [[SuggestionBox Suggestions]]
- [[CodeContributions Contributions from users]]
[[TestSkin user skins]] (with new [[WikkaSkinOptimization css template]]); (DarTar)
WikkaDocumentation shipped with the installation (or maybe [[IncludeRemote not]]); (DarTar)

Revision [18457]

Edited on 2008-01-28 00:11:41 by JavaWoman [Modified links pointing to docs server]
Additions:
- [[Docs:WikkaReleaseNotes Older Releases]]
Deletions:
- [[WikkaReleaseNotes Older Releases]]

Revision [8690]

Edited on 2005-05-29 12:16:43 by JavaWoman [move to subcategory]
Additions:
CategoryDevelopmentDiscussion
Deletions:
CategoryDevelopment

Revision [7119]

Edited on 2005-04-05 14:56:33 by NilsLindenberg [two things about header.php]
Additions:
===== Wikka Development =====
{{lastedit show="3"}}

>>**See also**
- WikkaBetaFeatures of this wiki
- [[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===

===Misc===


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

==Page-Caching==
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

==PagedComments==
Your thoughts about PagedComments? (DarTar)

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

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



----

===Need to be done===

installer:
~-**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)

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

handlers:
~-**edit.php**
~- (3) check for valid page name should be done only for new pages (done??)

header:
~-**header.php**
~- (5?) header is missing xml-declaration: echo '<?xml version="1.0" encoding="iso-8859-1"?>';
~- (9?) html tag is missing xhtml-declaration: <html xmlns="http://www.w3.org/1999/xhtml">

actions:
~- **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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). 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 processor...one 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

----
Deletions:
===== Wikka Development =====
{{lastedit show="3"}}

>>**See also**
- WikkaBetaFeatures of this wiki
- [[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===

===Misc===


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

==Page-Caching==
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

==PagedComments==
Your thoughts about PagedComments? (DarTar)

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

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



----

===Need to be done===

installer:
~-**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)

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

handlers:
~-**edit.php**
~- (3) check for valid page name should be done only for new pages (done??)

actions:
~- **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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). 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 processor...one 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

----

Revision [5668]

Edited on 2005-02-05 21:47:08 by JavaWoman [minor]
Additions:
~-**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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.---
Deletions:
~ **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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.---

Revision [5654]

Edited on 2005-02-05 18:21:30 by NilsLindenberg [addition]
Additions:
~-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)

Revision [5630]

Edited on 2005-02-04 18:59:05 by NilsLindenberg [syntax highlighting updated - removed]
Deletions:
~-We should update the infos on syntax highlighting in the default FormattingRules page (add wikkas build-in formatters again)

Revision [5625]

Edited on 2005-02-04 18:32:54 by NilsLindenberg [deleted the rest of the old discussions]
Deletions:
====Older discussions====
~-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/WikkaDocumentation main Wikka server]]%%
~~''Agreed. --JavaWoman''
~~~''For the time being, what about creating a default page called WikkaReleaseNotes containing a static link to the online WikkaReleaseNotes? (see my note above on why creating or overwriting a page during upgrade is not really a problem)'' -- DarTar
~~~~''Actually, I'd like to see our current ""ReleaseNotes"" page here renamed to **WikkaReleaseNotes**; pages relating to Wikka itself really should start with 'Wikka': we already have WikkaDevelopment, WikkaBugs, WikkaBugsResolved, etc. (why not WikkaDocumentation?) - WikkaReleaseNotes would neatly fit into that pattern and be clearer than just """ReleaseNotes""". Then someone writing about, say, a Calendar can create a page like FancyCalendarWikkaReleaseNotes etc. ---I agree with DarTar that a page with a static link to the online release notes here, to be included with the install, would be a good temporary solution; to be replaced later by a mechanism like FetchRemote (once finished - but let's not wait for that!) (**Note**: edited somewhat for readablity - we now do have WikkaReleaseNotes and WikkaDocumentation as suggested.) --JavaWoman''
~-I propose we update the default HomePage to display the version number, a [[WikkaReleaseNotes what's new]] link pointing to the WikkaReleaseNotes 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 {{version}} (see WikkaReleaseNotes).
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;
~~OK.
~~~''This should do it: %%(php)<?php
echo $this->VERSION;
?>%% Save as ##actions/version.php## --JavaWoman (who for once doesn't document what she writes. ;o) )''
~~~~Here it comes: this is Wikka version {{version}}. I wonder if it wouldn't be better to have such basic system plugins handled by the wikka formatter, instead of using an action. And maybe in the future ##""{{version}}""## will print a link (fetchable or not) to WikkaReleaseNotes? -- DarTar
~-If Nils is ready with the new version in a couple of days, replace the current FormattingRules with an more structured page.
~~''I'm in Rom till sunday so don't expect big changes before monday. Nils''
~-Do we still need two different actions //colour/color// ? I would drop the British one.
~~Dropped. ''Geez, in the whole wide world it's only the Americans who spell it without the "u"....so we keep the U.S. spelling? Ironic.''
~~~''spelling **is** [[http://en.wikipedia.org/wiki/American_and_British_English_differences ironic]] - you can always add a colour action yourself containing nothing but an include of ##actions/color.php##, if you must. :) --JavaWoman''
~~~''Liberia???? Japan I get (beaten in war). OAS I get (sucking up to U.S. ;) ). LIBERIA??? Liberia I don't get. ''(Simple, look up the [[http://en.wikipedia.org/wiki/Liberia#History history of Liberia]]; knowing that I could easily //guess// they'd be using American English''(oh ya, I see what you mean. I'd forgotten that bit of history.)''. And where did you think the name Liberia came from? --JW)'' BTW, I didn't mean that spelling was ironic, I meant that the decision was, given efforts by various members on this wiki to "internationalize" the wiki. (Or, I could rename the file. Writing an action to include an action is a programmer's solution obviously. LOL ;-} ) -- Mike''
~-Shouldn't we announce in the WikkaReleaseNotes that the //raw// handler has been modified?
~~-Sure.

Revision [5591]

Edited on 2005-02-04 15:27:25 by NilsLindenberg [moved /deleted discussions]
Additions:
===Need to be done===
~- (3) check for valid page name should be done only for new pages (done??)
~~&''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 processor...one 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''
~&''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
====Older discussions====
Deletions:
===In work===
===Things to be fixed before releasing wikka-1.1.6.0 (JW's take):===
After (and in addition to) all the discussion above triggered by DarTar's notes, here are my own observations based on careful code inspection (sometimes better than testing ;-)). See also my thoughts in WikkaGeshiIntegration.
//Numbers within brackets refer to (approximate) line numbers.//
==Bugs and other issues/problems==
==//Major//==
formatting:
~-**htmlspecialchars_unicode()**:
looking at the code I'm sure this will not work correctly. It wil "accept" numerical entity references but not named entity references - so those still won't work. (And actually, its operation doesn't have anything to do with **Unicode**, only with entities - which //may// encode Unicode characters but entities are not themselves Unicode.)
~//See my item 'Non-breaking space in forced links' in the SuggestionBox: this is one case that actually **shows** the function htmlspecialchars_unicode() does not work correctly!//
Also, there is no option for the ##quote_style## and ##charset## parameters as in the PHP original, so we lose functionality here, too. It's probably better to have a "wrapper" function around the PHP one, which (after applying the PHP function, passing on the extra parameters) merely reverts all ampersands that are for any entity references (numerical or named); thus the wrapper function should accept all parameters the PHP function does. And since we are supposed to produce XHTML, ENT_QUOTES should probably be the default for ##quote_style##; maybe also UTF-8 should be the default for ##charset##?
Note: the INI code formatter used ENT_QUOTES and this has now disappeared (it was there for a reason!). But an entity used in **code** should be visible as an entity, not as the character it encodes. Conclusion: a code formatter //should// use the PHP function htmlspecialchars() so that any entities are "escaped".
~Here's the solution: **a new function ##htmlspecialchars_ent()##** to replace the proposed (beta) ##htmlspecialchars_unicode()##:
~%%(php) /**
* Wrapper around PHP's htmlspecialchars() which preserves (repairs) entity references.
*
* The function accepts the same parameters as htmlspecialchars() in PHP and passes them on
* to that function.
*
* One defaults here is different here from that in htmlspecialchars() in PHP:
* charset is set to UTF-8 so we're ready for UTF-8 support (and as long as we don't support
* that there should be no difference with Latin-1); on systems where the charset parameter
* is not available or UTF-8 is not supported this will revert to Latin-1 (ISO-8859-1).
*
* The function first applies htmlspecialchars() to the input string and then "unescapes"
* character entity references and numeric character references (both decimal and hexadecimal).
* Entities are recognized also if the ending semicolon is omitted at the end or before a
* newline or tag but for consistency the semicolon is always added in the output where it was
* omitted.
*
* NOTE:
* Where code should be rendered _as_code_ the original PHP function should be used so that
* entity references are also rendered as such instead of as their corresponding characters.
*
* @access public
* @since wikka 1.1.6.0
* @version 1.0
* @todo (later) support full range of situations where (in SGML) a terminating ; may legally
* be omitted (end, newline and tag are merely the most common ones).
*
* @param string $text required: text to be converted
* @param integer $quote_style optional: quoting style - can be ENT_COMPAT (default, escape
* only double quotes), ENT_QUOTES (escape both double and single quotes) or
* ENT_NOQUOTES (don't escape any quotes)
* @param string $charset optional: charset to use while converting; default UTF-8
* (overriding PHP's default ISO-8859-1)
* @return string converted string with escaped special characted but entity references intact
*/
function htmlspecialchars_ent($text,$quote_style=ENT_COMPAT,$charset='UTF-8')
{
// define patterns
$alpha = '[a-z]+'; # character entity reference
$numdec = '#[0-9]+'; # numeric character reference (decimal)
$numhex = '#x[0-9a-f]+'; # numeric character reference (hexadecimal)
$terminator = ';|(?=($|[\n<]|<))'; # semicolon; or end-of-string, newline or tag
$entitystring = $alpha.'|'.$numdec.'|'.$numhex;
$escaped_entity = '&('.$entitystring.')('.$terminator.')';
// execute PHP built-in function, passing on optional parameters
$output = htmlspecialchars($text,$quote_style,$charset);
// "repair" escaped entities
// modifiers: s = across lines, i = case-insensitive
$output = preg_replace('/'.$escaped_entity.'/si',"&$1;",$output);
// return output
return $output;
}
%%
~~I created a test harness for it (I tested with ##htmlspecialchars()## in the Link() function in ##wikka.php## replaced by ##htmlspecialchars_ent()##:
~~~1)""[[HomePage word & notherword]]"" (to be escaped)---=> [[HomePage word & notherword]]
~~~1)""[[JavaWoman Java&nbsp;Woman]]"" (alpha: no-breaking space)---=> [[JavaWoman Java Woman]]
~~~1)""[[JavaWoman &Auml;hnlich]]"" (alpha with uppercase)---=> [[JavaWoman Ähnlich]]
~~~1)no terminating ; before tag &quot<span style="color:blue;">blue</span>&quot; (alpha: text, not link)---=> ""no terminating ; before tag "<span style="color:blue;">blue</span>"""
~~~1)""[[CategoryDevelopment test no terminating ; before end &quot]]"" (alpha)---=> [[CategoryDevelopment test no terminating ; before end &quot]]
~~~1)""[[FormattingRules <b>no ; before tag &#039</b>]]"" (numeric decimal)---=> [[FormattingRules <b>no ; before tag '</b>]]
~~~1)""[[SandBox missing ; before &#x3f5""---
~~~""|<- newline]]"" (numeric hex)---=> [[SandBox missing ; before &#x3f5
|<- newline]]
~~There are problems (now) with test cases 2, 3, 5, 6 and 7; with my proposed solution all testcases are converted correctly.
~~**Note:** The formatter does not recognize forced links with newline in description text (test case 7)! There is nothing wrong with having a newline inside a link description. => This requires small fix in wakka formatter (**##./formatters/wakka.php##**), as follows:
~~replace:
~~%%(php) // forced links
// \S : any character that is not a whitespace character
// \s : any whitespace character
else if (preg_match("/^\[\[(\S*)(\s+(.+))?\]\]$/", $thing, $matches))
%%
~~by:
~~%%(php) // forced links
// \S : any character that is not a whitespace character
// \s : any whitespace character
else if (preg_match("/^\[\[(\S*)(\s+(.+))?\]\]$/s", $thing, $matches)) # s modifier: recognize forced links across lines
%%
~~Finally: the call in **##./formatters/ini.php##** should be restored to:
~~%%(php)$text = htmlspecialchars($text, ENT_QUOTES);%%
~~and in **##./formatters/code.php##** we should also use %%(php)htmlspecialchars($text, ENT_QUOTES);%% (i.e, add the ENT_QUOTES parameter).
~~All other calls to htmlspecialchars_unicode() (as well as the definition) should be replaced by htmlspecialchars_ent() above.
~//NOTE: As noted elsewhere: copy code fragments from the **source** of this page, not the rendering, to preserve layout (tabs)!//
~-**wakka.php** (formatter):
~- (121) class replaced by align - should be class (only spelled 'center' instead of 'center' - and make sure CSS corresponds)
~- (200 etc.) integration of GeSHi not very clean (see my proposal in WikkaGeshiIntegration)
~- (371/376) '|' should not be part of $mindmappattern ? what's with the---##""if ($this->method == "show")""## ?? ---don't understand what's happening here (document! especially since this deviates from the normal "pattern")
~~''The show check is in there to prevent the applet code from displaying when not "viewing" a page. Specifically, there were problems with showing a "page history" before this was added. -- JsnX''
~- turning an image URL into an image link causes invalid XHTML (although syntactically valid, semantically it's **in**valid - and this cannot be solved: it's not possoible to provide a meaningful alt atribute with just a URL); since it always produces invalid (X)HTML I consider this a bug. In order to be able to produce valid XHTML (as we claim!) this formatting feature should be removed; images can still be included with the image action (which should be corrected, see below).
~- **showcode.php**
~- uses ENT_QUOTES but not supported (now) by htmlspecialchars_unicode (see solution under htmlspecialchars_unicode above!)
~- layout could be a bit better (wrap a class 'page' div around output)
==//Minor//==
~- (3) check for valid page name should be done only for new pages
~- (145) title on message is redundant (and worse than the link description itself, which is just fine by itself): should be removed
~~''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 processor...one 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''
~''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
--JavaWoman

Revision [5587]

Edited on 2005-02-04 15:16:08 by NilsLindenberg [moved discussion to WikkaReleaseNotesDiscussion]
Additions:
===In work===
~-We should update the infos on syntax highlighting in the default FormattingRules page (add wikkas build-in formatters again)
Deletions:
===Older discussion===
==Things 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 WikkaReleaseNotes 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 WikkaReleaseNotes page on the wikka server;
~~-I'd wager that the average Wikka owner does not care as much as you and I do about the release notes. Have you noticed that the majority of Wikka sites that have been around for a while have never upgraded? Anyhow, how about an alternative:
~~- We can still have a page named WikkaReleaseNotes, but we bring back what Wakka used to do. Create an action named wikkachanges. This action will display a file in the docs directory named CHANGES.txt. We then put the action in the WikkaReleaseNotes page. This way we cover two areas: admins who have just downloaded the distribution file, and online users who want to see the changes. The wikkachanges action is live on this site right now. Try it.
~~''I saw it in the SandBox and it messed up things royally there... disabled it, and added notes about my findings.---I agree with Dartar, I'd like to see WikkaReleaseNotes included as a default page; if one doesn't look at it, fine, but at least it's there if you do need to consult what was changed (and why) and it's much more readable than what ""{{wikkachanges}}"" produces. I'd vote for just removing the ""{{wikkachanges}}"" action and simply including a WikkaReleaseNotes page. --JavaWoman''
~~Have both of you thought how this would be implemented?? It's easy to include a default page on install. However, what are we going to do on upgrade? Are we going to overwrite the page? (''Yes, of course! And that's what you'd do with a text file as well - what's the difference?'') What if the site has changed the page? (''Include a note on the page that it is a system page that **will** be overwritten on upgrade; if possible protect the page from editing by anyone but admin on install.'') I think it would be annoying for the upgrade script to overwrite an existing page. (''But you //would// be overwriting the text file - what's the difference? A page is just a more readable version. And we wouldn;'t need to keep the same information synchronbized in two places - always a bad idea.'') Hence the solution that I have proposed. In addition, how long is it going to be before someone says, "Hey, why don't we include a text file that lists the changes". (''Maybe **very** long - it hasn't happened, has it? See how it goes.'') Once again, we take care of this by including the text file and then showing it in the wiki. Sites are not going to update the Wikka release notes--it's static data. Why have it as a wiki page? (''For readability, and it fits in simply with the system. Yes, sites are not going to update the release notes - in whatever form. And if they **do** want to update them, they could do that with the text file just as easily.'')
~~~''My 2 cents. On the one hand, I agree with JW as far as //readability// is concerned: it is much better to have a formatted version, with headers etc., possibly with links, than a plain-text version (the first thing I thought when I saw the SandBox page full of raw text was : "gosh, the formatters are broken!"). This said, there is a question that none of you has mentioned so far. How are we going to deal with //internal links// that are present in the current WikkaReleaseNotes page? Either we distribute a version of WikkaReleaseNotes with no internal links and no camelcase words left or we have to think of a solution to avoid generating a ton of missing pages. IMO, one interesting solution (which might require some futher development, though) is to use a [[IncludeRemote FetchRemote]] strategy to retrieve fresh and uptodate documentation on the new release from the main server (JsnX, have you tried to install the plugin locally?). This has the advantage of avoiding writing a hardcoded page in the user's database and - as Jason was suggesting - let the user free to decide where to add the release notes (it is just a matter of adding somewhere ##""{{fetchremote page="WikkaReleaseNotes")""##). On the other hand, I was wondering: is there really a problem with //overwriting// an existing page? Provided the installer says explicitly it is going to overwrite one page, this page will be nothing more than a //version// of the page (that's the power of wikis!): if a note is added like "updated by the Wikka installer", the user will always be able to retrieve previous versions of the same page if needed. So I don't really think that overwriting is a problem. -- DarTar''
~~~~Sorry to keep hammering on this, BUT :), let's see how your logic holds up:
~~~~~Is there really a problem with //overwriting// an existing HomePage? Provided the installer says it is going to overwrite the HomePage, the new HomePage will be nothing more than a //version// of the page. The site admin will always be able to retrieve the previous version of the HomePage if needed. So I don't really think that overwriting the HomePage is a problem.
~~~~Sounds absurd, doesn't it?
~~~~~''Um, yes. What goes for the HomePage goes for the WikkaReleaseNotes: "overwriting" simply means creating a new version in the database. So I don't really think that's a problem. ;-) --JW''
~~~~~~
~~~~~~''As I said above, I don't consider this a problem. But even if you don't agree with this, consider that no one is proposing here to overwrite a page like HomePage, but a page with a sufficiently clear 'system default' name (like WikkaReleaseNotes) that will hardly be modified by Wikka users (and if it is, again, it's just a version..). -- DarTar''
~~~~Regarding JavaWoman's comments:
~~~~~Your first point was that the installer would overwrite the text file, so why not overwrite a page.
~~~~~~That's not correct. **The site admin** would overwrite the text file, by his choice of uploading the new file to the webserver. It would be his choice to overwrite the file. See the difference?
~~~~~~''Most site admins would not "upload the [separate] files" but rather upload the archive to the server, untar it there, and then run the upgrade routine. Just untarring would replace all files. And why would one //not// replace a release notes (text) file? It contains all previous information, doesn't it?''
~~~~~Your next point was that it's a bad idea to keep the information in two places.
~~~~~~So you are suggesting that we should only make the information available online and **after the upgrade has already happened.** Wouldn't you want to know what has changed **before** you upgrade?
~~~~~~''It **is** known **before** you upgrade because it's right here. --JW''
~~~~~I could go on and on. The bottom line: it's standard for software distributions to include a text file that describes changes. This is where most people will look for the information....and they will want to review the changes before they decide to upgrade--not upgrade and then review what has changed. I'm in favor of using ""{{fetchremote}}"" to make the information available online, but also including a text file that can be reviewed offline. Here's an example of how the text file might be useful: Let's say an upgrade breaks an existing site. The admin could view the text file to help narrow his focus for fixing the problem. ... I'm going to throw in one more thing just to preempt it: But couldn't the site admin just view the release notes on WikkaWiki? That's possible, however this site might be down. It could be down from a denial-of-service attack. I could be dead and thus not able to pay the bill. Who knows? By including a text file we won't have to worry about any of this. -- JsnX
~~~~~''Actually, many applications have all their documentation online, except maybe a small readme and a license file. Most people don't download first, then unpack an archive, and then read a changes file to see what's in the latest release: they read the release notes online **before even downloading**. Sure a site can be down - that can always happen. Many possible causes (and it happens to the best of them). //As to you being dead and not being able to pay the bill - that's an entirely different discussion (one we should have, about continuity and how to ensure it, but not here in this context).// But the whole idea of including release notes is to provide a reference //after// download and installation - but that won't normally happen until **after** one has checked the release notes online to see whether it's worth the download in the first place.---My argument about keeping the information in two different places and two different formats identical still stands, meanwhile - how do you propose to make sure the two versions have identical information at all times? Even if you have a reliable procedure for that (you'll need a script) - it's extra (unneeded) work, as is creating a special action to show the contents of the text file: two files, two programs, all to show the same content? A simple page that (for now) shows just a link or (later) pulls the content directly from the site will be much simpler. -- JavaWoman''
~~~~~~
~~~~~~''Regarding this point, I don't agree with JW's argument. I think a text version with the release notes, accessible to the Wikka administrator before untarring and uploading the package makes perfectly sense (and actually is very common in software distributions). I really don't see the problem with "keeping information in two places": before releasing a new version, the text release notes can be created in 5 seconds just by copying and pasting in a text editor the formatted output of WikkaReleaseNotes. So where's the problem? -- DarTar''
~~~~~''In referring to "keeping information in two places" I'm thinking of a build process, assuming (not the case now!) that **all** the to-be-released files are in a CVS branch, and you just run a script to turn that into a distribution. The files in that branch should -at all times- be up-to-date, which includes any text files to be included. So what happens while you're working on a new release? Something like this - for **every change to be made for the next release**:
~~~~~~- apply a fix or create/add a new extension
~~~~~~- make a corresponding note in WikkaReleaseNotes here
~~~~~~- make a new copy of WikkaReleaseNotes to 'changes' text file
~~~~~~- commit all these files into the CVS---
~~~~~~....
~~~~~~- build (periodically) new beta release or (once) final release
~~~~~The set of files in the repository should be "complete" at all times to be able to do a build; which (in your proposal) means also //repeatedly// copying the WikkaReleaseNotes (manually, or via a script) - not just once, but for every change being made. It's an extra step, and doing that step is a manual process (even if you run a script to do the copying, running the script is a manual step). People do forget steps :), so the fewer manual steps there are, the more reliable the build and release process will be.''
~~~~~''On the other hand, a static WikkaReleaseNotes page with a link to the online WikkaReleaseNotes would need to be created and committed only once; no redundant and easy-to-forget manual steps needed any more. --JavaWoman''
~~Why don't we focus our energy on making the ""{{wikkachanges}}"" action better? JavaWoman, you are detailing problems with my crappy action that I spent ten minutes on to demonstrate the concept. Wouldn't it be possible to tweak the action to output the text to your satisfaction? (''What I see is is a far less readable version, and if it's in a text file, then how are you going to keep the two synchronized? We **already** have WikkaReleaseNotes - if you just include that it's simpler (it's already there), more reliable (nothing to synchronise, the data is in one place, not two), and more readable (no extra action needed either).'')
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as WikkaReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating? (''So rename it WikkaReleaseNotes **here** and include **that** page as a system page. I agree that the name is not optimal - but the same is true here already. **Note**: this rename has been done now --JW'')
~~I don't like the idea of us forcing pages on people. If we make the release notes as an action, people can have the release notes show on any page they want. They could create a page named WikiEngineChanges and place the ""{{wikkachanges}}"" action on it, and when they upgrade, the changes will show up on the page that **they** decided. (''So they create a page called WikiEngineChanges and just ""{{include}}"" the WikkaReleaseNotes on it.'') If we force a page named WikkaReleaseNotes, we are going to create an unnecessary struggle with site owners that might not want to have the Wikka release notes on a page named WikkaReleaseNotes. (''It's just another "system" page, like SandBox and FormattingRules. I don't see the problem.'') -- JsnX
~~''Comments embedded above to make them more relevant to context -- JavaWoman''
~~''I gave above some more reactions about my way of seeing the problem of release notes. I'd like to propose here some steps towards a solution that I hope we might all agree upon.
~~- we rename the ""ReleaseNotes"" page on this server as WikkaReleaseNotes; **Note**: done now --JW
~~- we add to the next release the ##""{{version}}""## action;
~~- we create a (temporary) ##""{{wikkachanges}}""## action that prints the following code:''
~~%%===== Wikka Release Notes =====
This server runs on [[[http://wikka.jsnx.com/ Wikka Wiki]] version **{{version}}**.
The new features of the current version are described on the [[http://wikka.jsnx.com/WikkaReleaseNotes main Wikka server]]%%
~~''In the future, this action will be replaced by a FetchRemote action.
~~(BTW it might be interesting to add named anchors in WikkaReleaseNotes to facilitate referring to specific Wikka versions)
~~- we add to the installer/upgrader a line for creating a local WikkaReleaseNotes. The page will contain, for the time being, only ##""{{wikkachanges}}""##. The installer leaves a note about the page creation/upgrade: "written by the Wikka Installer";
~~- we distribute with each release a text file, called ##docs/WikkaReleaseNotes.text## with a textual version of the section of WikkaRecentChanges page on the main wikka server concerning the last release.
~~
~~ Is this an acceptable compromise? ;) -- DarTar''

Revision [5583]

Edited on 2005-02-04 15:03:39 by NilsLindenberg [additions+deletion of things done]
Additions:
>>**See also**
- WikkaBetaFeatures of this wiki
- [[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===
===Misc===
~ **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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). 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 processor...one 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''
Deletions:
====Additions/Changes to the next release====
On this page, feature additions to the next relaese(s) of wikka can be discussed.
~-**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()""##:
~~-Done.
~~~- Since the bug has been fixed, I move the code to the resolved bugs. I'll add this bug fix in the WikkaReleaseNotes. -- DarTar
==GeSHi integration==
See also WikkaGeshiIntegration.
general:
~- version included is 1.0.3 - this was buggy and 1.0.4 is out now: this version (or any later one available) should be bundled.
resolved in version 1.0.4:
~- documentation missing (readme refers to this missing documentation) - is included in docs directory in 1.0.4
~- contains zero-byte css-gen.cfg (still in 1.0.4) -> but cssgen.php is now included in contrib dir in 1.0.4
~- example.php missing - in contrib dir in 1.0.4
~- html parsing is done with html4strict.php (please don't rename)
integration:
(See **detailed integration solution** in WikkaGeshiIntegration, complete with installer/updater code.)
~- do NOT hardcode paths within a function (ever!); people may already have a modded version of GeSHi on their system and want to use this: include path and $path should be defined in (a separate section of) the configuration (see also WikkaCodeStructure)
~- also allow configuration of such things as tab width and showing line numbers, so people don't have to hack wikka.php to accomplish this
~- always instantiate object as reference:---
##""$geshi"" **=&** ""new GeShi($sourcecode, $language, $this->geshi_path);""##
to be done:
~- css.php needs reverse-sort of keywords (done on Wikka site?); this change also needs to be documented in included source (and file mailed back to author)
~- possibly also for other language files? -> check!---
=> at least ones that are highly likely to be used in our (online) implementation:
~- sql
~- html4strict
~- java (?), not all are sorted either
~- javascript (doesn't look like a problem)
~- **calendar**: not my code: all TABs have been replaced by (irregular) spaces leading to bad worse readability of the code and sloppy layout of the output source (they are in the page **source**, of course, please don't take source from code **display**!)---
=> **Note:** working with CVS (on ""SourceForge"") - and access to it for developers - could prevent this sort of code mangling.
~-**header.php** little additions to get valid html (think its the right context here for this---""--""NilsLindenberg)
~~-adding a doctype before the <html>:%%(html4strict)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
~~-changing the <style> to <style type="text/css">
~~-changing the function test, so that a failed test won't result in unclosed pages:---change the line about $stopOnError to:%%(php)
if ($stopOnError)
{
include('setup/footer.php');
exit;
}
~- **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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). 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 processor...one 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''

Revision [5541]

Edited on 2005-02-03 19:32:54 by NilsLindenberg [copied problems with modrewrite to ProblemsWithModRewrite]
Deletions:
==ModRewrite==
- 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
DarTar kind of gave you the key....
Forget about the wrong information that your ISP gave you and read ModRewrite. -- JsnX
- Jason, I know the information that DarTar gave was correct and I have read ModRewrite but when I tried his settings, I got an error message, hence the reason for contacting my isp's help desk. The error can't find the correct path to wikka.php. I have reset the config file to RR Off and everything works fine. DarTar and JsnX, please accept my apology for wasting your time. --JamesMcl
- James, please keep asking questions. I wasn't trying to scare you off. In this case, though, it appears that something is amiss with mod_rewrite on your webhost. -- JsnX

Revision [5474]

Edited on 2005-02-02 11:28:40 by NilsLindenberg [moved next-release-discussions to the top]
Additions:
====Additions/Changes to the next release====
===For the next major release===
Deletions:
====Things in the next release====
====For the next major release====

Revision [5473]

Edited on 2005-02-02 11:27:18 by NilsLindenberg [next release discussion to the top]
Additions:
====Things in the next release====
On this page, feature additions to the next relaese(s) of wikka can be discussed.
===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)
==Page-Caching==
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
==PagedComments==
Your thoughts about PagedComments? (DarTar)
==User-skins==
[[TestSkin user skins]] (with new [[WikkaSkinOptimization css template]]); (DarTar)
==Documenation==
WikkaDocumentation shipped with the installation (or maybe [[IncludeRemote not]]); (DarTar)
===Older discussion===
==ModRewrite==
Deletions:
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 2004
====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....
- Your thoughts about PagedComments?
- [[TestSkin user skins]] (with new [[WikkaSkinOptimization css template]]);
- WikkaDocumentation shipped with the installation (or maybe [[IncludeRemote not]]);
DarTar
- 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.
- See my questions at HandlingWikkaConfig. NilsLindenberg
- by the way, what about a highlighter-format? .highlight isn't used :-)

Revision [5472]

Edited on 2005-02-02 11:00:57 by NilsLindenberg [copied ideas to SuggestionBox]
Deletions:
===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...
~GregorLindner
- Take a look at GroupManagement (which doesn't seem to be finished) - or at ACLsWithUserGroups.
=="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? --NilsLindenberg
==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''

Revision [5469]

Edited on 2005-02-02 10:39:53 by NilsLindenberg [copied table-discussion to WikkaTables]
Deletions:
==Table markup==
Richard Berg has provided code for very simple table code that could be placed in formatters/wakka.php. I think that one weakness that wikka has is the lack of support for any tables. Sure, I know people are thinking about syntax & extended features etc etc (I've contributed to that discussion) but I'd like to suggest that "simple" table support should be provided now if possible. Richard's code builds a table (and keep wikka links and formatting) using....
||cell1||cell2||**boldcell3**||
||cell4||cell5||//italicscell6//||
which is a basal example of code formatting we were thinking of using anyways, so when we do end up supporting tables in a more complex fashion, it should be reasonably simple for users with tables to adapt their previous code to the new code base. Anyways, I'd like to suggest that we add this code into the next release to provide basic table support. -- GmBowen
~& ''(//*Blush*// OK, **I** was missing something. From my early days with Wikka, I remembered having seen an "awkward table markup", and (much) later found a table action; the result: I thought we had both. In reality, the "awkward markup" I remembered //was// the action. I'll refactor the stuff below somewhat in view of this.)''--- The problem is not that Wikka has "lack of support for any tables" - we have a table action that serves as a "poor man's table markup". The real problems with this are:
~~1) this table "markup" (action) is basic, but at the same time very difficult to use (because it's really an action, and also because it's different from the common approach to table markup in many Wikis)
~~1) the table "markup" (action) does not support Wikka markup within its cells
~~1) it does not actually produce **data** table markup (which it should)
~&In my opinion, we should carefully determine what we want to be //able// to do in terms of table markup, and then look if we can find a simpler preliminary solution (a subset) that still enables us to get there. And any preliminary solution should at least address the problem of ease-of-use **and** generating data table markup. --- Even more preliminary, I suspect that it would be possible to make our current table "markup" (action) support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~& It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, there must be a blank line after the table code or it causes a **real** mess, and you can't escape the double pipings/table using double quotes (which I do find irritating....this is probably all easily solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen
~~~& If you want to include HTML markup, then yes we have **two** methods - but I wan't considering HTML markup; but the major drawback of our current table "markup" (action) is that we can't have Wikka markup inside the cells. So I'll see if that can be resolved first. I'm not considering any alternative markup until we have a plan for what we actually want to be able to support. A preliminary solution that may have to be thrown away again later because it doesn't lead to where we want to end up will just lead to endless confusion and waste a lot of effort. (Meanwhile, if Richard's code works for you, I won't stop you using it. ;-)) --JavaWoman ---
~~~& On further investigation, I found it's actually very simple to change the ""{{table}}"" action (pseudo-markup) so that it does support Wikka markup within the cells. In fact, nearly done, and I may come up with a version that does headers (##th##) as well. That should tide us over until we have decided on a direction for table **markup**. --JavaWoman
~& Well, scratch "very simple" and make that "reasonably simple" but I've done it. //And// documented it, of course. My re-write of table action is presented on the TableAction page, with documentation and examples on the TableActionInfo page. Please test thoroughly! --JavaWoman

Revision [4673]

Edited on 2005-01-16 07:58:38 by JavaWoman [changed htmlspecialchars test harness to avoid having this page in Category Category]
Additions:
~~~1)""[[CategoryDevelopment test no terminating ; before end &quot]]"" (alpha)---=> [[CategoryDevelopment test no terminating ; before end &quot]]
Deletions:
~~~1)""[[CategoryCategory test no terminating ; before end &quot]]"" (alpha)---=> [[CategoryCategory test no terminating ; before end &quot]]

Revision [4383]

Edited on 2005-01-10 17:27:45 by JsnX [small comment to JavaWoman]
Additions:
~~''The show check is in there to prevent the applet code from displaying when not "viewing" a page. Specifically, there were problems with showing a "page history" before this was added. -- JsnX''

Revision [4240]

Edited on 2005-01-07 22:54:04 by IamBack [referring to TableAction as temporary alternative for table markup (and going to inline comment styl]
Additions:
~& ''(//*Blush*// OK, **I** was missing something. From my early days with Wikka, I remembered having seen an "awkward table markup", and (much) later found a table action; the result: I thought we had both. In reality, the "awkward markup" I remembered //was// the action. I'll refactor the stuff below somewhat in view of this.)''--- The problem is not that Wikka has "lack of support for any tables" - we have a table action that serves as a "poor man's table markup". The real problems with this are:
~&In my opinion, we should carefully determine what we want to be //able// to do in terms of table markup, and then look if we can find a simpler preliminary solution (a subset) that still enables us to get there. And any preliminary solution should at least address the problem of ease-of-use **and** generating data table markup. --- Even more preliminary, I suspect that it would be possible to make our current table "markup" (action) support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~& It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, there must be a blank line after the table code or it causes a **real** mess, and you can't escape the double pipings/table using double quotes (which I do find irritating....this is probably all easily solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen
~~~& If you want to include HTML markup, then yes we have **two** methods - but I wan't considering HTML markup; but the major drawback of our current table "markup" (action) is that we can't have Wikka markup inside the cells. So I'll see if that can be resolved first. I'm not considering any alternative markup until we have a plan for what we actually want to be able to support. A preliminary solution that may have to be thrown away again later because it doesn't lead to where we want to end up will just lead to endless confusion and waste a lot of effort. (Meanwhile, if Richard's code works for you, I won't stop you using it. ;-)) --JavaWoman ---
~~~& On further investigation, I found it's actually very simple to change the ""{{table}}"" action (pseudo-markup) so that it does support Wikka markup within the cells. In fact, nearly done, and I may come up with a version that does headers (##th##) as well. That should tide us over until we have decided on a direction for table **markup**. --JavaWoman
~& Well, scratch "very simple" and make that "reasonably simple" but I've done it. //And// documented it, of course. My re-write of table action is presented on the TableAction page, with documentation and examples on the TableActionInfo page. Please test thoroughly! --JavaWoman
Deletions:
~''(//*Blush*// OK, **I** was missing something. From my early days with Wikka, I remembered having seen an "awkward table markup", and (much) later found a table action; the result: I thought we had both. In reality, the "awkward markup" I remembered //was// the action. I'll refactor the stuff below somewhat in view of this.)''--- The problem is not that Wikka has "lack of support for any tables" - we have a table action that serves as a "poor man's table markup". The real problems with this are:
~In my opinion, we should carefully determine what we want to be //able// to do in terms of table markup, and then look if we can find a simpler preliminary solution (a subset) that still enables us to get there. And any preliminary solution should at least address the problem of ease-of-use **and** generating data table markup.
~Even more preliminary, I suspect that it would be possible to make our current table "markup" (action) support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~''It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, there must be a blank line after the table code or it causes a **real** mess, and you can't escape the double pipings/table using double quotes (which I do find irritating....this is probably all easily solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen''
~~~If you want to include HTML markup, then yes we have **two** methods - but I wan't considering HTML markup; but the major drawback of our current table "markup" (action) is that we can't have Wikka markup inside the cells. So I'll see if that can be resolved first. I'm not considering any alternative markup until we have a plan for what we actually want to be able to support. A preliminary solution that may have to be thrown away again later because it doesn't lead to where we want to end up will just lead to endless confusion and waste a lot of effort. (Meanwhile, if Richard's code works for you, I won't stop you using it. ;-)) --JavaWoman
~~~On further investigation, I found it's actually very simple to change the ""{{table}}"" action (pseudo-markup) so that it does support Wikka markup within the cells. In fact, nearly done, and I may come up with a version that does headers (##th##) as well. That should tide us over until we have decided on a direction for table **markup**. --JavaWoman

Revision [4203]

Edited on 2005-01-07 15:57:43 by JavaWoman [heading added (it helps, really!)]
Additions:
==Table markup==

Revision [4107]

Edited on 2005-01-06 20:58:27 by JavaWoman [layout (minor)]

No Differences

Revision [4095]

Edited on 2005-01-06 19:46:57 by ChristianBarthelemy [Minor update]
Additions:
- Take a look at GroupManagement (which doesn't seem to be finished) - or at ACLsWithUserGroups.
Deletions:
- Take a look at GroupManagement (which doesn't seem to be finished)

Revision [4083]

Edited on 2005-01-06 18:34:07 by JavaWoman [more on table markup]
Additions:
~''(//*Blush*// OK, **I** was missing something. From my early days with Wikka, I remembered having seen an "awkward table markup", and (much) later found a table action; the result: I thought we had both. In reality, the "awkward markup" I remembered //was// the action. I'll refactor the stuff below somewhat in view of this.)''--- The problem is not that Wikka has "lack of support for any tables" - we have a table action that serves as a "poor man's table markup". The real problems with this are:
~~1) this table "markup" (action) is basic, but at the same time very difficult to use (because it's really an action, and also because it's different from the common approach to table markup in many Wikis)
~~1) the table "markup" (action) does not support Wikka markup within its cells
~~1) it does not actually produce **data** table markup (which it should)
~In my opinion, we should carefully determine what we want to be //able// to do in terms of table markup, and then look if we can find a simpler preliminary solution (a subset) that still enables us to get there. And any preliminary solution should at least address the problem of ease-of-use **and** generating data table markup.
~Even more preliminary, I suspect that it would be possible to make our current table "markup" (action) support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~~If you want to include HTML markup, then yes we have **two** methods - but I wan't considering HTML markup; but the major drawback of our current table "markup" (action) is that we can't have Wikka markup inside the cells. So I'll see if that can be resolved first. I'm not considering any alternative markup until we have a plan for what we actually want to be able to support. A preliminary solution that may have to be thrown away again later because it doesn't lead to where we want to end up will just lead to endless confusion and waste a lot of effort. (Meanwhile, if Richard's code works for you, I won't stop you using it. ;-)) --JavaWoman
~~~On further investigation, I found it's actually very simple to change the ""{{table}}"" action (pseudo-markup) so that it does support Wikka markup within the cells. In fact, nearly done, and I may come up with a version that does headers (##th##) as well. That should tide us over until we have decided on a direction for table **markup**. --JavaWoman
Deletions:
~The problem is not that Wikka has "lack of support for any tables" - on the contrary, we have **both** table markup **and** a table action. The real problems are:
~~1) the current table markup is extremely difficult to use (because of how it looks and works, and also because it's different from the common appraoch in many Wikis)
~~1) the table markup does not support Wikka markup within its cells
~~1) the table action is rather simple to use but is very limited
~~1) neither actually produce **data** table markup (which they should)
~In my opinion, we should carefully determine what we want to be //able// to do, and then look if we can find a simpler preliminary solution that still enables us to get there. And any preliminary solution should at least address the problem of ease-of-use **and** generating data table markup.
~Even more preliminary, I suspect that it would be possible to make our current table markup (''do you mean the html markup? or am I missing something??'' - No. Yes. :) You're missing Wikka table markup! ''Um, maybe I don't know about it?? Could you link me to the page supporting it? thanks.'') support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~~If you want to include HTML markup, then we have **three** methods since we have an action **and** table markup already (except, as I pointed out, it's not easy to use because of its format and different syntax from what is used in many other Wikis); but the major drawback of our current table markup (as I understand it) is that we can't have Wikka markup inside the cells. So I'll see if that can be resolved first. I'm not considering HTML markup, and I'm not considering any alternative markup until we have a plan for what we actually want to be able to support. A preliminary solution that may have to be thrown away again later because it doesn't lead to where we want to end up will just lead to endless confusion and waste a lot of effort. (Meanwhile, if Richard's code works for you, I won't stop you using it. ;-)) --JavaWoman

Revision [4077]

Edited on 2005-01-06 14:50:11 by GmBowen [reply to JW & question]
Additions:
~Even more preliminary, I suspect that it would be possible to make our current table markup (''do you mean the html markup? or am I missing something??'' - No. Yes. :) You're missing Wikka table markup! ''Um, maybe I don't know about it?? Could you link me to the page supporting it? thanks.'') support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
Deletions:
~Even more preliminary, I suspect that it would be possible to make our current table markup (''do you mean the html markup? or am I missing something??'' - No. Yes. :) You're missing Wikka table markup!) support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman

Revision [4075]

Edited on 2005-01-06 14:36:57 by JavaWoman [reply to GmBowen about table markup]
Additions:
~Even more preliminary, I suspect that it would be possible to make our current table markup (''do you mean the html markup? or am I missing something??'' - No. Yes. :) You're missing Wikka table markup!) support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~''It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, there must be a blank line after the table code or it causes a **real** mess, and you can't escape the double pipings/table using double quotes (which I do find irritating....this is probably all easily solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen''
~~~If you want to include HTML markup, then we have **three** methods since we have an action **and** table markup already (except, as I pointed out, it's not easy to use because of its format and different syntax from what is used in many other Wikis); but the major drawback of our current table markup (as I understand it) is that we can't have Wikka markup inside the cells. So I'll see if that can be resolved first. I'm not considering HTML markup, and I'm not considering any alternative markup until we have a plan for what we actually want to be able to support. A preliminary solution that may have to be thrown away again later because it doesn't lead to where we want to end up will just lead to endless confusion and waste a lot of effort. (Meanwhile, if Richard's code works for you, I won't stop you using it. ;-)) --JavaWoman
Deletions:
~Even more preliminary, I suspect that it would be possible to make our current table markup (''do you mean the html markup? or am I missing something??''support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, there must be a blank line after the table code or it causes a **real** mess, and you can't escape the double pipings/table using double quotes (which I do find irritating....this is probably all easily solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen''

Revision [4071]

Edited on 2005-01-06 14:04:45 by GmBowen [(further) reply to JW & link to try table markup]
Additions:
~~It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, there must be a blank line after the table code or it causes a **real** mess, and you can't escape the double pipings/table using double quotes (which I do find irritating....this is probably all easily solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen''
Deletions:
~~It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, and there must be a blank line after the table code or it causes a **real** mess (I suspect this is all solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen''

Revision [4070]

Edited on 2005-01-06 13:58:46 by GmBowen [reply to JW & a link to try the wikka table markup out]
Additions:
~Even more preliminary, I suspect that it would be possible to make our current table markup (''do you mean the html markup? or am I missing something??''support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman
~~It was unfair of me to say that we don't have "any table support"....there's both the action & html markup....I meant wikka-markup table support that is simple and straightforward to use by "real" people (as opposed to us). Anyhow, I should, in fairness, point out that Richard's code has limitations. You can't put it around ""===header==="" code, ""@@centering@@"" breaks the interpreter, and there must be a blank line after the table code or it causes a **real** mess (I suspect this is all solvable....just not by me I'm afraid). If anybody wants to "play" go [[http://131.202.167.33/wikichanges/wikka.php?wakka=SandBox here]]. -- GmBowen''
Deletions:
~Even more preliminary, I suspect that it would be possible to make our current table markup support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman

Revision [4064]

Edited on 2005-01-06 08:23:08 by JavaWoman [comment on Mike's table proposal]
Additions:
~The problem is not that Wikka has "lack of support for any tables" - on the contrary, we have **both** table markup **and** a table action. The real problems are:
~~1) the current table markup is extremely difficult to use (because of how it looks and works, and also because it's different from the common appraoch in many Wikis)
~~1) the table markup does not support Wikka markup within its cells
~~1) the table action is rather simple to use but is very limited
~~1) neither actually produce **data** table markup (which they should)
~In my opinion, we should carefully determine what we want to be //able// to do, and then look if we can find a simpler preliminary solution that still enables us to get there. And any preliminary solution should at least address the problem of ease-of-use **and** generating data table markup.
~Even more preliminary, I suspect that it would be possible to make our current table markup support Wikka markup within the cells by making a change to how the Formatter processes a page - this should already address a major drawback of what we currently have and give us some breathing space to come up with a different, better markup. --JavaWoman

Revision [4058]

Edited on 2005-01-06 05:10:46 by GmBowen [advocating for simple table support]
Additions:
Richard Berg has provided code for very simple table code that could be placed in formatters/wakka.php. I think that one weakness that wikka has is the lack of support for any tables. Sure, I know people are thinking about syntax & extended features etc etc (I've contributed to that discussion) but I'd like to suggest that "simple" table support should be provided now if possible. Richard's code builds a table (and keep wikka links and formatting) using....
||cell1||cell2||**boldcell3**||
||cell4||cell5||//italicscell6//||
which is a basal example of code formatting we were thinking of using anyways, so when we do end up supporting tables in a more complex fashion, it should be reasonably simple for users with tables to adapt their previous code to the new code base. Anyways, I'd like to suggest that we add this code into the next release to provide basic table support. -- GmBowen

Revision [3846]

Edited on 2004-12-30 23:42:12 by NilsLindenberg [check of usernames against pagenames moved to WikkaBugsResolved]
Deletions:
===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)<?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;
?>%%
~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

Revision [3619]

Edited on 2004-12-22 21:53:52 by JavaWoman [layout]
Additions:
~-**header.php** little additions to get valid html (think its the right context here for this---""--""NilsLindenberg)
~~-adding a doctype before the <html>:%%(html4strict)
~~-changing the <style> to <style type="text/css">
~~-changing the function test, so that a failed test won't result in unclosed pages:---change the line about $stopOnError to:%%(php)
Deletions:
~-**header.php** little additions to get valid html (think its the right context here for this --NilsLindenberg):
~~ adding a doctype before the <html>:
%%(html4strict)
~~ changing the <style> to <style type="text/css">
~~ changing the function test, so that a failed test won't result in unclosed pages:
change the line about $stopOnError to
%%(php)

Revision [3618]

Edited on 2004-12-22 21:02:54 by NilsLindenberg [changed layout]
Additions:
~-**header.php** little additions to get valid html (think its the right context here for this --NilsLindenberg):
Deletions:
~-**header.php** little additions to get valid html:
~~--NilsLindenberg

Revision [3617]

Edited on 2004-12-22 20:58:08 by NilsLindenberg [added little code change for setup/header.php]
Additions:
~-**header.php** little additions to get valid html:
~~ adding a doctype before the <html>:
%%(html4strict)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
~~ changing the <style> to <style type="text/css">
~~ changing the function test, so that a failed test won't result in unclosed pages:
change the line about $stopOnError to
%%(php)
if ($stopOnError)
include('setup/footer.php');
exit;
~~--NilsLindenberg
====For the next minor release====
====For the next major release====
Deletions:
[for the next minor release]
[for the next major release]

Revision [3612]

Edited on 2004-12-22 12:46:27 by JavaWoman [adding notes to GmBowen's reaction to proposed newpage action removal]
Additions:
~''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 processor...one 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''
Deletions:
~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. 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. Kids (and other users I would argue) will want to start a new page like they do in a word processor...one or two clicks only (and in my environment the URL bar is hidden, so they can't do it that way). 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. 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.

Revision [3608]

Edited on 2004-12-22 12:23:26 by JavaWoman [referring to completed WikkaGeshiIntegration with installation code]
Additions:
(See **detailed integration solution** in WikkaGeshiIntegration, complete with installer/updater code.)
Deletions:
(See worked out solution in WikkaGeshiIntegration (except for installer/updater - will follow soon))

Revision [3532]

Edited on 2004-12-20 14:57:10 by JavaWoman [htmlspecialchars() solution; other minor edits in my contribution]
Additions:
~-**htmlspecialchars_unicode()**:
looking at the code I'm sure this will not work correctly. It wil "accept" numerical entity references but not named entity references - so those still won't work. (And actually, its operation doesn't have anything to do with **Unicode**, only with entities - which //may// encode Unicode characters but entities are not themselves Unicode.)
~//See my item 'Non-breaking space in forced links' in the SuggestionBox: this is one case that actually **shows** the function htmlspecialchars_unicode() does not work correctly!//
~Here's the solution: **a new function ##htmlspecialchars_ent()##** to replace the proposed (beta) ##htmlspecialchars_unicode()##:
~%%(php) /**
* Wrapper around PHP's htmlspecialchars() which preserves (repairs) entity references.
* The function accepts the same parameters as htmlspecialchars() in PHP and passes them on
* to that function.
* One defaults here is different here from that in htmlspecialchars() in PHP:
* charset is set to UTF-8 so we're ready for UTF-8 support (and as long as we don't support
* that there should be no difference with Latin-1); on systems where the charset parameter
* is not available or UTF-8 is not supported this will revert to Latin-1 (ISO-8859-1).
* The function first applies htmlspecialchars() to the input string and then "unescapes"
* character entity references and numeric character references (both decimal and hexadecimal).
* Entities are recognized also if the ending semicolon is omitted at the end or before a
* newline or tag but for consistency the semicolon is always added in the output where it was
* omitted.
* NOTE:
* Where code should be rendered _as_code_ the original PHP function should be used so that
* entity references are also rendered as such instead of as their corresponding characters.
* @access public
* @since wikka 1.1.6.0
* @version 1.0
* @todo (later) support full range of situations where (in SGML) a terminating ; may legally
* be omitted (end, newline and tag are merely the most common ones).
* @param string $text required: text to be converted
* @param integer $quote_style optional: quoting style - can be ENT_COMPAT (default, escape
* only double quotes), ENT_QUOTES (escape both double and single quotes) or
* ENT_NOQUOTES (don't escape any quotes)
* @param string $charset optional: charset to use while converting; default UTF-8
* (overriding PHP's default ISO-8859-1)
* @return string converted string with escaped special characted but entity references intact
function htmlspecialchars_ent($text,$quote_style=ENT_COMPAT,$charset='UTF-8')
// define patterns
$alpha = '[a-z]+'; # character entity reference
$numdec = '#[0-9]+'; # numeric character reference (decimal)
$numhex = '#x[0-9a-f]+'; # numeric character reference (hexadecimal)
$terminator = ';|(?=($|[\n<]|<))'; # semicolon; or end-of-string, newline or tag
$entitystring = $alpha.'|'.$numdec.'|'.$numhex;
$escaped_entity = '&('.$entitystring.')('.$terminator.')';
// execute PHP built-in function, passing on optional parameters
$output = htmlspecialchars($text,$quote_style,$charset);
// "repair" escaped entities
// modifiers: s = across lines, i = case-insensitive
$output = preg_replace('/'.$escaped_entity.'/si',"&$1;",$output);
// return output
return $output;
%%
~~I created a test harness for it (I tested with ##htmlspecialchars()## in the Link() function in ##wikka.php## replaced by ##htmlspecialchars_ent()##:
~~~1)""[[HomePage word & notherword]]"" (to be escaped)---=> [[HomePage word & notherword]]
~~~1)""[[JavaWoman Java&nbsp;Woman]]"" (alpha: no-breaking space)---=> [[JavaWoman Java Woman]]
~~~1)""[[JavaWoman &Auml;hnlich]]"" (alpha with uppercase)---=> [[JavaWoman Ähnlich]]
~~~1)no terminating ; before tag &quot<span style="color:blue;">blue</span>&quot; (alpha: text, not link)---=> ""no terminating ; before tag "<span style="color:blue;">blue</span>"""
~~~1)""[[CategoryCategory test no terminating ; before end &quot]]"" (alpha)---=> [[CategoryCategory test no terminating ; before end &quot]]
~~~1)""[[FormattingRules <b>no ; before tag &#039</b>]]"" (numeric decimal)---=> [[FormattingRules <b>no ; before tag '</b>]]
~~~1)""[[SandBox missing ; before &#x3f5""---
~~~""|<- newline]]"" (numeric hex)---=> [[SandBox missing ; before &#x3f5
|<- newline]]
~~There are problems (now) with test cases 2, 3, 5, 6 and 7; with my proposed solution all testcases are converted correctly.
~~**Note:** The formatter does not recognize forced links with newline in description text (test case 7)! There is nothing wrong with having a newline inside a link description. => This requires small fix in wakka formatter (**##./formatters/wakka.php##**), as follows:
~~replace:
~~%%(php) // forced links
// \S : any character that is not a whitespace character
// \s : any whitespace character
else if (preg_match("/^\[\[(\S*)(\s+(.+))?\]\]$/", $thing, $matches))
%%
~~by:
~~%%(php) // forced links
// \S : any character that is not a whitespace character
// \s : any whitespace character
else if (preg_match("/^\[\[(\S*)(\s+(.+))?\]\]$/s", $thing, $matches)) # s modifier: recognize forced links across lines
%%
~~Finally: the call in **##./formatters/ini.php##** should be restored to:
~~%%(php)$text = htmlspecialchars($text, ENT_QUOTES);%%
~~and in **##./formatters/code.php##** we should also use %%(php)htmlspecialchars($text, ENT_QUOTES);%% (i.e, add the ENT_QUOTES parameter).
~~All other calls to htmlspecialchars_unicode() (as well as the definition) should be replaced by htmlspecialchars_ent() above.
~//NOTE: As noted elsewhere: copy code fragments from the **source** of this page, not the rendering, to preserve layout (tabs)!//
~-**wakka.php** (formatter):
~- **showcode.php**
~- uses ENT_QUOTES but not supported (now) by htmlspecialchars_unicode (see solution under htmlspecialchars_unicode above!)
~- **calendar**: not my code: all TABs have been replaced by (irregular) spaces leading to bad worse readability of the code and sloppy layout of the output source (they are in the page **source**, of course, please don't take source from code **display**!)---
~-**install.php** does not remove /actions/wakkabug.php
~-**wikka.php**:
~-**edit.php**
~- **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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.---
~- **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.---
Deletions:
~- htmlspecialchars_unicode():
looking at the code I'm not sure this will work correctly. It wil "accept" numerical entity references but not named entity references - so those still won't work. (And strictly, its operation doesn't have anything to do with **Unicode**, only with entities - which //may// encode Unicode characters but entities are not themselves Unicode.)
~- wakka.php (formatter)
~- showcode.php
~- uses ENT_QUOTES but not supported (now) by htmlspecialchars_unicode (see notes about formatting above)
~- calendar: not my code: all TABs have been replaced by (irregular) spaces leading to bad worse readability of the code and sloppy layout of the output source (they are in the page **source**, of course, please don't take source from code **display**!)---
~- install.php does not remove /actions/wakkabug.php
~- wikka.php
~- edit.php
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.---
~- 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.---

Revision [3350]

Edited on 2004-12-17 12:41:44 by GmBowen [reply to JW ; )]
Additions:
~~~''Liberia???? Japan I get (beaten in war). OAS I get (sucking up to U.S. ;) ). LIBERIA??? Liberia I don't get. ''(Simple, look up the [[http://en.wikipedia.org/wiki/Liberia#History history of Liberia]]; knowing that I could easily //guess// they'd be using American English''(oh ya, I see what you mean. I'd forgotten that bit of history.)''. And where did you think the name Liberia came from? --JW)'' BTW, I didn't mean that spelling was ironic, I meant that the decision was, given efforts by various members on this wiki to "internationalize" the wiki. (Or, I could rename the file. Writing an action to include an action is a programmer's solution obviously. LOL ;-} ) -- Mike''
~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. 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. Kids (and other users I would argue) will want to start a new page like they do in a word processor...one or two clicks only (and in my environment the URL bar is hidden, so they can't do it that way). 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. 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.
Deletions:
~~~''Liberia???? Japan I get (beaten in war). OAS I get (sucking up to U.S. ;) ). LIBERIA??? Liberia I don't get. ''(Simple, look up the [[http://en.wikipedia.org/wiki/Liberia#History history of Liberia]]; knowing that I could easily //guess// they'd be using American English. And where did you think the name Liberia came from? --JW)'' BTW, I didn't mean that spelling was ironic, I meant that the decision was, given efforts by various members on this wiki to "internationalize" the wiki. (Or, I could rename the file. Writing an action to include an action is a programmer's solution obviously. LOL ;-} ) -- Mike''
~It's a little more than that: an alt text is intended to **replace** and image (or other embedded content) when it is not shown: that will also happen when you surf with a text-only browser, or when you are surfing with a graphical browser with images turned off or a slow connection where retrieving an image may time out or just be slow - in all those cases the alt text will be shown, and should be meaninful as a **replacement**, in context. --JW

Revision [3349]

Edited on 2004-12-17 12:22:49 by JavaWoman [remark about Liberia ;-)]
Additions:
~~~''Liberia???? Japan I get (beaten in war). OAS I get (sucking up to U.S. ;) ). LIBERIA??? Liberia I don't get. ''(Simple, look up the [[http://en.wikipedia.org/wiki/Liberia#History history of Liberia]]; knowing that I could easily //guess// they'd be using American English. And where did you think the name Liberia came from? --JW)'' BTW, I didn't mean that spelling was ironic, I meant that the decision was, given efforts by various members on this wiki to "internationalize" the wiki. (Or, I could rename the file. Writing an action to include an action is a programmer's solution obviously. LOL ;-} ) -- Mike''
Deletions:
~~~''Liberia???? Japan I get (beaten in war). OAS I get (sucking up to U.S. ;) ). LIBERIA??? Liberia I don't get. BTW, I didn't mean that spelling was ironic, I meant that the decision was, given efforts by various members on this wiki to "internationalize" the wiki. (Or, I could rename the file. Writing an action to include an action is a programmer's solution obviously. LOL ;-} ) -- Mike''

Revision [3348]

Edited on 2004-12-17 12:15:20 by JavaWoman [layout]
Additions:
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.---
~- 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.---
Deletions:
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.
~- 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.

Revision [3342]

Edited on 2004-12-17 09:27:52 by JavaWoman [replies to GmBowen]
Additions:
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). 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
~- 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
~It's a little more than that: an alt text is intended to **replace** and image (or other embedded content) when it is not shown: that will also happen when you surf with a text-only browser, or when you are surfing with a graphical browser with images turned off or a slow connection where retrieving an image may time out or just be slow - in all those cases the alt text will be shown, and should be meaninful as a **replacement**, in context. --JW
Deletions:
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). 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
~- 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

Revision [3338]

Edited on 2004-12-17 03:52:26 by GmBowen [comments on JW's comments.....]
Additions:
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). 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
~- 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
Deletions:
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.
~- 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.

Revision [3336]

Edited on 2004-12-17 00:15:34 by JavaWoman [minor edit]
Additions:
~- (200 etc.) integration of GeSHi not very clean (see my proposal in WikkaGeshiIntegration)
Deletions:
~- (200 etc.) integration of GeSHi not very clean (can I make a proposal?)

Revision [3335]

Edited on 2004-12-17 00:12:29 by JavaWoman [minor text formatting]
Additions:
looking at the code I'm not sure this will work correctly. It wil "accept" numerical entity references but not named entity references - so those still won't work. (And strictly, its operation doesn't have anything to do with **Unicode**, only with entities - which //may// encode Unicode characters but entities are not themselves Unicode.)
Also, there is no option for the ##quote_style## and ##charset## parameters as in the PHP original, so we lose functionality here, too. It's probably better to have a "wrapper" function around the PHP one, which (after applying the PHP function, passing on the extra parameters) merely reverts all ampersands that are for any entity references (numerical or named); thus the wrapper function should accept all parameters the PHP function does. And since we are supposed to produce XHTML, ENT_QUOTES should probably be the default for ##quote_style##; maybe also UTF-8 should be the default for ##charset##?
Note: the INI code formatter used ENT_QUOTES and this has now disappeared (it was there for a reason!). But an entity used in **code** should be visible as an entity, not as the character it encodes. Conclusion: a code formatter //should// use the PHP function htmlspecialchars() so that any entities are "escaped".
Deletions:
looking at the code I'm not sure this will work correctly. It wil "accept" numerical entity references but not named entity references. (And strictly, its operation doesn't have anything to do with **Unicode**, only with entities ~- which //may// encode Unicode characters but entities are not themselves Unicode.)
Also, there is no option for the quote_style and charset parameters as in the PHP original, so we lose functionality here, too. It's probably better to have a "wrapper" function around the PHP one, which (after applying the PHP function, passing on the extra parameters) merely reverts all ampersands that are for any entity references (numerical or named); thus the wrapper function should accept all parameters the PHP function does. And since we are supposed to produce XHTML, ENT_QUOTES should probably be the default for quote_style; maybe also UTF-8 should be the default for charset?
(Note: the INI code formatter used ENT_QUOTES and this has now disappeared. But should code formatters not encode all entities? An entity used in **code** should be visible as an entity, not as the character it encodes.)

Revision [3334]

Edited on 2004-12-17 00:02:36 by JavaWoman [minor layout]
Additions:
~- calendar: not my code: all TABs have been replaced by (irregular) spaces leading to bad worse readability of the code and sloppy layout of the output source (they are in the page **source**, of course, please don't take source from code **display**!)---
Deletions:
~- calendar: not my code: all TABs have been replaced by (irregular) spaces leading to bad worse readability of the code and sloppy layout of the output source (they are in the page **source**, of course, please don't take source from code **display**!)

Revision [3329]

Edited on 2004-12-16 19:08:22 by JavaWoman [ypot in 1.1.6.0beta review]
Additions:
(Note: the INI code formatter used ENT_QUOTES and this has now disappeared. But should code formatters not encode all entities? An entity used in **code** should be visible as an entity, not as the character it encodes.)
Deletions:
(Note: the INI code formatter used ENT_QUOTES and this has now disappeared. But should code formatters not encode all entities? An entity used in **ode** should be visible as an entity, not as the character it encodes.)

Revision [3328]

Edited on 2004-12-16 19:07:09 by JavaWoman [notes on 1.1.6.0beta]
Additions:
===Things to be fixed before releasing wikka-1.1.6.0 (JW's take):===
After (and in addition to) all the discussion above triggered by DarTar's notes, here are my own observations based on careful code inspection (sometimes better than testing ;-)). See also my thoughts in WikkaGeshiIntegration.
//Numbers within brackets refer to (approximate) line numbers.//
==GeSHi integration==
See also WikkaGeshiIntegration.
general:
~- version included is 1.0.3 - this was buggy and 1.0.4 is out now: this version (or any later one available) should be bundled.
resolved in version 1.0.4:
~- documentation missing (readme refers to this missing documentation) - is included in docs directory in 1.0.4
~- contains zero-byte css-gen.cfg (still in 1.0.4) -> but cssgen.php is now included in contrib dir in 1.0.4
~- example.php missing - in contrib dir in 1.0.4
~- html parsing is done with html4strict.php (please don't rename)
integration:
(See worked out solution in WikkaGeshiIntegration (except for installer/updater - will follow soon))
~- do NOT hardcode paths within a function (ever!); people may already have a modded version of GeSHi on their system and want to use this: include path and $path should be defined in (a separate section of) the configuration (see also WikkaCodeStructure)
~- also allow configuration of such things as tab width and showing line numbers, so people don't have to hack wikka.php to accomplish this
~- always instantiate object as reference:---
##""$geshi"" **=&** ""new GeShi($sourcecode, $language, $this->geshi_path);""##
to be done:
~- css.php needs reverse-sort of keywords (done on Wikka site?); this change also needs to be documented in included source (and file mailed back to author)
~- possibly also for other language files? -> check!---
=> at least ones that are highly likely to be used in our (online) implementation:
~- sql
~- html4strict
~- java (?), not all are sorted either
~- javascript (doesn't look like a problem)
==Bugs and other issues/problems==
==//Major//==
formatting:
~- htmlspecialchars_unicode():
looking at the code I'm not sure this will work correctly. It wil "accept" numerical entity references but not named entity references. (And strictly, its operation doesn't have anything to do with **Unicode**, only with entities ~- which //may// encode Unicode characters but entities are not themselves Unicode.)
Also, there is no option for the quote_style and charset parameters as in the PHP original, so we lose functionality here, too. It's probably better to have a "wrapper" function around the PHP one, which (after applying the PHP function, passing on the extra parameters) merely reverts all ampersands that are for any entity references (numerical or named); thus the wrapper function should accept all parameters the PHP function does. And since we are supposed to produce XHTML, ENT_QUOTES should probably be the default for quote_style; maybe also UTF-8 should be the default for charset?
(Note: the INI code formatter used ENT_QUOTES and this has now disappeared. But should code formatters not encode all entities? An entity used in **ode** should be visible as an entity, not as the character it encodes.)
~- wakka.php (formatter)
~- (121) class replaced by align - should be class (only spelled 'center' instead of 'center' - and make sure CSS corresponds)
~- (200 etc.) integration of GeSHi not very clean (can I make a proposal?)
~- (371/376) '|' should not be part of $mindmappattern ? what's with the---##""if ($this->method == "show")""## ?? ---don't understand what's happening here (document! especially since this deviates from the normal "pattern")
~- turning an image URL into an image link causes invalid XHTML (although syntactically valid, semantically it's **in**valid - and this cannot be solved: it's not possoible to provide a meaningful alt atribute with just a URL); since it always produces invalid (X)HTML I consider this a bug. In order to be able to produce valid XHTML (as we claim!) this formatting feature should be removed; images can still be included with the image action (which should be corrected, see below).
handlers:
~- showcode.php
~- uses ENT_QUOTES but not supported (now) by htmlspecialchars_unicode (see notes about formatting above)
~- layout could be a bit better (wrap a class 'page' div around output)
~- calendar: not my code: all TABs have been replaced by (irregular) spaces leading to bad worse readability of the code and sloppy layout of the output source (they are in the page **source**, of course, please don't take source from code **display**!)
=> **Note:** working with CVS (on ""SourceForge"") - and access to it for developers - could prevent this sort of code mangling.
==//Minor//==
installer:
~- install.php does not remove /actions/wakkabug.php
main:
~- wikka.php
~- (499) RE for InterWiki link not the same as in (formatter) wakka.php
handlers:
~- edit.php
~- (3) check for valid page name should be done only for new pages
~- (145) title on message is redundant (and worse than the link description itself, which is just fine by itself): should be removed
actions:
~- 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 1.1.6.0beta! So it's not resolved, and unchanged from 1.1.5.3). I think it's much better to remove it though.
~- 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.
--JavaWoman

Revision [3255]

Edited on 2004-12-15 19:45:46 by JavaWoman [replacing HelpInfo by WikkaDocumentation]
Additions:
- WikkaDocumentation shipped with the installation (or maybe [[IncludeRemote not]]);
Deletions:
- [[HelpInfo documentation]] shipped with the installation (or maybe [[IncludeRemote not]]);

Revision [3221]

Edited on 2004-12-15 10:08:13 by JavaWoman [minor edits to make discussion look a little less silly :)]
Additions:
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as WikkaReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating? (''So rename it WikkaReleaseNotes **here** and include **that** page as a system page. I agree that the name is not optimal - but the same is true here already. **Note**: this rename has been done now --JW'')
~~- we rename the ""ReleaseNotes"" page on this server as WikkaReleaseNotes; **Note**: done now --JW
[[http://wikka.jsnx.com/WikkaDocumentation main Wikka server]]%%
~~~~''Actually, I'd like to see our current ""ReleaseNotes"" page here renamed to **WikkaReleaseNotes**; pages relating to Wikka itself really should start with 'Wikka': we already have WikkaDevelopment, WikkaBugs, WikkaBugsResolved, etc. (why not WikkaDocumentation?) - WikkaReleaseNotes would neatly fit into that pattern and be clearer than just """ReleaseNotes""". Then someone writing about, say, a Calendar can create a page like FancyCalendarWikkaReleaseNotes etc. ---I agree with DarTar that a page with a static link to the online release notes here, to be included with the install, would be a good temporary solution; to be replaced later by a mechanism like FetchRemote (once finished - but let's not wait for that!) (**Note**: edited somewhat for readablity - we now do have WikkaReleaseNotes and WikkaDocumentation as suggested.) --JavaWoman''
Deletions:
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as WikkaReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating? (''So rename it WikkaReleaseNotes **here** and include **that** page as a system page. I agree that the name is not optimal - but the same is true here already.'')
~~- we rename the WikkaReleaseNotes page on this server as WikkaReleaseNotes;
[[http://wikka.jsnx.com/HelpInfo main Wikka server]]%%
~~~~''Actually, I'd like to see our **current** WikkaReleaseNotes page here renamed to **WikkaReleaseNotes**; pages relating to Wikka itself really should start with 'Wikka': we already have WikkaDevelopment, WikkaBugs, WikkaBugsResolved, etc. (why not WikkaDocumentation?) - WikkaReleaseNotes would neatly fit into that pattern and be clearer than just """WikkaReleaseNotes""". Then someone writing about, say, a Calendar can create a page like FancyCalendarWikkaReleaseNotes etc. ---I agree with DarTar that a page with a static link to the online release notes here, to be included with the install, would be a good temporary solution; to be replaced later by a mechanism like FetchRemote (once finished - but let's not wait for that!) --JavaWoman''

Revision [3213]

Edited on 2004-12-15 02:05:39 by JsnX [Renamed ReleaseNotes as WikkaReleaseNotes - please do not "fix"]
Additions:
~-Why not adding WikkaReleaseNotes 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 WikkaReleaseNotes page on the wikka server;
~~''I saw it in the SandBox and it messed up things royally there... disabled it, and added notes about my findings.---I agree with Dartar, I'd like to see WikkaReleaseNotes included as a default page; if one doesn't look at it, fine, but at least it's there if you do need to consult what was changed (and why) and it's much more readable than what ""{{wikkachanges}}"" produces. I'd vote for just removing the ""{{wikkachanges}}"" action and simply including a WikkaReleaseNotes page. --JavaWoman''
~~~''My 2 cents. On the one hand, I agree with JW as far as //readability// is concerned: it is much better to have a formatted version, with headers etc., possibly with links, than a plain-text version (the first thing I thought when I saw the SandBox page full of raw text was : "gosh, the formatters are broken!"). This said, there is a question that none of you has mentioned so far. How are we going to deal with //internal links// that are present in the current WikkaReleaseNotes page? Either we distribute a version of WikkaReleaseNotes with no internal links and no camelcase words left or we have to think of a solution to avoid generating a ton of missing pages. IMO, one interesting solution (which might require some futher development, though) is to use a [[IncludeRemote FetchRemote]] strategy to retrieve fresh and uptodate documentation on the new release from the main server (JsnX, have you tried to install the plugin locally?). This has the advantage of avoiding writing a hardcoded page in the user's database and - as Jason was suggesting - let the user free to decide where to add the release notes (it is just a matter of adding somewhere ##""{{fetchremote page="WikkaReleaseNotes")""##). On the other hand, I was wondering: is there really a problem with //overwriting// an existing page? Provided the installer says explicitly it is going to overwrite one page, this page will be nothing more than a //version// of the page (that's the power of wikis!): if a note is added like "updated by the Wikka installer", the user will always be able to retrieve previous versions of the same page if needed. So I don't really think that overwriting is a problem. -- DarTar''
~~~~~~''Regarding this point, I don't agree with JW's argument. I think a text version with the release notes, accessible to the Wikka administrator before untarring and uploading the package makes perfectly sense (and actually is very common in software distributions). I really don't see the problem with "keeping information in two places": before releasing a new version, the text release notes can be created in 5 seconds just by copying and pasting in a text editor the formatted output of WikkaReleaseNotes. So where's the problem? -- DarTar''
~~Why don't we focus our energy on making the ""{{wikkachanges}}"" action better? JavaWoman, you are detailing problems with my crappy action that I spent ten minutes on to demonstrate the concept. Wouldn't it be possible to tweak the action to output the text to your satisfaction? (''What I see is is a far less readable version, and if it's in a text file, then how are you going to keep the two synchronized? We **already** have WikkaReleaseNotes - if you just include that it's simpler (it's already there), more reliable (nothing to synchronise, the data is in one place, not two), and more readable (no extra action needed either).'')
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as WikkaReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating? (''So rename it WikkaReleaseNotes **here** and include **that** page as a system page. I agree that the name is not optimal - but the same is true here already.'')
~~I don't like the idea of us forcing pages on people. If we make the release notes as an action, people can have the release notes show on any page they want. They could create a page named WikiEngineChanges and place the ""{{wikkachanges}}"" action on it, and when they upgrade, the changes will show up on the page that **they** decided. (''So they create a page called WikiEngineChanges and just ""{{include}}"" the WikkaReleaseNotes on it.'') If we force a page named WikkaReleaseNotes, we are going to create an unnecessary struggle with site owners that might not want to have the Wikka release notes on a page named WikkaReleaseNotes. (''It's just another "system" page, like SandBox and FormattingRules. I don't see the problem.'') -- JsnX
~~- we rename the WikkaReleaseNotes page on this server as WikkaReleaseNotes;
~~(BTW it might be interesting to add named anchors in WikkaReleaseNotes to facilitate referring to specific Wikka versions)
~~- we distribute with each release a text file, called ##docs/WikkaReleaseNotes.text## with a textual version of the section of WikkaRecentChanges page on the main wikka server concerning the last release.
~~~''For the time being, what about creating a default page called WikkaReleaseNotes containing a static link to the online WikkaReleaseNotes? (see my note above on why creating or overwriting a page during upgrade is not really a problem)'' -- DarTar
~~~~''Actually, I'd like to see our **current** WikkaReleaseNotes page here renamed to **WikkaReleaseNotes**; pages relating to Wikka itself really should start with 'Wikka': we already have WikkaDevelopment, WikkaBugs, WikkaBugsResolved, etc. (why not WikkaDocumentation?) - WikkaReleaseNotes would neatly fit into that pattern and be clearer than just """WikkaReleaseNotes""". Then someone writing about, say, a Calendar can create a page like FancyCalendarWikkaReleaseNotes etc. ---I agree with DarTar that a page with a static link to the online release notes here, to be included with the install, would be a good temporary solution; to be replaced later by a mechanism like FetchRemote (once finished - but let's not wait for that!) --JavaWoman''
~-I propose we update the default HomePage to display the version number, a [[WikkaReleaseNotes what's new]] link pointing to the WikkaReleaseNotes and a link to WikkaDocumentation. Here's my source code proposal for the new default HomePage
Thanks for installing [[Wikka:HomePage WikkaWiki]]! This site is running on version {{version}} (see WikkaReleaseNotes).
~~~~Here it comes: this is Wikka version {{version}}. I wonder if it wouldn't be better to have such basic system plugins handled by the wikka formatter, instead of using an action. And maybe in the future ##""{{version}}""## will print a link (fetchable or not) to WikkaReleaseNotes? -- DarTar
~-Shouldn't we announce in the WikkaReleaseNotes that the //raw// handler has been modified?
~~~- Since the bug has been fixed, I move the code to the resolved bugs. I'll add this bug fix in the WikkaReleaseNotes. -- DarTar
Deletions:
~-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;
~~''I saw it in the SandBox and it messed up things royally there... disabled it, and added notes about my findings.---I agree with Dartar, I'd like to see ReleaseNotes included as a default page; if one doesn't look at it, fine, but at least it's there if you do need to consult what was changed (and why) and it's much more readable than what ""{{wikkachanges}}"" produces. I'd vote for just removing the ""{{wikkachanges}}"" action and simply including a ReleaseNotes page. --JavaWoman''
~~~''My 2 cents. On the one hand, I agree with JW as far as //readability// is concerned: it is much better to have a formatted version, with headers etc., possibly with links, than a plain-text version (the first thing I thought when I saw the SandBox page full of raw text was : "gosh, the formatters are broken!"). This said, there is a question that none of you has mentioned so far. How are we going to deal with //internal links// that are present in the current ReleaseNotes page? Either we distribute a version of ReleaseNotes with no internal links and no camelcase words left or we have to think of a solution to avoid generating a ton of missing pages. IMO, one interesting solution (which might require some futher development, though) is to use a [[IncludeRemote FetchRemote]] strategy to retrieve fresh and uptodate documentation on the new release from the main server (JsnX, have you tried to install the plugin locally?). This has the advantage of avoiding writing a hardcoded page in the user's database and - as Jason was suggesting - let the user free to decide where to add the release notes (it is just a matter of adding somewhere ##""{{fetchremote page="ReleaseNotes")""##). On the other hand, I was wondering: is there really a problem with //overwriting// an existing page? Provided the installer says explicitly it is going to overwrite one page, this page will be nothing more than a //version// of the page (that's the power of wikis!): if a note is added like "updated by the Wikka installer", the user will always be able to retrieve previous versions of the same page if needed. So I don't really think that overwriting is a problem. -- DarTar''
~~~~~~''Regarding this point, I don't agree with JW's argument. I think a text version with the release notes, accessible to the Wikka administrator before untarring and uploading the package makes perfectly sense (and actually is very common in software distributions). I really don't see the problem with "keeping information in two places": before releasing a new version, the text release notes can be created in 5 seconds just by copying and pasting in a text editor the formatted output of ReleaseNotes. So where's the problem? -- DarTar''
~~Why don't we focus our energy on making the ""{{wikkachanges}}"" action better? JavaWoman, you are detailing problems with my crappy action that I spent ten minutes on to demonstrate the concept. Wouldn't it be possible to tweak the action to output the text to your satisfaction? (''What I see is is a far less readable version, and if it's in a text file, then how are you going to keep the two synchronized? We **already** have ReleaseNotes - if you just include that it's simpler (it's already there), more reliable (nothing to synchronise, the data is in one place, not two), and more readable (no extra action needed either).'')
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as ReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating? (''So rename it WikkaReleaseNotes **here** and include **that** page as a system page. I agree that the name is not optimal - but the same is true here already.'')
~~I don't like the idea of us forcing pages on people. If we make the release notes as an action, people can have the release notes show on any page they want. They could create a page named WikiEngineChanges and place the ""{{wikkachanges}}"" action on it, and when they upgrade, the changes will show up on the page that **they** decided. (''So they create a page called WikiEngineChanges and just ""{{include}}"" the ReleaseNotes on it.'') If we force a page named ReleaseNotes, we are going to create an unnecessary struggle with site owners that might not want to have the Wikka release notes on a page named ReleaseNotes. (''It's just another "system" page, like SandBox and FormattingRules. I don't see the problem.'') -- JsnX
~~- we rename the ReleaseNotes page on this server as WikkaReleaseNotes;
~~(BTW it might be interesting to add named anchors in ReleaseNotes to facilitate referring to specific Wikka versions)
~~- we distribute with each release a text file, called ##docs/releasenotes.text## with a textual version of the section of WikkaRecentChanges page on the main wikka server concerning the last release.
~~~''For the time being, what about creating a default page called WikkaReleaseNotes containing a static link to the online ReleaseNotes? (see my note above on why creating or overwriting a page during upgrade is not really a problem)'' -- DarTar
~~~~''Actually, I'd like to see our **current** ReleaseNotes page here renamed to **WikkaReleaseNotes**; pages relating to Wikka itself really should start with 'Wikka': we already have WikkaDevelopment, WikkaBugs, WikkaBugsResolved, etc. (why not WikkaDocumentation?) - WikkaReleaseNotes would neatly fit into that pattern and be clearer than just """ReleaseNotes""". Then someone writing about, say, a Calendar can create a page like FancyCalendarReleaseNotes etc. ---I agree with DarTar that a page with a static link to the online release notes here, to be included with the install, would be a good temporary solution; to be replaced later by a mechanism like FetchRemote (once finished - but let's not wait for that!) --JavaWoman''
~-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
Thanks for installing [[Wikka:HomePage WikkaWiki]]! This site is running on version {{version}} (see ReleaseNotes).
~~~~Here it comes: this is Wikka version {{version}}. I wonder if it wouldn't be better to have such basic system plugins handled by the wikka formatter, instead of using an action. And maybe in the future ##""{{version}}""## will print a link (fetchable or not) to ReleaseNotes? -- DarTar
~-Shouldn't we announce in the ReleaseNotes that the //raw// handler has been modified?
~~~- Since the bug has been fixed, I move the code to the resolved bugs. I'll add this bug fix in the ReleaseNotes. -- DarTar

Revision [3115]

Edited on 2004-12-12 12:24:33 by JavaWoman [more on releases and notes]
Additions:
~~~~~~''As I said above, I don't consider this a problem. But even if you don't agree with this, consider that no one is proposing here to overwrite a page like HomePage, but a page with a sufficiently clear 'system default' name (like WikkaReleaseNotes) that will hardly be modified by Wikka users (and if it is, again, it's just a version..). -- DarTar''
~~~~~''In referring to "keeping information in two places" I'm thinking of a build process, assuming (not the case now!) that **all** the to-be-released files are in a CVS branch, and you just run a script to turn that into a distribution. The files in that branch should -at all times- be up-to-date, which includes any text files to be included. So what happens while you're working on a new release? Something like this - for **every change to be made for the next release**:
~~~~~~- apply a fix or create/add a new extension
~~~~~~- make a corresponding note in WikkaReleaseNotes here
~~~~~~- make a new copy of WikkaReleaseNotes to 'changes' text file
~~~~~~- commit all these files into the CVS---
~~~~~~....
~~~~~~- build (periodically) new beta release or (once) final release
~~~~~The set of files in the repository should be "complete" at all times to be able to do a build; which (in your proposal) means also //repeatedly// copying the WikkaReleaseNotes (manually, or via a script) - not just once, but for every change being made. It's an extra step, and doing that step is a manual process (even if you run a script to do the copying, running the script is a manual step). People do forget steps :), so the fewer manual steps there are, the more reliable the build and release process will be.''
~~~~~''On the other hand, a static WikkaReleaseNotes page with a link to the online WikkaReleaseNotes would need to be created and committed only once; no redundant and easy-to-forget manual steps needed any more. --JavaWoman''
Deletions:
~~~~~~''As I said above, I don't consider this a problem. But even if you don't agree with this, consider that no one is proposing here to overwrite a page like HomePage, but a page with a sufficiently clear 'system default' name (like WIkkaReleaseNotes) that will hardly be modified by Wikka users (and if it is, again, it's just a version..). -- DarTar''

Revision [3114]

Edited on 2004-12-12 10:55:07 by DarTar [steps towards an agreement?]
Additions:
~~~~~~''As I said above, I don't consider this a problem. But even if you don't agree with this, consider that no one is proposing here to overwrite a page like HomePage, but a page with a sufficiently clear 'system default' name (like WIkkaReleaseNotes) that will hardly be modified by Wikka users (and if it is, again, it's just a version..). -- DarTar''
~~- we distribute with each release a text file, called ##docs/releasenotes.text## with a textual version of the section of WikkaRecentChanges page on the main wikka server concerning the last release.
~~ Is this an acceptable compromise? ;) -- DarTar''
Deletions:
~~~~~~''As I said above, I don't really consider this a problem. But even if you don't agree with this, consider that no one is proposing here to overwrite a page like HomePage, but a page with a sufficiently clear 'system default' name (like WIkkaReleaseNotes) that will hardly be modified by Wikka users. -- DarTar''
~~-1) we distribute with each release a text file, called ##docs/releasenotes.text## with a textual version of the section of WikkaRecentChanges page on the main wikka server concerning the last release.
~~ Is this a solution that might convince all of you? ;) -- DarTar''

Revision [3113]

Edited on 2004-12-12 10:51:54 by DarTar [steps towards an agreement?]
Additions:
~~~~~''Actually, many applications have all their documentation online, except maybe a small readme and a license file. Most people don't download first, then unpack an archive, and then read a changes file to see what's in the latest release: they read the release notes online **before even downloading**. Sure a site can be down - that can always happen. Many possible causes (and it happens to the best of them). //As to you being dead and not being able to pay the bill - that's an entirely different discussion (one we should have, about continuity and how to ensure it, but not here in this context).// But the whole idea of including release notes is to provide a reference //after// download and installation - but that won't normally happen until **after** one has checked the release notes online to see whether it's worth the download in the first place.---My argument about keeping the information in two different places and two different formats identical still stands, meanwhile - how do you propose to make sure the two versions have identical information at all times? Even if you have a reliable procedure for that (you'll need a script) - it's extra (unneeded) work, as is creating a special action to show the contents of the text file: two files, two programs, all to show the same content? A simple page that (for now) shows just a link or (later) pulls the content directly from the site will be much simpler. -- JavaWoman''
~~~~~~
~~- we rename the ReleaseNotes page on this server as WikkaReleaseNotes;
~~- we add to the next release the ##""{{version}}""## action;
~~- we create a (temporary) ##""{{wikkachanges}}""## action that prints the following code:''
~~%%===== Wikka Release Notes =====
~~''In the future, this action will be replaced by a FetchRemote action.
~~- we add to the installer/upgrader a line for creating a local WikkaReleaseNotes. The page will contain, for the time being, only ##""{{wikkachanges}}""##. The installer leaves a note about the page creation/upgrade: "written by the Wikka Installer";
~~ Is this a solution that might convince all of you? ;) -- DarTar''
Deletions:
~~~~~''Actually, many applications have all their documentation online, except maybe a small readme and a license file. Most people don't download first, then unpack an archive, and then read a changes file to see what's in the latest release: they read the release notes online **before even downloading**. Sure a site can be down - that can always happen. Many possible causes (and it happens to the best of them). //As to you being dead and not being able to pay the bill - that's an entirely different discussion (one we should have, about continuity and how to ensure it, but not here in this context).// But the whole idea of including release notes is to provide a reference //after// download and installation - but that won't normally happen until **after** one has checked the release notes online to see whether it's worth the download in the first place.---My argument about keeping the information in two different places and two different formats identical still stands, meanwhile - how do you propose to make sure the two versions have identical information at all times? Even if you have a reliable procedure for that (you'll need a script) - it's extra (unneeded) work, as is creating a special action to show the contents of the text file: two files, two programs, all to show the same content? A simple page that (for now) shows just a link or (later) pulls the content directly from the site will be much simpler.''
~~1) we rename the ReleaseNotes page on this server as WikkaReleaseNotes;
~~1) we add to the next release the ##""{{version}}""## action;
~~1) we create a (temporary) ##""{{wikkachanges}}""## action that prints the following code:
%%===== Wikka Release Notes =====
~~In the future, this action will be replaced by a FetchRemote action.
~~-1) we add to the installer/upgrader a line for creating a local WikkaReleaseNotes. The page will contain, for the time being, only ##""{{wikkachanges}}""##. The installer leaves a note about the page creation/upgrade: "written by the Wikka Installer";
~~ Is this a solution that might convince all of you? -- DarTar

Revision [3112]

Edited on 2004-12-12 10:46:19 by DarTar [steps towards an agreement?]
Additions:
~~~~~~''As I said above, I don't really consider this a problem. But even if you don't agree with this, consider that no one is proposing here to overwrite a page like HomePage, but a page with a sufficiently clear 'system default' name (like WIkkaReleaseNotes) that will hardly be modified by Wikka users. -- DarTar''
~~~~~~''Regarding this point, I don't agree with JW's argument. I think a text version with the release notes, accessible to the Wikka administrator before untarring and uploading the package makes perfectly sense (and actually is very common in software distributions). I really don't see the problem with "keeping information in two places": before releasing a new version, the text release notes can be created in 5 seconds just by copying and pasting in a text editor the formatted output of ReleaseNotes. So where's the problem? -- DarTar''
~~''I gave above some more reactions about my way of seeing the problem of release notes. I'd like to propose here some steps towards a solution that I hope we might all agree upon.
~~1) we rename the ReleaseNotes page on this server as WikkaReleaseNotes;
~~1) we add to the next release the ##""{{version}}""## action;
~~1) we create a (temporary) ##""{{wikkachanges}}""## action that prints the following code:
%%===== Wikka Release Notes =====
This server runs on [[[http://wikka.jsnx.com/ Wikka Wiki]] version **{{version}}**.
The new features of the current version are described on the [[http://wikka.jsnx.com/WikkaReleaseNotes main Wikka server]]%%
~~In the future, this action will be replaced by a FetchRemote action.
~~(BTW it might be interesting to add named anchors in ReleaseNotes to facilitate referring to specific Wikka versions)
~~-1) we add to the installer/upgrader a line for creating a local WikkaReleaseNotes. The page will contain, for the time being, only ##""{{wikkachanges}}""##. The installer leaves a note about the page creation/upgrade: "written by the Wikka Installer";
~~-1) we distribute with each release a text file, called ##docs/releasenotes.text## with a textual version of the section of WikkaRecentChanges page on the main wikka server concerning the last release.
~~
~~ Is this a solution that might convince all of you? -- DarTar

Revision [3104]

Edited on 2004-12-11 22:11:21 by JavaWoman [continuing the release notes argument :)]
Additions:
~~~~Sounds absurd, doesn't it?
~~~~~''Um, yes. What goes for the HomePage goes for the WikkaReleaseNotes: "overwriting" simply means creating a new version in the database. So I don't really think that's a problem. ;-) --JW''
~~~~~~''Most site admins would not "upload the [separate] files" but rather upload the archive to the server, untar it there, and then run the upgrade routine. Just untarring would replace all files. And why would one //not// replace a release notes (text) file? It contains all previous information, doesn't it?''
~~~~~~''It **is** known **before** you upgrade because it's right here. --JW''
~~~~~''Actually, many applications have all their documentation online, except maybe a small readme and a license file. Most people don't download first, then unpack an archive, and then read a changes file to see what's in the latest release: they read the release notes online **before even downloading**. Sure a site can be down - that can always happen. Many possible causes (and it happens to the best of them). //As to you being dead and not being able to pay the bill - that's an entirely different discussion (one we should have, about continuity and how to ensure it, but not here in this context).// But the whole idea of including release notes is to provide a reference //after// download and installation - but that won't normally happen until **after** one has checked the release notes online to see whether it's worth the download in the first place.---My argument about keeping the information in two different places and two different formats identical still stands, meanwhile - how do you propose to make sure the two versions have identical information at all times? Even if you have a reliable procedure for that (you'll need a script) - it's extra (unneeded) work, as is creating a special action to show the contents of the text file: two files, two programs, all to show the same content? A simple page that (for now) shows just a link or (later) pulls the content directly from the site will be much simpler.''
Deletions:
~~~~Sounds absurd, doesn't it?

Revision [3100]

Edited on 2004-12-11 19:38:28 by JsnX [the logic of overwriting pages and offline changenotes]
Additions:
~~~~Sorry to keep hammering on this, BUT :), let's see how your logic holds up:
~~~~~Is there really a problem with //overwriting// an existing HomePage? Provided the installer says it is going to overwrite the HomePage, the new HomePage will be nothing more than a //version// of the page. The site admin will always be able to retrieve the previous version of the HomePage if needed. So I don't really think that overwriting the HomePage is a problem.
~~~~Sounds absurd, doesn't it?
~~~~Regarding JavaWoman's comments:
~~~~~Your first point was that the installer would overwrite the text file, so why not overwrite a page.
~~~~~~That's not correct. **The site admin** would overwrite the text file, by his choice of uploading the new file to the webserver. It would be his choice to overwrite the file. See the difference?
~~~~~Your next point was that it's a bad idea to keep the information in two places.
~~~~~~So you are suggesting that we should only make the information available online and **after the upgrade has already happened.** Wouldn't you want to know what has changed **before** you upgrade?
~~~~~I could go on and on. The bottom line: it's standard for software distributions to include a text file that describes changes. This is where most people will look for the information....and they will want to review the changes before they decide to upgrade--not upgrade and then review what has changed. I'm in favor of using ""{{fetchremote}}"" to make the information available online, but also including a text file that can be reviewed offline. Here's an example of how the text file might be useful: Let's say an upgrade breaks an existing site. The admin could view the text file to help narrow his focus for fixing the problem. ... I'm going to throw in one more thing just to preempt it: But couldn't the site admin just view the release notes on WikkaWiki? That's possible, however this site might be down. It could be down from a denial-of-service attack. I could be dead and thus not able to pay the bill. Who knows? By including a text file we won't have to worry about any of this. -- JsnX

Revision [3099]

Edited on 2004-12-11 14:51:12 by DarTar ["Version" action uploaded + PagedComments question]
Additions:
- Your thoughts about PagedComments?
- [[TestSkin user skins]] (with new [[WikkaSkinOptimization css template]]);
Deletions:
- skins (with new [[WikkaSkinOptimization css template]]);

Revision [3097]

Edited on 2004-12-11 12:29:27 by DarTar ["Version" action uploaded.]
Additions:
{{lastedit show="3"}}
Thanks for installing [[Wikka:HomePage WikkaWiki]]! This site is running on version {{version}} (see ReleaseNotes).
~~~~Here it comes: this is Wikka version {{version}}. I wonder if it wouldn't be better to have such basic system plugins handled by the wikka formatter, instead of using an action. And maybe in the future ##""{{version}}""## will print a link (fetchable or not) to ReleaseNotes? -- DarTar
Deletions:
{{lastedit}}
Thanks for installing [[Wikka:HomePage WikkaWiki]]! This site is running on version [[ReleaseNotes 1.1.6.0]]

Revision [3095]

Edited on 2004-12-10 22:40:51 by JavaWoman [version action code]
Additions:
~~~''This should do it: %%(php)<?php
echo $this->VERSION;
?>%% Save as ##actions/version.php## --JavaWoman (who for once doesn't document what she writes. ;o) )''

Revision [3074]

Edited on 2004-12-10 12:48:20 by JavaWoman [further note on release notes inclusion]
Additions:
~~~~''Actually, I'd like to see our **current** ReleaseNotes page here renamed to **WikkaReleaseNotes**; pages relating to Wikka itself really should start with 'Wikka': we already have WikkaDevelopment, WikkaBugs, WikkaBugsResolved, etc. (why not WikkaDocumentation?) - WikkaReleaseNotes would neatly fit into that pattern and be clearer than just """ReleaseNotes""". Then someone writing about, say, a Calendar can create a page like FancyCalendarReleaseNotes etc. ---I agree with DarTar that a page with a static link to the online release notes here, to be included with the install, would be a good temporary solution; to be replaced later by a mechanism like FetchRemote (once finished - but let's not wait for that!) --JavaWoman''

Revision [3070]

Edited on 2004-12-10 12:42:53 by DarTar [Replying on ReleaseNotes]
Additions:
~~~- Since the bug has been fixed, I move the code to the resolved bugs. I'll add this bug fix in the ReleaseNotes. -- DarTar
Deletions:
~~~- Since the bug has been fixed, I move the code to the resolved bugs. I'll add this bug fix in the ReleaseNotes.

Revision [3069]

Edited on 2004-12-10 12:42:10 by DarTar [Replying on ReleaseNotes]
Additions:
~~~- Since the bug has been fixed, I move the code to the resolved bugs. I'll add this bug fix in the ReleaseNotes.
Deletions:
**original**
%%(php)
$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>';
%%
**modified**
%%(php)
$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();
%%
**original**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
if ($_POST["mail"]=="result") {
%%
-- DarTar, 08 Dec 04

Revision [3068]

Edited on 2004-12-10 12:32:04 by DarTar [Replying on ReleaseNotes]
Additions:
~~~''For the time being, what about creating a default page called WikkaReleaseNotes containing a static link to the online ReleaseNotes? (see my note above on why creating or overwriting a page during upgrade is not really a problem)'' -- DarTar

Revision [3067]

Edited on 2004-12-10 12:11:21 by DarTar [Replying on ReleaseNotes]
Additions:
~~~''My 2 cents. On the one hand, I agree with JW as far as //readability// is concerned: it is much better to have a formatted version, with headers etc., possibly with links, than a plain-text version (the first thing I thought when I saw the SandBox page full of raw text was : "gosh, the formatters are broken!"). This said, there is a question that none of you has mentioned so far. How are we going to deal with //internal links// that are present in the current ReleaseNotes page? Either we distribute a version of ReleaseNotes with no internal links and no camelcase words left or we have to think of a solution to avoid generating a ton of missing pages. IMO, one interesting solution (which might require some futher development, though) is to use a [[IncludeRemote FetchRemote]] strategy to retrieve fresh and uptodate documentation on the new release from the main server (JsnX, have you tried to install the plugin locally?). This has the advantage of avoiding writing a hardcoded page in the user's database and - as Jason was suggesting - let the user free to decide where to add the release notes (it is just a matter of adding somewhere ##""{{fetchremote page="ReleaseNotes")""##). On the other hand, I was wondering: is there really a problem with //overwriting// an existing page? Provided the installer says explicitly it is going to overwrite one page, this page will be nothing more than a //version// of the page (that's the power of wikis!): if a note is added like "updated by the Wikka installer", the user will always be able to retrieve previous versions of the same page if needed. So I don't really think that overwriting is a problem. -- DarTar''

Revision [3066]

Edited on 2004-12-10 08:57:35 by JavaWoman [trying to explain why including release notes as a page is a good idea :)]
Additions:
~~Have both of you thought how this would be implemented?? It's easy to include a default page on install. However, what are we going to do on upgrade? Are we going to overwrite the page? (''Yes, of course! And that's what you'd do with a text file as well - what's the difference?'') What if the site has changed the page? (''Include a note on the page that it is a system page that **will** be overwritten on upgrade; if possible protect the page from editing by anyone but admin on install.'') I think it would be annoying for the upgrade script to overwrite an existing page. (''But you //would// be overwriting the text file - what's the difference? A page is just a more readable version. And we wouldn;'t need to keep the same information synchronbized in two places - always a bad idea.'') Hence the solution that I have proposed. In addition, how long is it going to be before someone says, "Hey, why don't we include a text file that lists the changes". (''Maybe **very** long - it hasn't happened, has it? See how it goes.'') Once again, we take care of this by including the text file and then showing it in the wiki. Sites are not going to update the Wikka release notes--it's static data. Why have it as a wiki page? (''For readability, and it fits in simply with the system. Yes, sites are not going to update the release notes - in whatever form. And if they **do** want to update them, they could do that with the text file just as easily.'')
~~Why don't we focus our energy on making the ""{{wikkachanges}}"" action better? JavaWoman, you are detailing problems with my crappy action that I spent ten minutes on to demonstrate the concept. Wouldn't it be possible to tweak the action to output the text to your satisfaction? (''What I see is is a far less readable version, and if it's in a text file, then how are you going to keep the two synchronized? We **already** have ReleaseNotes - if you just include that it's simpler (it's already there), more reliable (nothing to synchronise, the data is in one place, not two), and more readable (no extra action needed either).'')
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as ReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating? (''So rename it WikkaReleaseNotes **here** and include **that** page as a system page. I agree that the name is not optimal - but the same is true here already.'')
~~I don't like the idea of us forcing pages on people. If we make the release notes as an action, people can have the release notes show on any page they want. They could create a page named WikiEngineChanges and place the ""{{wikkachanges}}"" action on it, and when they upgrade, the changes will show up on the page that **they** decided. (''So they create a page called WikiEngineChanges and just ""{{include}}"" the ReleaseNotes on it.'') If we force a page named ReleaseNotes, we are going to create an unnecessary struggle with site owners that might not want to have the Wikka release notes on a page named ReleaseNotes. (''It's just another "system" page, like SandBox and FormattingRules. I don't see the problem.'') -- JsnX
~~''Comments embedded above to make them more relevant to context -- JavaWoman''
Deletions:
~~Have both of you thought how this would be implemented?? It's easy to include a default page on install. However, what are we going to do on upgrade? Are we going to overwrite the page? What if the site has changed the page? I think it would be annoying for the upgrade script to overwrite an existing page. Hence the solution that I have proposed. In addition, how long is it going to be before someone says, "Hey, why don't we include a text file that lists the changes". Once again, we take care of this by including the text file and then showing it in the wiki. Sites are not going to update the Wikka release notes--it's static data. Why have it as a wiki page?
~~Why don't we focus our energy on making the ""{{wikkachanges}}"" action better? JavaWoman, you are detailing problems with my crappy action that I spent ten minutes on to demonstrate the concept. Wouldn't it be possible to tweak the action to output the text to your satisfaction?
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as ReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating?
~~I don't like the idea of us forcing pages on people. If we make the release notes as an action, people can have the release notes show on any page they want. They could create a page named WikiEngineChanges and place the ""{{wikkachanges}}"" action on it, and when they upgrade, the changes will show up on the page that **they** decided. If we force a page named ReleaseNotes, we are going to create an unnecessary struggle with site owners that might not want to have the Wikka release notes on a page named ReleaseNotes. -- JsnX

Revision [3061]

Edited on 2004-12-09 23:51:32 by JsnX [Explaining why ReleaseNotes is a bad idea]
Additions:
~~Have both of you thought how this would be implemented?? It's easy to include a default page on install. However, what are we going to do on upgrade? Are we going to overwrite the page? What if the site has changed the page? I think it would be annoying for the upgrade script to overwrite an existing page. Hence the solution that I have proposed. In addition, how long is it going to be before someone says, "Hey, why don't we include a text file that lists the changes". Once again, we take care of this by including the text file and then showing it in the wiki. Sites are not going to update the Wikka release notes--it's static data. Why have it as a wiki page?
~~Why don't we focus our energy on making the ""{{wikkachanges}}"" action better? JavaWoman, you are detailing problems with my crappy action that I spent ten minutes on to demonstrate the concept. Wouldn't it be possible to tweak the action to output the text to your satisfaction?
~~I'm proposing that we name the page WikkaReleaseNotes for a reason. Let's imagine that Linus decides he wants to create a Wikka site name LinuxWiki to document his Linux kernel. If we name a default page as ReleaseNotes, won't this confuse people on the LinuxWiki site when they are looking for the release notes for Linux? What will Linus name the page that describes the release notes for his software? You might say, he could just overwrite the Wikka release notes with whatever he wants. But then what happens when he upgrades to a new Wikka version? Do you see the problem that we are creating?
~~I don't like the idea of us forcing pages on people. If we make the release notes as an action, people can have the release notes show on any page they want. They could create a page named WikiEngineChanges and place the ""{{wikkachanges}}"" action on it, and when they upgrade, the changes will show up on the page that **they** decided. If we force a page named ReleaseNotes, we are going to create an unnecessary struggle with site owners that might not want to have the Wikka release notes on a page named ReleaseNotes. -- JsnX

Revision [3054]

Edited on 2004-12-09 21:44:58 by GmBowen [comment on JW irony comment]
Additions:
~~~''Liberia???? Japan I get (beaten in war). OAS I get (sucking up to U.S. ;) ). LIBERIA??? Liberia I don't get. BTW, I didn't mean that spelling was ironic, I meant that the decision was, given efforts by various members on this wiki to "internationalize" the wiki. (Or, I could rename the file. Writing an action to include an action is a programmer's solution obviously. LOL ;-} ) -- Mike''

Revision [3050]

Edited on 2004-12-09 21:07:55 by JavaWoman [comment on spelling irony]
Additions:
~~~''spelling **is** [[http://en.wikipedia.org/wiki/American_and_British_English_differences ironic]] - you can always add a colour action yourself containing nothing but an include of ##actions/color.php##, if you must. :) --JavaWoman''

Revision [3048]

Edited on 2004-12-09 20:42:51 by GmBowen [minor comment on irony]
Additions:
~~Dropped. ''Geez, in the whole wide world it's only the Americans who spell it without the "u"....so we keep the U.S. spelling? Ironic.''
Deletions:
~~Dropped.

Revision [3044]

Edited on 2004-12-09 19:44:04 by JavaWoman [comment on including docs]
Additions:
~~''Agreed. --JavaWoman''

Revision [3043]

Edited on 2004-12-09 19:42:09 by JavaWoman [minor edit]
Additions:
~~''I saw it in the SandBox and it messed up things royally there... disabled it, and added notes about my findings.---I agree with Dartar, I'd like to see ReleaseNotes included as a default page; if one doesn't look at it, fine, but at least it's there if you do need to consult what was changed (and why) and it's much more readable than what ""{{wikkachanges}}"" produces. I'd vote for just removing the ""{{wikkachanges}}"" action and simply including a ReleaseNotes page. --JavaWoman''
Deletions:
~~''I saw it in the SandBox and it messed up things royally there... disabled it, and added notes about my findings.---I agree with Dartar, I'd like to see ReleaseNotes included as a default page; if one doesn't look at it, fine, but at least it's there and it's much more readable than what ""{{wikkachanges}}"" produces is you do need to consult what was changed, and why. I'd vote for just removing the ""{{wikkachanges}}"" action and simply including a ReleaseNotes page. --JavaWoman''

Revision [3042]

Edited on 2004-12-09 19:39:04 by JavaWoman [fixing layout (list bug again?)]

No Differences

Revision [3041]

Edited on 2004-12-09 19:37:58 by JavaWoman [note about wikkachanges action]
Additions:
~~- We can still have a page named WikkaReleaseNotes, but we bring back what Wakka used to do. Create an action named wikkachanges. This action will display a file in the docs directory named CHANGES.txt. We then put the action in the WikkaReleaseNotes page. This way we cover two areas: admins who have just downloaded the distribution file, and online users who want to see the changes. The wikkachanges action is live on this site right now. Try it.
~~''I saw it in the SandBox and it messed up things royally there... disabled it, and added notes about my findings.---I agree with Dartar, I'd like to see ReleaseNotes included as a default page; if one doesn't look at it, fine, but at least it's there and it's much more readable than what ""{{wikkachanges}}"" produces is you do need to consult what was changed, and why. I'd vote for just removing the ""{{wikkachanges}}"" action and simply including a ReleaseNotes page. --JavaWoman''
Deletions:
~~- We can still have a page named WikkaReleaseNotes, but we bring back what Wakka used to do. Create an action named wikkachanges. This action will display a file in the docs directory named CHANGES.txt. We then put the action in the WikkaReleaseNotes page. This way we cover two areas: admins who have just downloaded the distribution file, and online users who want to see the changes. The wikkachanges action is live on this site right now. Try it.

Revision [3035]

Edited on 2004-12-09 18:26:05 by NilsLindenberg [small note]
Additions:
~~''I'm in Rom till sunday so don't expect big changes before monday. Nils''

Revision [3011]

Edited on 2004-12-09 13:23:10 by JsnX [Reply to JamesMcl]
Additions:
- James, please keep asking questions. I wasn't trying to scare you off. In this case, though, it appears that something is amiss with mod_rewrite on your webhost. -- JsnX

Revision [2998]

Edited on 2004-12-09 07:37:49 by JamesMcl [Reply to JamesMcl]
Additions:
- Jason, I know the information that DarTar gave was correct and I have read ModRewrite but when I tried his settings, I got an error message, hence the reason for contacting my isp's help desk. The error can't find the correct path to wikka.php. I have reset the config file to RR Off and everything works fine. DarTar and JsnX, please accept my apology for wasting your time. --JamesMcl

Revision [2993]

Edited on 2004-12-09 03:57:35 by JsnX [non-comprehensive reply to DarTar]
Additions:
~~-I'd wager that the average Wikka owner does not care as much as you and I do about the release notes. Have you noticed that the majority of Wikka sites that have been around for a while have never upgraded? Anyhow, how about an alternative:
~~- We can still have a page named WikkaReleaseNotes, but we bring back what Wakka used to do. Create an action named wikkachanges. This action will display a file in the docs directory named CHANGES.txt. We then put the action in the WikkaReleaseNotes page. This way we cover two areas: admins who have just downloaded the distribution file, and online users who want to see the changes. The wikkachanges action is live on this site right now. Try it.
~~OK.
~~Dropped.
~~-Sure.
~-**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()""##:
~~-Done.
Deletions:
~-**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()""##:

Revision [2992]

Edited on 2004-12-09 00:14:24 by JsnX [reply to JamesMcl about mod_rewrite]
Additions:
DarTar kind of gave you the key....
Forget about the wrong information that your ISP gave you and read ModRewrite. -- JsnX

Revision [2985]

Edited on 2004-12-08 21:54:18 by JamesMcl [Reply to DarTar]
Additions:

- I contacted my isp and they advised me to use
- %%/home/www/user/wikka/%%
- Didn't work though --JamesMcl

Revision [2957]

Edited on 2004-12-08 13:40:31 by DarTar [Reply to JMCL]
Additions:
- ''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

Revision [2956]

Edited on 2004-12-08 12:10:02 by JamesMcl [Reply to DarTar]
Additions:
- 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
Deletions:
- 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

Revision [2955]

Edited on 2004-12-08 11:55:47 by JamesMcl [Reply to DarTar]
Additions:
- 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
- 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
Deletions:
- Couldn't the wikka imnstallation 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

Revision [2953]

Edited on 2004-12-08 10:46:45 by DarTar [Things to be fixed before releasing 1.1.6.0]
Additions:
==Things 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**
%%(php)
$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>';
%%
**modified**
%%(php)
$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();
%%
**original**
%%(php)
if ($_GET["mail"]=="result") {
%%
**modified**
%%(php)
if ($_POST["mail"]=="result") {
%%
-- DarTar, 08 Dec 04

Revision [2950]

Edited on 2004-12-08 08:52:42 by DarTar [Reply to JMCL]
Additions:
- ''The .htaccess file //is// created during the installation, are you experiencing any problem with rewrite rules?'' --DarTar

Revision [2949]

Edited on 2004-12-08 07:34:58 by JamesMcl [Explanation of ModRewrite request]
Additions:
- Jason, as I understand it, we have to add a .htaccess file with the code shown in the ModRewrite page.
- Couldn't the wikka imnstallation 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

Revision [2929]

Edited on 2004-12-07 18:11:46 by NilsLindenberg [added link to HandlingWikkaConfig]
Additions:
- See my questions at HandlingWikkaConfig. NilsLindenberg
Deletions:
- ''I find the way the include of the config is handeld very confusing. But that could be a case of my limited php-skills. I write more when I had time to look over it again.'' Nils
- Just my two euro-cents :-) NilsLindenberg

Revision [2925]

Edited on 2004-12-07 17:14:25 by JsnX [JamesMcl, ModRewrite?]
Additions:
- ''Please be more specific. Wikka already works with or without ModRewrite.'' -- JsnX

Revision [2903]

Edited on 2004-12-07 07:54:01 by JamesMcl [Request for mod rewrite in next minor release]
Additions:
- please add ModRewrite in code as a default. --JamesMcl

Revision [2792]

Edited on 2004-12-03 08:10:26 by JamesMcl [Save pages in pdf format]
Additions:
==Save Pages to PDF Format==
Page output to an Adobe pdf file using FPDF.
E-mail this page facility
--JamesMcl

Revision [2783]

Edited on 2004-12-02 20:21:04 by GmBowen ["search comments" a "lost" feature....and a solution]
Additions:
~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
Deletions:
~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...probably actually better to make it so that there's two parts to the search results page....one for Pages and one for Comments...I'll muck with that idea] 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

Revision [2779]

Edited on 2004-12-02 19:13:19 by GmBowen ["search comments" a "lost" feature....and a solution]
Additions:
~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...probably actually better to make it so that there's two parts to the search results page....one for Pages and one for Comments...I'll muck with that idea] 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
Deletions:
~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.] 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

Revision [2774]

Edited on 2004-12-02 17:54:15 by GmBowen ["search comments" a "lost" feature...]
Additions:
~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.] 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
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? --NilsLindenberg
Deletions:
~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"". 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
It would be good iff 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? --NilsLindenberg

Revision [2771]

Edited on 2004-12-02 16:11:41 by NilsLindenberg [order of text-search]
Additions:
==Order of the text-search==
It would be good iff 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? --NilsLindenberg

Revision [2770]

Edited on 2004-12-02 15:59:58 by NilsLindenberg [header + minor layout changes]
Additions:
===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 2004
[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....
[for the next major release]
- skins (with new [[WikkaSkinOptimization css template]]);
- [[HelpInfo documentation]] shipped with the installation (or maybe [[IncludeRemote not]]);
DarTar
- ''I find the way the include of the config is handeld very confusing. But that could be a case of my limited php-skills. I write more when I had time to look over it again.'' Nils
===Ideas===
==Usergroups==
Yet another idea from me:
~Usergroups. So i can create a group of users, and just write that group into the ACLs...
~GregorLindner
- 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"". 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
''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)<?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;
}
?>%%
~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
Deletions:
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 :)
- 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....
[for the next major release]
- skins (with new [[WikkaSkinOptimization css template]]);
- [[HelpInfo documentation]] shipped with the installation (or maybe [[IncludeRemote not]]);
DarTar

- ''I find the way the include of the config is handeld very confusing. But that could be a case of my limited php-skills. I write more when I had time to look over it again.'' Nils
==Ideas:==

- Yet another idea from me:
~Usergroups. So i can create a group of users, and just write that group into the ACLs...
~GregorLindner
- Take a look at GroupManagement (which doesn't seem to be finished)


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


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


''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)<?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;
?>%%
~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


Revision [2769]

Edited on 2004-12-02 15:55:20 by GmBowen [header + minor layout changes]
Additions:
~~''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"". 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''
Deletions:
''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. A separate action to list all comments by a user would also be useful. -- GmBowen''

Revision [2768]

Edited on 2004-12-02 15:52:57 by GmBowen [header + minor layout changes]
Additions:
''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. A separate action to list all comments by a user would also be useful. -- GmBowen''

Revision [2645]

Edited on 2004-11-30 00:01:35 by JsnX [moved "usernames checked against page names" code]
Additions:
===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)<?php
~For **##actions/usersettings.php##** - insert after line 151:%%(php)<?php
~ and change **##if##** on the next line to **##elseif##**. That should do it, I think. -- JavaWoman
Deletions:
- 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
~~For **##actions/usersettings.php##** - insert after line 151:%%(php)<?php
~~ 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

Revision [2610]

Edited on 2004-11-29 11:55:33 by NilsLindenberg [a little bit of layout]
Additions:
==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''
----
CategoryDevelopment
Deletions:
==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''
----
CategoryDevelopment

Revision [2609]

Edited on 2004-11-29 11:54:38 by NilsLindenberg [reply to jason and gregor, one deletion]
Additions:
- 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.
- ''I find the way the include of the config is handeld very confusing. But that could be a case of my limited php-skills. I write more when I had time to look over it again.'' Nils
- by the way, what about a highlighter-format? .highlight isn't used :-)
==Ideas:==
- Take a look at GroupManagement (which doesn't seem to be finished)
Deletions:
- 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:==
- ++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

Revision [2600]

Edited on 2004-11-28 23:29:45 by JsnX [small cleanup]
Additions:
- Just my two euro-cents :-) NilsLindenberg
Deletions:
- for privacy reasons, i would like to see an addition about wikiping on RecentChanges (see SuggestionBox)
- Just my two euro-cents :-) NilsLindenberg

Revision [2597]

Edited on 2004-11-28 22:53:59 by JsnX [small cleanup]
Deletions:
- 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

Revision [2593]

Edited on 2004-11-28 22:21:40 by JsnX [small cleanup]
Deletions:
- 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 wakkawiki.com? OK, I'll see if I can change these. :) -- JsnX

Revision [2582]

Edited on 2004-11-28 17:40:58 by JavaWoman [about referring to line numbers]
Additions:
~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

Revision [2575]

Edited on 2004-11-28 14:58:05 by JsnX [small clean up]
Deletions:
- small bug: when editing a page, if you use in the comment characters like the ampersand or quotation marks, preview the page and then reedit the page, the comment field will contain litteral htmlentities such as ##"e;## which will be stored as such;
- I just noticed this yesterday. I'll check into it. Thanks for all the ideas.

Revision [2551]

Edited on 2004-11-27 17:26:00 by JsnX [Removed "Underline in headers"]
Deletions:
- 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''

Revision [2546]

Edited on 2004-11-27 17:08:17 by JsnX [cleaning up a bit]
Deletions:
- bugfix preventing creation of pages with invalid names (well done, but see my [[WikkaBugs note]]);
- OK. But do we know what a valid page name is? ;)
- if people find it useful, include the ##[[LastEdit lastedit.php]]## miniaction (I've moved the style attributes to a dedicated ##.lastedit## class in wikka.css);
- OK. I see no harm with including it in the release.
- 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;
- OK.

Revision [2538]

Edited on 2004-11-27 14:26:42 by DarTar [Adding my wishlist]
Additions:
DarTar
Deletions:
--DarTar

Revision [2524]

Edited on 2004-11-27 13:22:34 by DarTar [Adding my wishlist]
Additions:
- if people find it useful, include the ##[[LastEdit lastedit.php]]## miniaction (I've moved the style attributes to a dedicated ##.lastedit## class in wikka.css);
- [[HelpInfo documentation]] shipped with the installation (or maybe [[IncludeRemote not]]);
Deletions:
- if people find it useful, include the ##lastedit.php## miniaction (I've moved the style attributes to a dedicated ##.lastedit## class in wikka.css);
- [[HelpInfo documentation]] shipped with the installation;

Revision [2523]

Edited on 2004-11-27 13:21:13 by JsnX [acknowledging DarTar's suggestions]
Additions:
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 :)
- 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
- bugfix preventing creation of pages with invalid names (well done, but see my [[WikkaBugs note]]);
- OK. But do we know what a valid page name is? ;)
- 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....
- if people find it useful, include the ##lastedit.php## miniaction (I've moved the style attributes to a dedicated ##.lastedit## class in wikka.css);
- OK. I see no harm with including it in the release.
- 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;
- OK.
- small bug: when editing a page, if you use in the comment characters like the ampersand or quotation marks, preview the page and then reedit the page, the comment field will contain litteral htmlentities such as ##"e;## which will be stored as such;
- I just noticed this yesterday. I'll check into it. Thanks for all the ideas.
[for the next major release]
- skins (with new [[WikkaSkinOptimization css template]]);
- [[HelpInfo documentation]] shipped with the installation;
--DarTar

- 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 wakkawiki.com? 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



==Ideas:==
- ++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
~GregorLindner

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

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


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

----
CategoryDevelopment
Deletions:
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;
- small bug: when editing a page, if you use in the comment characters like the ampersand or quotation marks, preview the page and then reedit the page, the comment field will contain litteral htmlentities such as ##"e;## which will be stored as such;
[for the next major release]
- skins (with new [[WikkaSkinOptimization css template]]);
- [[HelpInfo documentation]] shipped with the installation;
--DarTar
- 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 wakkawiki.com? 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
==Ideas:==
- ++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
~GregorLindner
- Yet another idea from me:
~Usergroups. So i can create a group of users, and just write that group into the ACLs...
~GregorLindner
- 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 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)<?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.
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)
- 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''
----
CategoryDevelopment

Revision [2517]

Edited on 2004-11-27 12:20:14 by DarTar [Adding my wishlist]
Additions:
- small bug: when editing a page, if you use in the comment characters like the ampersand or quotation marks, preview the page and then reedit the page, the comment field will contain litteral htmlentities such as ##"e;## which will be stored as such;

Revision [2514]

Edited on 2004-11-27 12:02:09 by DarTar [Adding my wishlist]
Additions:
===== Wikka Development =====
{{lastedit}}
[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;
--DarTar

Revision [2511]

Edited on 2004-11-27 06:52:48 by JavaWoman [reply to JsnX]
Additions:
~~~''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''

Revision [2510]

Edited on 2004-11-26 23:50:42 by JsnX [Back to NilsLindenberg]
Additions:
- You mean the links to wakkawiki.com? OK, I'll see if I can change these. :) -- JsnX
- 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.
- 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 haven't tested this yet either. I'll check it out, but I'm not sure if it will make this upcoming release. -- JsnX

Revision [2502]

Edited on 2004-11-26 18:26:25 by NilsLindenberg [one last thing]
Additions:
- for privacy reasons, i would like to see an addition about wikiping on RecentChanges (see SuggestionBox)

Revision [2500]

Edited on 2004-11-26 18:23:40 by NilsLindenberg [reply to Jason]
Additions:
- if the sourceforge-files are at date, you could think about changing the link at the end of setup.php :-)
- 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.
- if someone finds the failure quick; //Underline in headers// would also be nice (WikkaBugs, Category Users as an example)
- I have no chance of testing it, so if anyone could tell me, if //Strikethrough rendering// works (see WikkaCSS) - just curios
- by the way, what about a highlighter-format? .highlight isn't used :-)
- Just my two euro-cents :-) NilsLindenberg

Revision [2495]

Edited on 2004-11-26 15:39:59 by JsnX [upcoming release requests]
Additions:
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

Revision [2492]

Edited on 2004-11-26 15:19:08 by GmBowen [upcoming release requests]
Additions:
''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)

Revision [2420]

Edited on 2004-11-24 14:54:19 by GregorLindner [Usergroups for ACLs]

No Differences

Revision [2419]

Edited on 2004-11-24 14:53:43 by GregorLindner [Usergroups for ACLs ?]
Additions:
- ++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...
Deletions:
- 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.

Revision [2406]

Edited on 2004-11-24 09:58:29 by GregorLindner [Information Page when read access denied ?]
Additions:
- 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.
Deletions:
- 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.

Revision [2405]

Edited on 2004-11-24 09:57:41 by GregorLindner [Information Page when read access denied ?]
Additions:
- 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.
~GregorLindner

Revision [1929]

Edited on 2004-10-19 14:26:00 by GmBowen [Information Page when read access denied ?]
Additions:
~~(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)
Deletions:
~~(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)

Revision [1816]

Edited on 2004-10-11 23:15:25 by GmBowen [Information Page when read access denied ?]
Additions:
~~(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)

Revision [1810]

Edited on 2004-10-11 19:54:42 by JavaWoman [page exists check for new username (and more)]
Additions:
~~For **##wikka.php##**:%%(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;
}
?>%%
~~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

Revision [1801]

Edited on 2004-10-11 18:27:37 by JavaWoman [more comments]
Additions:
~~''LOL! Nice variant of my favorite "running off to catch the train" scenario; you got your point across nicely though ;-) --JW''
~~''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''
~~''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''

Revision [1800]

Edited on 2004-10-11 18:10:42 by DarTar [Added reaction]
Additions:
~~''I agree, it's an important issue (some Wakka forks have already addressed the problem of concurrent editing) -- DarTar''
~~''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''
~~''I totally agree with JW's point -- DarTar''

Revision [1797]

Edited on 2004-10-11 17:53:31 by GmBowen [Added reaction]

No Differences

Revision [1796]

Edited on 2004-10-11 17:53:17 by GmBowen [Added reaction]
Additions:
~~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

Revision [1795]

Edited on 2004-10-11 17:48:21 by GmBowen [Added reaction]
Additions:
~~''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''
Deletions:
~~''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. -- GmBowen''

Revision [1794]

Edited on 2004-10-11 17:47:57 by GmBowen [note on where "homepage" user came from]
Additions:
~~''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. -- GmBowen''
Deletions:
~~''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. -- MikeB''

Revision [1793]

Edited on 2004-10-11 17:47:31 by GmBowen [note on where "homepage" user came from]
Additions:
~~''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. -- MikeB''

Revision [1791]

Edited on 2004-10-11 15:59:45 by JsnX [replying to JavaWoman's comments]
Additions:
==Ideas:==
- 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:
~~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
~~Agreed. -- JsnX
==Low priority:==
~~OK. Point taken. I was considering doing some form of filtering, but will now only consider higlighting, as requested. -- JsnX
Deletions:
Ideas:
- 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.

Revision [1790]

Edited on 2004-10-11 15:26:43 by JavaWoman [comments ;-)]
Additions:
~~''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''
~~''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''
~~''**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''
- 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''
Deletions:
- Add the ability to 'search for all comments by user X'. How this might be useful: I want to find a comment by JavaWoman, but I can't remember which page it was on -- she's quite prolific! -- so I use this new function to list all of her comments.

Revision [1785]

Edited on 2004-10-11 13:47:29 by JsnX [ideas for future development]
Additions:
- Add the ability to 'search for all comments by user X'. How this might be useful: I want to find a comment by JavaWoman, but I can't remember which page it was on -- she's quite prolific! -- so I use this new function to list all of her comments.

Revision [1784]

Edited on 2004-10-11 13:15:25 by JsnX [ideas for future development]
Additions:
CategorySystemOverhaul


Ideas:
- New usernames should be checked against existing page names. This was prompted by a new user named 'HomePage'.
- 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.
- 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.



----
Deletions:
===Note on Missed Release Dates, July 2004:===

Specifying release dates started because of feedback that said, "give us an idea of when the next release will be." So I started giving "Target dates". The metaphor is that you don't always hit a bulls eye when shooting at a target. And target dates are sometimes missed.

I continue to specify dates so that people will know that Wikka development hasn't been abandoned. ... It's just been delayed due to real life priorities.

This has been a learning experience and underscores the need to open up the development process to others. Moving development to Sourceforge.net is appearing to be the main option.

Feedback is welcome.

- JsnX

take it easy! wikka is for free and absolutely worth that price. so if anyone has complaints, he or she may take action. to put the source to a repository is a good idea. to provide the old version again while a revision is pending, too.

you may take a couple of minutes and point out which development tasks need attention, because i have no idea about the actual state. i can't promise too much, because it can get tricky to work on two different versions (and i will push my own fork forward according to my needs), but if you need some help you first have to communicate the issues.

----

Jason, I definitely agree that moving Wikka development to a repository and trying to understand whether there are people willing to contribute code is going to be a necessary step to keep Wikka alive. There are many cases of other Wakka forks (like Wikini) that have been able to gather a large community of developers/contributors and keep adding new features/fixing bugs on a daily basis. To me, what is interesting in wiki development is the way in which forks evolve from projects that are not able to keep up with their "competitors". It is clearly a case of "survival of the fittest": the only way to discourage migration of ideas to other forks or more mature projects consists in aggregating people. Otherwise, a project is doomed to natural extinction.
Apologies for the rudeness of these thoughts, they are just supposed to tease (not to discourage) people who follow with interest the prospects of this great project ;-)

-- DarTar

----

Revision [829]

Edited on 2004-07-31 00:28:48 by DarTar [ideas for future development]
Additions:
Jason, I definitely agree that moving Wikka development to a repository and trying to understand whether there are people willing to contribute code is going to be a necessary step to keep Wikka alive. There are many cases of other Wakka forks (like Wikini) that have been able to gather a large community of developers/contributors and keep adding new features/fixing bugs on a daily basis. To me, what is interesting in wiki development is the way in which forks evolve from projects that are not able to keep up with their "competitors". It is clearly a case of "survival of the fittest": the only way to discourage migration of ideas to other forks or more mature projects consists in aggregating people. Otherwise, a project is doomed to natural extinction.
Apologies for the rudeness of these thoughts, they are just supposed to tease (not to discourage) people who follow with interest the prospects of this great project ;-)
-- DarTar

Revision [798]

Edited on 2004-07-29 13:29:06 by DreckFehler [moved portions to wikka-bugs]
Deletions:
===bug in redesigned acl-handling?===
btw: am i wrong or does the $wakka->hasaccess routine (v. 1.1.3) only check the user-rights against the //present// page, regardless if the parameter $tag is set or not? i haven't had a closer look, but as i understood, the check against $this->acls[$privilege."_acl"] only returns the right value, if $tag == $this->tag and else should be passed over to the loadacl-function as wakka did. -- DreckFehler

Revision [797]

Edited on 2004-07-29 13:27:22 by DreckFehler [bug in redesigned acl-handling?]
Additions:
take it easy! wikka is for free and absolutely worth that price. so if anyone has complaints, he or she may take action. to put the source to a repository is a good idea. to provide the old version again while a revision is pending, too.
you may take a couple of minutes and point out which development tasks need attention, because i have no idea about the actual state. i can't promise too much, because it can get tricky to work on two different versions (and i will push my own fork forward according to my needs), but if you need some help you first have to communicate the issues.
===bug in redesigned acl-handling?===
btw: am i wrong or does the $wakka->hasaccess routine (v. 1.1.3) only check the user-rights against the //present// page, regardless if the parameter $tag is set or not? i haven't had a closer look, but as i understood, the check against $this->acls[$privilege."_acl"] only returns the right value, if $tag == $this->tag and else should be passed over to the loadacl-function as wakka did. -- DreckFehler

Revision [779]

Edited on 2004-07-26 13:16:20 by JsnX [added link to CategoryDevelopment]
Additions:
----
CategoryDevelopment

Revision [778]

The oldest known version of this page was created on 2004-07-26 13:12:04 by JsnX [added link to CategoryDevelopment]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki