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

{syntax type="tiki" editor="plain"}
trying to preview a wiki-page with an name containing german umlauts (e. g. "Grafikdesign - Abschlüsse") leads to the following SQL-Error: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='

for (likely) the following query:

SELECT `page_id`, `pageName`, `hits`, `description`, `lastModif`, `comment`, `version`, `version_minor`, `user`, `ip`, `flag`, `points`, `votes`, `wiki_cache`, `cache_timestamp`, `pageRank`, `creator`, `page_size`, `lang`, `lockedby`, `is_html`, `created`, `wysiwyg`, `wiki_authors_style`, `comments_enabled` FROM `tiki_pages` WHERE `pageName`='Grafikdesign - Abschl�sse'

it seems that the request handling of the char-encoding for preview is not propper.

On wiki page I have this title:
~np~!{TR()}Summer Holiday camps{TR} 2021{CODE}~/np~

In my custom.php translation file for Hebrew I have:
"Summer Holiday camps" => "קייטנות קיץ",

When I look at the page in english all is fine:
{img fileId="1548" thumb="box"}

But in Hebrew, because numbers are seen as LTR, it misplace the anchor.
{img fileId="1546" thumb="box"}
{img fileId="1547" thumb="box"}

That’s was the kind of issue I was talking about during the TikiFest Virtual 2021. ;-)

I updated a previously working 16.x trunk instance.

With preview/save/cancel buttons at top and button.
After editing a page
*The bottom save button saves the edit, but returns you to the edit page again.
*The top button saves the edit and returns you to the normal page as it should.

However, all properties are lost when saved.
*cannot turn on or off comments for the page
*Previously stored tags and description are cleared.

When using the "Wiki Page Staging and Approval" feature... I would like the "Category for approved pages" option to include a new selection: "Prompt for category"

This would allow users to select a category when they approve the page, allowing approvers to select a different category for pages, rather then selecting a single, overall, "approved" category.

Sometimes, we end up with some strange characters in pages names (accents, punctuation, etc). While it generally works, people should keep URLs with simple characters (like in emails) for nice readable URLS.

For example:
((I know this is all wrong, but fear it might be right - Alain Désilets))

As noted above, quicklinks toolbar does not appear.
follows is convo with mlpvolt regarding issue and attempts to fix:

is this a new install (clean DB?)
> >>
> >> this sounds like a configuration issue - have you defined some
> >> categories (in the admin menu?)
> >> feel free to email me a screenshot.
> >>
> >> Mlpvolt

It is a new install...clean db..
> > I followed the instructions exactly as given for a windows desktop install.
> > Brand new Easy PHP, etc....
> > Yes, I have defined some categories....(8 hours of playing around)
> > Tried themes, changed title bars, etc..

Is there any loss of functionality?
> > can you categorize the page?
> > and this only appears when you edit, right?
> >
> > MLP

Everything else seems to work quite well.
> I can edit the page with code, but no quicklinks..so it's not as easy as it might be.
> and yes, only appears with the edit function.
> I have no idea what's going on and my efforts this morning have just produced more of the same.
> Love tikiwiki and would really like to get this resolved so we can get it up for our group.

