Category: Wiki (page view, edit, history, rename, etc)

As of tiki 1.9.5, errors might occur when a link is inserted on the form ((ThisIsAPageWithoutDescription|This is the link text)). This resulted in some strange behaviour for me where the title on the link got turned into a link when tiki parsed it etc.

http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/lib/tikilib.php?r1=1.514.2.271&r2=1.514.2.272&pathrev=BRANCH-1-9 describes how the text to display is found.

tiki-listpages.php is showing page's entry twice

TestPage 0 13:24 admin 1
HomePage 0 13:24 admin 2
TestPage 0 13:24 admin 1
HomePage 0 13:24 admin 2

This is a small quirk/inconsistency when using "List pages". You can set the display rows parameter but if the user has access to some pages restricted because of categorisation the actual display row limit used is the number of pages in the system and not the number of pages available to the user.

This means that the listing can be spread over several pages with perhaps only 1 or 2 pages shown per page even if the display rows parameter is set to (say) 30.

It would be much better if this could always show 'up to' the limit set no matter if some pages are restricted.

People expect to find one here

Tiki website admins probably expect page hits to be recorded and shown on List Pages, but they aren't unless the Stats feature is activated. (It seems to me they used to be, long ago, but maybe memory is failing me ;-) .) If recording/displaying page hits can't be separated from the Stats feature, so it's on by default even if Stats isn't activated, then at least there should be a notice on List Pages like "To have page hits recorded and displayed here, activate the Stats feature."

{syntax type="tiki" editor="plain"}
The LISTPAGES plugin does not display the category or category path for a page, even if so configured.

See demo/test on http://demo.tiki.org/9x/tiki-index.php?page=test_list

It appears that the $listpages variable does not include any category information at all.

PASCAL

Also tested with Version and Category path and also does not display

{syntax type="tiki" editor="plain"}
Locking a wiki page causes the "Translate" link to not display. As a user (baijianpeng) pointed out, there's no connection between wanting|not wanting original page changes and translations of that page.

Unless I'm missing something, it seems the Translate link should display regardless of whether the page is locked or not.

The 'best language' logic only applies if no wiki page is specified, i.e. it only applies to the default wiki page.

Suppose that you select a translated version of a wiki page, and then follow a link to another wiki page, which has also been translated (into the same language).

As is stands, you will probably see the original language version of the second wiki page, and not the translated version. On the face of it, this is an error.

You could, of course, fix this behaviour, by modifying the link in the translated version of the first page, so that it referred directly to the translated version of the second page. In this case, you could argue that the current functionality is in fact correct.

I would disagree, because it makes the process of translating wiki pages too difficult. It would mean, that when you translate a single wiki page, you must locate all other wiki pages in that language, which link to the page, and update the links in those pages. Although the backlinks feature would help find the relevant pages, I don't think that you can reasonably expect a translator to perform this task.

We have a long table that presents fine on initial display, but when presented as (cached) the data is truncated. The footer appears mostly as normal except that it's evident that the table elements are arbitrarily cut off thereby affecting the subsequent footer.

Our table where the error is occurring is 680 lines long. The table will be truncated somewhere around line 390 or 540 but for a given edit instance it will always truncate at the same place.

We are seeing this behavior in 1.9.1 and 1.9.5. I don't believe this is a browser-related issue because we are seeing virtually the same results in IE and Firefox.

There is no visible limit about the length of the description field in Tiki for the user.
However this field is limited and if you go over the limit you will have a white page when saving your work potentially losing your last edit.

{CODE()}
[Mon Jun 14 09:11:25.437718 2021] [proxy_fcgi:error] [pid 46913:tid 140057356769024] [client 10.0.0.138:52983] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught TikiDb_Exception: Data too long for column 'description' at row 1 in /home/bernardsfez/public_html/lib/core/TikiDb/Exception.php:20\nStack trace:\n#0 /home/bernardsfez/public_html/lib/core/TikiDb.php(193): TikiDb_Exception::classify()\n#1 /home/bernardsfez/public_html/lib/core/TikiDb/Pdo.php(145): TikiDb->handleQueryError()\n#2 /home/bernardsfez/public_html/lib/core/TikiDb.php(101): TikiDb_Pdo->query()\n#3 /home/bernardsfez/public_html/lib/core/TikiDb/Table.php(130): TikiDb->queryException()\n#4 /home/bernardsfez/public_html/lib/core/TikiDb/Table.php(112): TikiDb_Table->updateMultiple()\n#5 /home/bernardsfez/public_html/lib/tikilib.php(5368): TikiDb_Table->update()\n#6 /home/bernardsfez/public_html/tiki-editpage.php(1227): TikiLib->update_page()\n#7 {main}\n thrown in /home/bernardsfez/public_html/lib/core/TikiDb/Exception.php on line 20', referer: https://bernardsfez.com/tiki-editpage.php?page=Comp%C3%A9tences+cl%C3%A9s+et+portefeuille+clients
{CODE}

