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

This was also reproduced on the http://demo.opensourcecms.com site.
When you select only two langages: english and french in the admin i18n section, on the line: Reg users can change language, you check the box named "Available languages" and you select english and french.

Then, when you go on a wiki page and click on the "translation" button, you see only english and french in the drop-down list. This is fine.
But when you edit a wiki page, the drop-down list of languages you can set for the page has all languages instean of only the expected two.

I am running tw 3.6 LTS in an enterprise environment (PHP 5.3.2, Windows 2003, Apache 2.2.13). We saw this same issue in 3.2 before our LTS upgrade.

We have tried to enable Rating (Polls) by following the instructions at [http://twbasics.keycontent.org/tiki-index.php?page_ref_id=366] and [http://doc.tikiwiki.org/Polls] (Poll templates). I have enabled the Rating, Categories, Poll options in Admin.

After adding the rating option to a wiki page, I save and revisit. I can see the Rating button in the top right corner of the page. When I select it, the button expands as expected into a pane with the options and a vote button, however the page also redirects to tiki-index.php# (my main page).

Why does the Rating button redirect instead of remaining on the page and allowing the user to vote?

It behaves the same in IE6 and FF3.6

---

Can you please retest in currently supported Tiki versions? (e.g. Tiki12, ...). Thanks in advanced! {sign user="xavi" datetime="2014-02-07T09:46:47+00:00"}

See yourself by creating a structure and making a page with {toc} in the source code. That creates a Table of Contents of the structure. This table of contents isn't considered by the Wiki 3D browser. So you are forced to enter links manually to be able to browse the structure with the Java Applet.

See screeshot

The functionality to allow comments in wiki pages on a 'per page' basis that was in Tiki 6 has been moved from Wiki admin to Comments admin and is therefore less visible

It should be replicated in Wiki admin as well to make it more visible


Fixed r48529

"The conversion seems to have dropped comments, on 1.8 the front page used to say it had 80+ comments, now on 1.9 it says 53."


I think no comments were dropped, it's the count which is different. Only first level comments are counted.

In 1.9.x, Side-by-side diff is the default

Sometime in the history of 1.10 (around when WYSIWYG editor arrived I think), HTML diff became the default.

This appears to be more of an accident than a conscience choice.

Side-by-side should re-become the default.

Ever better, the admin should should what the site default it.

Even better, each user could override this value in their preferences.

When I click "Dump" in the default menu (under "Wiki"), I get an unstyled Tiki page (no CSS is used) with an error message: "Page not found dump/new.tar". There's no sign of a wiki dump, needless to say. (This is on a wamp localhost; I didn't try on another server yet.)

In master, when editing a wiki page, clicking the edit help icon brings up the first modal as usual. But, switching to the plugin help tab and clicking on a plugin to insert, the modal for that doesn't display. The first modal just disappears and nothing takes its place.

This is using the standard wiki edit screen, and WYSIWYG and Markdown are not activated.

Update: This bug report was closed but, checking again in master and branch 26x (in a Windows 11 Laragon wamp stack), I'm finding that, again (or still), plugin UI modals don't open from the general wiki help modal. I tried in Firefox and Edge browsers. Clicking the PluginBox icon in the first modal's list of plugins doesn't open the second modal. Nothing happens.

With MediaWiki, before you save, you can review changes. It shows what you __will__ change (if you click save), in wiki diff format.

This is very nice.

Sometimes, we have done several edits, and we are not sure exactly what we changed (supposing we are multitasking or interrupted). It is nice to be able to review this and fill out the edit description accordingly

Useful for translation as well:
http://wiki-translation.com/tiki-view_tracker_item.php?itemId=51


Related:
*{wish id=2102}
*{wish id=1843}
*{wish id=1220}

In Opera (9.6), the wiki edit page only displays as far as the quicktags (these show), then the page display hangs and nothing else loads. This is with the normal editor.

The UI of the Wiki History needs some more love... See the screenshot:
{img fileId="1230" thumb="box"}

After ((rev:67935)):
{img fileId="1232" thumb="box"}

