Comparing revisions for WikkaDevelopment
- [5587] 2005-02-04 15:16:08 by NilsLindenberg (unregistered user) [moved discussion to WikkaReleaseNotesDiscussion]
- [18457] 2008-01-28 00:11:41 by JavaWoman (unregistered user) [Modified links pointing to docs server]
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)
----
===In work===
~-We should update the infos on syntax highlighting in the default FormattingRules page (add wikkas build-in formatters again)
----
~-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.
----
===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 Woman]]"" (alpha: no-breaking space)---=> [[JavaWoman Java Woman]]
~~~1)""[[JavaWoman Ähnlich]]"" (alpha with uppercase)---=> [[JavaWoman Ähnlich]]
~~~1)no terminating ; before tag "<span style="color:blue;">blue</span>" (alpha: text, not link)---=> ""no terminating ; before tag "<span style="color:blue;">blue</span>"""
~~~1)""[[CategoryDevelopment test no terminating ; before end "]]"" (alpha)---=> [[CategoryDevelopment test no terminating ; before end "]]
~~~1)""[[FormattingRules <b>no ; before tag '</b>]]"" (numeric decimal)---=> [[FormattingRules <b>no ; before tag '</b>]]
~~~1)""[[SandBox missing ; before ϵ""---
~~~""|<- newline]]"" (numeric hex)---=> [[SandBox missing ; before ϵ
|<- 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).
handlers:
~- **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//==
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.---
~~''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
--JavaWoman
----
CategoryDevelopment
{{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)
----
===In work===
~-We should update the infos on syntax highlighting in the default FormattingRules page (add wikkas build-in formatters again)
----
~-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.
----
===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 Woman]]"" (alpha: no-breaking space)---=> [[JavaWoman Java Woman]]
~~~1)""[[JavaWoman Ähnlich]]"" (alpha with uppercase)---=> [[JavaWoman Ähnlich]]
~~~1)no terminating ; before tag "<span style="color:blue;">blue</span>" (alpha: text, not link)---=> ""no terminating ; before tag "<span style="color:blue;">blue</span>"""
~~~1)""[[CategoryDevelopment test no terminating ; before end "]]"" (alpha)---=> [[CategoryDevelopment test no terminating ; before end "]]
~~~1)""[[FormattingRules <b>no ; before tag '</b>]]"" (numeric decimal)---=> [[FormattingRules <b>no ; before tag '</b>]]
~~~1)""[[SandBox missing ; before ϵ""---
~~~""|<- newline]]"" (numeric hex)---=> [[SandBox missing ; before ϵ
|<- 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).
handlers:
~- **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//==
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.---
~~''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
--JavaWoman
----
CategoryDevelopment
Deletions:
{{lastedit show="3"}}
>>**See also**
- WikkaBetaFeatures of this wiki
- [[Docs:WikkaReleaseNotes Older Releases]]
- [[SuggestionBox Suggestions]]
- [[CodeContributions Contributions from users]]
>>
====The next release====
//the following things will be added/updated/fixed in the next release//
===Feature Additions===
===Bug fixes===
===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
----
CategoryDevelopmentDiscussion