It is an important bug (edit may be lost) on a popular feature (wiki page) and require an easy fix (real limit of text + small warning".
it should be fixed asap.

UPDATE:The value of the length accepted by the field in the database is 200 characters.
{img fileId="1608" thumb="box"}

It seemed to happen in 24.2 all of a sudden, so I upgraded to 25.0 to see if it would fix the issue but no, I can no longer attach an image to a wikipage using either the button at the bottom of the page or the button in the file galleries section. So I figure tiki is confused in a database setting.

All files are stored in a directory that has worked just fine previously

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

Mail notification not showing wiki page name and url.Problem in objectlib.php.

I upgraded from 1.8.5 to 1.9.0 and the configured mail notifications (for 'any wiki page changes', send mail to some list) don't work anymore.

No PHP errors are generated, and my php max_limit is 32MB.

We can already send in content to Tiki via email:

add/edit wiki
add articles
via tiki-admin_mailin.php

and add forum posts via
tiki-admin_forums.php


joe@joe.com sends an email. The system recognizes that joe@joe.com belongs to the user "joe" and adds the tracker/wiki edit/forum post/article as if the user joe had logged in and added it via the web form.


Make this optional for security reasons. If someone spoofs the email address, he could send in content for someone else.

{syntax type="tiki" editor="plain"}
This feature arrived in {mr id=5960} but wan't made optional sadly, i might get round to it one day, so this is just a reminder really

I often find a section of a wiki page near the bottom and want to edit just that section, and have to scroll all the way to the top to enable the icons, so either the icons should be always there but hidden (like the heading links), or we need a shortcut key to do that ("i" for icon, or "e"for edit... hmmm, simpler if they're always there)

The wiki parser inserts <br /> tags for each newline in the source text.
This produces a lot of vertical spacing in the rendered text, and is impossible to remove before, e.g. terms in definition lists, headings etc., whose wiki source text must start in the first column. Using the <br /> tag between paragraphs of text is also logically incorrect; <p>...</p> should be used for that.
Suggested solutions:
#Let 1 newline produce no HTML tags in output,
+Let 2 newlines produce a new paragraph (<p>) in output
+Devise new wiki syntax to let authors manually insert vertical spacing
#Let n newlines produce n-1 <br /> tags in output.
The latter solution seems simple, but does strictly speaking not produce the logically correct HTML output where paragraphs are delimited by <p>...</p> tags.
NOTE: This is ''not'' a CSS styling problem!

When including a maketoc into a page, the titles in the page are still parsed for WikiWords and Hotwords. This breaks HTML, links, and may decrease the readability of page TOC-s.

Everytime I use the maketoc inside a wiki page on a fresh tikiwiki 3.2 install the whole page content is duplicated every time I hit "save". Even if I delete all the content but one version and hit save the whole PREVIOUS page is duplicated again. Like I hit save: two times the page content. I delete all but one time the content, I hit save: three times the page content. I delete all but one time ... save ... four times the page content.
Only removing the maketoc makes it possible to get rid of the problem.
That was done with Opera browser on a page with 4 h1 headings but I doubt it is a browser problem. :)

This tracker item could not be found

On a wiki page, the "translate" and "manage translation" links under the little globe appear if 1. The person has permission to edit that page, but at the same time have no permissions to create new pages or edit other pages.

The links do not appear if the person does not have write access to the wiki page.


What should happen:

The "translate" and "manage translations" buttons should only appear if the user has permissions to create a translation, rather than edit the specific page they are on.

The issue I have come across is that the nav buttons are appearing when the page can not be edited, but the opposite problem is also likely (although I have not tested it) that a translation could be desired, on a page thats write permissions have been suspended.

This issue has also caused several translation & error pages to become crawled by bots and indexed in search engines. I will be proposing some new robots.txt rules to help prevent this in another ticket (to keep it all together with other suggestions)

Hope this is of interest for someone to tackle.

This tracker item could not be found

Hello!

I'm wondering to know if it is possible to put ((Markdown)) support on TikiWiki roadmap. As many of you know, Markdown is a syntax widely supported by many CMS, text editors, JS and PHP libraries and other Wiki services.

There are even some e-mail plugins, like ((https://markdown-here.com/|Markdown Here)), that allow users to write e-mails on Markdown language and the convert to HTML before sending emails.

Some ""competitors"" allow Markdown support as a plugin, like:

* WordPress - https://br.wordpress.org/plugins/wp-markdown/
* Joomla - https://extensions.joomla.org/extension/ace-x-markdown-editor/
* Drupal - https://www.drupal.org/project/markdown
* Plone - https://docs.plone.org/adapt-and-extend/config/markup.html
* Magento - https://github.com/SchumacherFM/Magento-Markdown
* Jekyll - https://jekyllrb.com/ (AFAIK, this one is used on Github pages)
* Octopress - http://octopress.org/ (I used this one for a long time)

Also, some other frameworks have extensions for markdown:

* Symphony - http://symphonyextensions.com/extensions/markdown/
* Django - https://github.com/agusmakmun/django-markdown-editor
* CodeIgniter - https://github.com/jonlabelle/ci-markdown
* Rails - https://github.com/vmg/redcarpet

So, as Markdown became familiar for a lot of non-technical users, I bet supporting Markdown is a good move for Tiki and also, it may turn easy migrating from other platform using Markdown to TikiWiki.

A user typo whilst creating a structure can create a new page which then isn't (easily) accessed.

Whilst creating a new structure and adding pages with aliases using the "Tree" feature, if hyphen space greater-than rather than simply hyphen greater-than is entered the new page is created without an alias but with a longer that expected page name.

For example
Test_01 -> Page1 creates new page called Test_01 and alias Page1 as expected.
But
Test_02 - > Page2 creates a new page called "Test_02 - > Page2" with no alias.

Accessing this page and removing it is challenging :-))

--(Can't currently create a show instance for you, no database connection available, but I can reproduce this on the demo 18x/system)--

Using the Structures "next page" button from page Test_01 causes a wiki error "Page not found" for "Test_02 - Page2" (sic without greater-than sign).

Likewise wikilink from toc generated on pages within the structure also results in "Page not found".

Adding the plugin listpages with options find="Test_0" to the root of the structure shows the pages as expected.

Note the wikilink URLs generated by toc and listpages are different, but wikilink from listpages also results in the same "Page not found error" for the same page "Test_02----Page2"