Category: Usability

{syntax type="tiki" editor="plain"}
A wiki link in combination with a equation tag parses falsely.
This editor entry

{CODE()}((Fire weather index|{EQUATION()}FWI{EQUATION})){CODE}

displays the text output:

<img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle">§1a7e9ee2385aa1db7956a7f63689955f§

In HTML code:

<a class="wiki" title="Fire weather index" href="tiki-index.php?page=Fire+weather+index">&lt;img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle"&gt;§1a7e9ee2385aa1db7956a7f63689955f§</a>

The same in version 4.2 which is correct:

<a class="wiki " href="tiki-index.php?page=Fire+weather+index" title="Fire weather index"><img align="absmiddle" alt="FWI" src="lib/equation/pictures/04d4e88879dbf4f876f4b62fea56172f.png"></a>

{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.

{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.

!!Problems

__Pretty Much Resolved by the wiki ALIAS function__ - so closed.

Redirect plugin
*is not included by default in TikiWiki because it could be used for bad things
*creates redundancy (in search results, page listings, etc) - maybe redirected pages should not appear in list?

Renamed pages
*do not automatically redirect - creates broken links.


!!Proposed solution:

!!!renamed pages
*When a page is renamed the user must choose "hard or soft redirect" perhaps better known as "redirect or refer from old page?"
**hard redirect places redirect plugin on pagename-old to pagename-new.
**soft redirect puts something at top of page like
^This page has been renamed: pagename^


!!!Add synonyms/aliases to a page

suggestion (mlp): adding aliases to a page should automatically create pages with hard or soft redirects to pagename. Note that the adding of alias pages must not destroy data if page already exists.

Ex.:
dev.tikiwiki.org/Tracker
dev.tikiwiki.org/Trackers
dev.tikiwiki.org/Bug tracker

would be aliases. It would avoid the pollution we have here: http://dev.tikiwiki.org/tiki-orphan_pages.php


doc.tikiwiki.org/Install
doc.tikiwiki.org/Installation
doc.tikiwiki.org/Installer

Each wiki page should be able to put one or many aliases. These aliases would work in search. All the aliases should have an important weight in the internal search engine.

We could use this instead of renaming pages. Also, when we do rename a page, we could have an option to have the old page name to be an alias of the new one. Thus, better for external search engines.

Theses aliases could even be used as meta tag for this page.

Putting aliases to non wiki pages (ex.: tiki-forums.php) would make ((doc:structures)) more useful. Now, using structures for site navigation only makes sense if you only have wiki pages. And who ''only'' wants to have wiki pages with all the great features offered by TikiWiki? :-)

It also help to use cleaner page links in sentences. If my Wiki page is called Install, I have to do the following now:

{img src=images/code.png}%%% {CODE()}
For more information about ((Install|Installation))
{CODE}

With aliases, I could do:
{img src=images/code.png}%%% {CODE()}
For more information about ((Installation))
{CODE}

Page aliases - and hard redirects - should permit to set status "Moved Permanently" for robots to send traffic to main page.

What would we do with page renames? (which correct links in wiki pages). Needs some thought. We don't want some unwanted changing of text in existing wiki pages.


Do we need?
Redirect to internal or external http is ok because a special permission is needed to use. -> tiki_p_wiki_alias . In security admin, warm that giving tiki_p_wiki_alias to untrusted people is a security risk.


Related:
[wish1119|Better handling of page renaming]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

http://dev.tikiwiki.org/Add+to+WishList simulates the wiki page "add to WishList"


But
{CODE()}
((Add to WishList))
{CODE}

does not simulate
{CODE()}
((Add+to+WishList))
{CODE}

Should it?

Should plus(+) and space ( ) be freely interchangeable, the same was "A" and "a" are?

{syntax type="tiki" editor="plain"}
In edit mode, if I do

{CODE()}
((
{CODE}


(and maybe a few letters), an auto-complete should appear, like the quick_edit module. This list should be WYSIWYCA.


This would also be useful in some plugins, when a parameter is wiki=

The most important is ((doc:PluginInclude)), because the main goal of the plugin is to include other pages, which you may not know the exact name.

When in plugin edit mode, an auto-complete could be done with jQuery (ask LPH for details)

Related:
{wish id=480}

{syntax type="tiki" editor="plain"}
in older versions eg. 2.4, it was possible to use wiki page links with ampersands ( &) and also different color in the link text

for instance : "Look & feel" gave the link like <a href=./Look_and_feel> look & feel </a> does

or {CODE()}((Look_and_feel|~~#00F:Look and feel~~)){CODE} gave the link in blue color

Both works with external link syntax {CODE()}[./Look_and_feel|~~#00F:Look and feel~~]{CODE}

most probably it's the same error as describe in bug #3585


if it's helpful : I'm willed to give a bonus to the person who will fix the bug

It is rather difficult to write plugins that embed other plugins. The reason is the wiki syntax of the plugins not expressing if it is a beginning or an ending clause. The default is the "{X} body {X}" syntax.
Instead, {X} body {/X} should be used.
While this latter syntax as well as the {X /} are accepted by $tikilib->parse_data, it does not process the embedded calls. E.g {X} {X /} {/X} does not work. It returns an empty body instead of {X /} or the result of {X /}.

I tested the wikiplugin author on a fresh Tiki26: https://doc.tiki.org/PluginAuthor

When hovering the text inserted I can see a popup (not very nice) and the popup is unstable.
There are a few similar option in Tiki and using bootstrap.

Using this wikiplugin leaves the impression it has not been improved in time as it should have.

{FADE(label="Previous test on Tiki25")}I tested the wikiplugin author on a fresh Tiki25: https://doc.tiki.org/PluginAuthor

As it is visible on the doc page too, the plugin should display a popup and it is not working.

About the fields, Make Visible is a bit unclear and not documented.
What would be the point to add a plugin and hide it... May be it will be clearer when the plugin work again.{FADE}

Open Wiki Page, Click on the 'print' button to open the 'print view'.
Top of page is a Title link to the home page of the tikiwiki,
Below that is 'Home'. This should be the name of the wiki page, and/or the description of the page.

wiki shows no preview in translate edit mode while in normal wiki page edit it's working fine

version: 3.0beta4 SVN
theme: darkroom
browser: FF3

steps to reproduce:
# enable multilingual features
# select translate from dropdown where "English" is
# set the language and pagename for new page serving as translation
# in the editing mode click preview

# enable Slideshows feature on Wiki Admin panel
# log out
# click on the Slides button under HomePage content; tiki-slideshow.php?page=HomePage&slide=1 displays fragments of plugins as ~np~{DIV}~/np~, ~np~{ELSE}~/np~ and ~np~{GROUP}~/np~ (in other words it doesn't parse the plugins properly)

Creating a new page (e.g. -+Foo+- through the form in the wiki structure top bar produces a missleading error message:
{CODE()}
Error. TikiLib::create_page: Cannot create page "Foo", it already exists.)
{CODE}

In addition, another remarksbox is shown below saying:
{CODE()}
Success
Page Foo saved (version 1).
{CODE}

However, the page is created indeed, and within the structure also.

You can reproduce it here:
http://xavi-9794-7136.show2.tikiwiki.org/tiki-index.php?page=D1+Cover
u: admin
p: 12345

Create a page called foobar (or any other name for a new page inside the structure) and you will see the issue reproduced.
{img fileId="1314" thumb="box"}

Wiki syntax is not enabled in Tracker comments on this site. May be usability bug in later Tiki versions.

In the Quicklinks, there are two table links (one for the old wiki-table syntax, and one for the new).

On the Wiki table syntax in effect (from tiki-admin.php?page=wiki) should appear.

In templates/tiki-edit_help.tpl, this is already done with:

{if $feature_wiki_tables eq 'new'}

---
On second thought, since the new table syntax is so much better, and it's now the default on new installs. All references to old syntax should be phased out. People should only use it if they have large amounts of legacy data that they don't want to take the time to convert.

After upgraded to 14.1, Wiki template page can not be applied as an input form in the PluginTracker. The error message shows "Missing template Name". But the same template while using in Plugin Trackerlist can display items and work fine. Does anyone have same problem? Or what setting I missed?
*My Plugin Tracker Setting
{img fileId="1007" thumb="y" rel="box[g]"}
*Tracker setting
{img fileId="1009" thumb="y" rel="box[g]"}
*Error while wiki template page used in PluginTracker as an input form: ~~#F06:Missed Template File~~
{img fileId="1008" thumb="y" rel="box[g]"}
*Work properly in PluginTrackerlist to display items.
{img fileId="1010" thumb="y" rel="box[g]"}

In Tiki 3.1, the wiki syntax for text color breaks when there are two colors on one line. See http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=&comments_parentId=33947 for the forum post reporting this, and examples of the problem.

(Edited to check "watch" feature.)

{syntax type="tiki" editor="plain"}
__Tiki:__ 6.1
__Firefox:__

Wiki text returned by the SQL plugin is not translated. I used the "Quote" plugin to verify if this problem exists for all plugins returning Wiki text and the value translated as specified in the data passed.

We make fairly extensive use of the SQL plugin on our internal department site. A technique for implementing this plugin we use is to enclose the return value of a column in double parenthesis. This enables us to have a web page reference for each of the returned rows.

This technique is used in several circumstances. One is that we select from our database stored information on hundreds of servers making the server name a link to a detailed info page. The example below is used to link to project detail pages describing individual active projects.

{CODE(caption="Example SQL",wrap="0")}
select
concat( '((', p.project_name, '))' ) as "Project Name",
u.user_username as "Project Owner",
tdv.value as "Project Status"
from
projects p,
departments d,
project_departments pd,
tsi_dp_valsets tdv,
users u
where p.project_id = pd.project_id
and pd.department_id = d.dept_id
and d.dept_name = 'TSI-KPHC'
and u.user_id = p.project_owner
and tdv.ID = p.project_status
and tdv.value != 'Archived'
and tdv.value != 'Complete'
order by tdv.value;
{CODE}

This issue is not restricted to link specifications as bold (double underscores) no longer work when returned by SQL either.

I have rated this a "9" strictly from a personal importance perspective and not as a definition of impact to the overall Tiki project. The customers of our department rely on these returned links for information and updates.

I have been all through the Administrative areas hoping to find a feature flag to turn on wiki text parsing of plugins (before trying the above referenced "Quote test") and am also unable to find such a flag specific to the SQL plugin.

--Steve

Concerncs the current SVN version of tiki.
If you create a link to another wiki page via ((OtherPage)) it will be linked to tiki-editpage.php?page=OtherPage, whereas it should be tiki-index.php?page=OtherPage

__problem __with Russian (and, as I understood, any non-English character language) wiki-links in CKE Editor (and plugins):
1. Let's create wiki page named "Фичи" (copy-paste, hope it'll be work)
2. Create page with any name e.g. test with wiki-link to a first page ("Фичи").
3. Link is broken. becouse on the stage of convertation from wiki-link to CKE URL something goes wrong and if You click on this link and choose "Edit Link" you'll see "tiki-index.php?page=Фичи"
3.1 Yes, link is broken:
Page not found
äøÃÂø
----
Hint: without WYSIWYG editor all will be ok. No broken links with any symbols.

__Why priority is high?__
-becouse we can't create ANY wiki-links from CKE-editor if wiki page named with non-Latin leters.

p.s.
double-checked here http://php.opensourcecms.com/scripts/details.php?scriptid=63
with WYSIWYG_6x profile.

tags: utf-8, russian, link, wiki

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

{syntax type="tiki" editor="plain"}
In case we have "Wiki page edit buttons location" set (Preference name: wiki_actions_bar) to "Both" (shows buttons on top and bottom) the bottom "Cancel edit" is not working.

Screenshot of MYSQL bug #1 in admin_categories submitted by Russ.