As of r68335:
# The language dropdown remains squeezed.
# When the Advanced/Simple button has focus, the text/background contrast is insufficient (in the theme on dev.tiki.org).
# --The "rows per page" text input field lacks Bootstrap classes it seems-- Should not be an issue as of r68348.

It is not possible to open several times the help modal {icon name="question-circle"} when editing content.
You need to use it once, save, reload the page and re-use it... and so on.

This is not way to edit content something that should be trivial for Tiki !

{syntax type="tiki" editor="plain"}
On a Tiki29 if one of these are enable
* Element Plus
* Element Plus Autocomplete
* Element Plus Select

When you edit a wiki page you can't select a wiki page using the toolbar button, add a wiki page.

It seems that happens when "Element Plus Select" is disable, NOT "Autocomplete".
The documentation or the tooltips about this should be clear and consistent.

When creating a link like this

((test - test))

to link to a page named 'test - test' then the created page is missing the hyphen. Additionally the pages is always shown as non-existent, meaning that the question mark behind the source link is always there, even if th e page was manually renamed. It is a real blocker.

There's a problem with wiki_watch_minor. It conflicts with notification
wiki_page_changes_incl_minor ("Any wiki page is changed, even minor
changes"). If wiki_watch_minor is disabled, a wiki_page_changes_incl_minor watch will not be triggered by a minor change.

The difference between minor and non-minor edits is done in
notificationemaillib->sendWikiEmailNotification(). This is where the
preference could be taken into account.

This is a regression from r10949. It was discussed on http://article.gmane.org/gmane.comp.cms.tiki.cvs/57346

Hello,

Recently upgraded to 3.0..

Thought I'd turn on the "Discuss pages on forums." option.. Created a forum for the purpose.. Went to the Wiki admin page and selected the option.. Picked the forum from the popup that appeared.. Pressed "Change preferences."..

No change.

Tried several times in different ways on different browsers.

No change.


How can I enable this option?



Thanks in advance,

Karl

{syntax type="tiki" editor="plain"}
When attaching a document to a wiki-page, for example an MS-Word file, this attachment seems not to be indexed. There's also no option to indicate which handlers for different mime-types to use. This option is available when using file-galery, but not for page attachments.
As a result the file will never show up in any search results.
Furthermore: it would be convenient to be able to indicate that the indexing of attachments should be logged. This would ease system debugging in the case mentioned.

If an upload fails here: tiki-list_file_gallery.php?galleryId=1, I get a descriptive error message (ex: file too big).

The same would be useful for wiki page attachments.

At : https://tiki.org/Roundtable-Meeting-2021-02 I can write a description but it won’t be saved.

I tested on OSX, WIN10 and different browsers and a different Tiki (all Tiki22): https://share.vidyard.com/watch/1xGgGNfUMUd6YtBF1DPFck?

In 1.9.9 and 1.9.10 (at least), if a description is added to a wiki page after the page is initially created, the description doesn't ever display on tiki-browse_categories.php. If an existing wiki page description is edited, the old version continues to be displayed on Browse Categories (or the new version may appear after some delay?). Based on IRC report from Random7 and confirmed at themes.tw.o. I didn't check behavior in 1.10 yet.

If you toggle right module to close it with the new centre switch and then try to use the functions on the dropdown edit menu the wikipage just scrools for a bit then stops but does not carry out any of the edit actions like "toggle edit icons".
I'm using firefox 108 on ubuntu 22

Gary I was able to use a different theme "Cyborg". To get different themes working in 25.x you have to associate the theme with a category or section of tiki.
I was able to see that the dropdown items menu with the edit wiki page toggle is under the table of contents of the wiki page so clicking on the area where the toggle edit icons is you are actually clicking on one of the TOC items.

Screen shot attached: https://dev.tiki.org/tiki-download_item_attachment.php?attId=827

https://tiki.org/tiki-pagehistory.php?page=1-click+installers&newver=185&oldver=184 reports Please log in Permission denied

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"

{syntax type="tiki" editor="plain"}
http://wikisuite.org/tiki-pagehistory.php?page=ClearOS&newver=0&oldver=30

See also attached image

It's a ((WYSIWYCA)) bug. Anonymous users can't remove page versions, so interface shouldn't offer it.

@fabio: please coach team as needed