OK try deactivating categories in admin>features and see what happens.
> Also try switching themes in admin general. (i don't recognize that theme)
> > MLP

That got rid of the error message and I can live with categories turned off.
Still no quicklinks on the edit page though..
Feels like progress...LOL oh...and I've tried just about every theme and it makes absolutely no difference.
Sid

-Montréal, le 24 août 2005- Lors d’un point de presse,
becomes:
-Montréal, le 24 août 2005- Lors d?un point de presse


There maybe other special characters with this problem...

In previous versions of tiki wiki, the alias of a page would show as the pagetitle for that page (assuming pref enabled to do so), but now the pagetitle is the pagename and not the page alias.

workaround below.

It would be nice when deleting (or renaming) a wiki page, if Tiki asked for a redirect (via the REDIRECT page). This would help visitors how have bookmarked the original page.

Use case:
#As admin, you select to DELETE (or RENAME) a wiki page.
#When Tiki prompts for confirmation, there could be a checkbox & text field asking for a redirect page.
+You should be able to enter ''either'' an existing wiki page or a fully qualified URL.
#If you select the checkbox (and enter a new page), Tiki does not ''delete'' the page. Instead Tiki edits the page to replace all existing content with a REDIRECT plugin.


There should be an option to have "301" headers so search engines know to update their DB.


There is a new page Alias feature in 3.0 Renamed pages could keep old URL as an alias. This could be done by appending an invisible page alias.

See attached images for UI example from MediaWiki

Related:
[wish1489|Wiki page name Alias]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

I removed a page at doc.tiki.org and checked the box to make a redirect to another page whose name consists of three words. I wrote the page name normally with spaces, with no characters to represent spaces. When the redirect was created, it concatenated the page name's three words into one, so a long string with no spaces. This breaks the redirect.

Please see
http://doc.tikiwiki.org/Lost+edit


{FLASH(movie=files/FeatureRequest_BetterHandlingOfBackButtonWhileEditing.swf,width=>811,height=>708,quality=>high)}{FLASH}

Reference Gallery is not working. When you try to add a reference of a page to the gallery, so that it could be used for other pages, you get a notice with "200 OK" error (not sure what it is meant)

Show instance: http://fvtorres-11800-5956.show.tikiwiki.org/
User: admin
Pass: 12345

Thanks

{syntax type="tiki" editor="plain"}
All wiki pages have the option to refresh them by clicking on their title. For a page e.g. ...&itemId=5, it does not work.

TW5.0Beta1

Steps to reproduce:

Use admin rights for the following steps

1. Create at least 2 categories
2. Give Registered (default no rights changed) User group access to one of them and deny access to the other
3. Now create 1 Wiki site in each Category
4. Link both pages from the tiki.index.php via Wiki link

5. Log in as the Registered user now
6. Try viewing both Sites via the Wiki link on one u get the error that u dont have permission to do so
7. Now click on the Link
Create this page (page will be orphaned)
8. Now u can view the page even though u arent allowed to do so
9. Uncheck the category change the site and u are even able to save the edits u did even though u dont have permission to do so

According the docs ([https://doc.tiki.org/Content-Templates#Use_it]) and past experience, there was an edit textarea on the content templates page (tiki-admin_content_templates.php) but, at tiki.org, the edit tab only allows editing of content template details, not the body of the template.

Maybe as a workaround, a wiki page can be specified for the template's content, but this is supposed to be just an alternative to composing on the content template admin page, not the only way to do it.

The "Allow HTML" button is a PITA.

because it is default unchecked EACH TIME you open the edit screen. therefore if anyone puts html in a page it is by default not parsed the next time somebody edits.

Using the tiki-mailin feature (for Wiki-Put or Article-Put), I consistently see right after the body tag, a PHP message showing me the array being populated. This happens whether or not there's an error in the posting itself.

Can someone explain why this is happening?

Source of example is attached. (@@@ indicates prvate information). Thanks.

Is it possible to give a checkbox or setting to turn this off?

Although I ''don't'' get reports about my own changes to wiki files, I ''do'' get reports about the attachments I myself make to wiki pages. I'd rather those not be sent out.

Since upgrading from LTS18.7 to 18.8, we are now unable to remove specific versions of a wiki page.
So whilst we can edit a page to hide profanity, obsenity and the like, we can not physically remove that version of the page.

This might also mean a site would be unable to fully comply with a "right to be forgotten" style request.

As an admin or suitably privildges user, go to page history, add tick in box for the version to be deleted. Then from the drop down menu at the foot of the page select Remove and click on the OK button.

The "Please confirm" pop up is shown and then click on Delete button.

The Error message "No version were selected. Please select one or more versions" is shown at the top of the History screen. The screen shows a selection tick against the version it's just failed to delete.

This bug seems closely related to at least two other recently filed bugs ....
[https://dev.tiki.org/item8065-Wiki-pages-cannot-be-deleted] and
[https://dev.tiki.org/item8128--No-users-were-selected-error]

When running "remove unused images" from wiki admin panel, it removes used images too. One problem is that the procedure means to saves only images referenced with "picture file=...". When user automatically uploads an image inside a wiki page, this image is referenced with "img source=..." inside the wiki page, thus it won't be saved when removing unused images, because it isn't considered as a used one. But the major problem is that all images are removed, even the ones reference with picture etc.!

{syntax type="tiki" editor="plain"}
Hi. When choosing "Remove" from the "More" dropdown list at the lower right of a page, you get a message "Please confirm. Delete the last version of the following Seite?". And there is a checkbox "Remove all versions".

That checkbox doesn't do anything. Always the latest version of the page is deleted, not all versions.

It had worked before (Tiki 24?).

Using 2.3, when some user renames a page that you were monitoring, you get an email message with a broken link to stop monitoring, because there is no hash at the url.

Example:
^
If you don't want to receive these notifications follow this link:
http://yourdomain/tiki-user_watches.php?hash=
^

{syntax type="tiki" editor="plain"}
Renaming or creation of pages with brackets in name not updating links when Wysiwyg.

Affects both ? and normal links.

Imagine you have 2 wiki pages. Page A and Page B, and Page B is assigned to category X.
In page A you use the CATEGORY plugin to list all objects from category X, and thus, it lists the "Page B" name, which links to it.

Then you rename Page B to Page C. In page A, the plugin category still shows name and link to "Page B", and not the updated name and link: "Page C".

This bug has been here for almost a year, and it is present in 1.9 and 1.10
---
bug still alive on tiki 2.1, and confirmed also after deleting pages, and clearing tiki caches.

It can be tested on (production) site for registered users at:
http://uniwiki.sima.ourproject.org

If a (UserPage) Page does not exist it is rendered as normal Text followed by "?" (red),
the problem occurs if a "." (dot) is in the link name

This:
*((UserPagmax.mustermann|Max Mustermann))

is rendered as:
Max Mustermann?.mustermann" class="wiki wikinew">?

Happens on BRANCH-1-9 when Use WikiWords is activated