Category: Consistency

{syntax type="tiki" editor="plain"}
When you move a part of a structure to another or new structure, the structure_id will not be updated.

wiki (wysiwyg) inline editor transforms page alias links into standard wiki page link on save (alias lost)

See it reproduced here:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

The homepage has at the bottom the standard code for an alias at teh page "HomePage" to be accessed also from "Casa" alias page name.
{CODE()}
(alias(Casa))
{CODE}

Therefore, you can access to the homepage also with:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=Casa

However, if you open that wiki pade for edition with "Inline wiki editor", make some changes, and saved the page through the inline wiki editor (click again at that button that you used to open the inline editor), then the alias link is gone. If you edit the page with the standard wiki plain text aditor, you will see that the code at the bottom is replaced with a standard wiki link pointing to "HomePage" and using "Casa" as label.
{CODE()}
((HomePage|Casa))
{CODE}

Text boxes do not save in WYSIWYG mode. Even switching from WYSIWYG to Source and back will remove much of the formatting. I have turned this feature off for the time being because formatting is automatically removed when you go to edit a wiki.

This is mitigated by a warning in edit help:
{QUOTE()}The conversion process is not entirely transparent, meaning that you may notice differences between the look of a page in different modes.
This will improve in future updates but as the two systems have significant differences in what they can do it is unlikely to ever be totally transparent.{QUOTE}

At tiki-listpages.php if you delete a page using the wrench action item "Remove" you won't see the result till you reload the page.
It happens in some other places, see the related.

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 /}.

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)

Wiki tables are really ugly now. Ex.: http://tiki.org/Domains
{img fileId="857"}

Fancy tables are better. Ex.: http://themes.tiki.org/Sample+page (notice there are no stripes)
{img fileId="858"}

And PluginWish, which is an alias of PluginTrackerList looks like this (notice the stripes):
{img fileId="859"}

PluginProposal looks like at http://dev.tiki.org/CSS+Frameworks+and+Preprocessors
{img fileId="861"}


So what is right Bootstrap way to do tables?

Here are two related commits in trunk:
https://sourceforge.net/p/tikiwiki/code/51838
https://sourceforge.net/p/tikiwiki/code/51677

Should they be changed?
Should they be backported to 13.x?

From Tiki26 the slideshow feature default setting have been changed and this breaks previous slideshows using H1 to H3 to create slides.

If you enter following code in a wiki-page ~np~ ...page... ~/np~ there is a bug in the interpreter. The preview-mode is working right and shows ...page... as plain text, but when you save the page wiki-parser interprets it as a tag and shows the pagenavigation-bar.

On a Tiki23 I set a group (admin groups) to have a membership expiration date.
{img fileId="1718" thumb="box"}

Then on a wiki page I set up a memberpayment plugin : https://doc.tiki.org/PluginMemberPayment
I can set the hideperiod parameter with a dropdown of yes or no

Issues:
# The tooltip for "hideperiod " tells me the default is "1" (not yes or no)

Update: Re-tested on Tiki25 still here.

On Tiki as long as the feature "Stats" (tiki-admin.php?page=stats&highlight=feature_stats) is not enabled (it is disabled by default) hits on pages are not counted.

However, even the feature is disabled there is a "hit" column displayed at http://bsfez-11581-8115.show2.tikiwiki.org/tiki-listpages.php (and certainly other places). It will be populated with a lot of 0 for Tikis that will never use or needs stats.

{img fileId="1772" thumb="box"}

{img fileId="1773" thumb="box"}

On a Tiki24, on a tracker I have an item link.
On the option I select Multiple fields, Dropdown and in Format for Customising Multiple Fields I do some customisation.

When the item is in editing more (tracker edit, inline edit) the display is unformatted when I'm in view mode Format for Customising Multiple Fields is applied.

IE:
Multiple Fields;
* ~~#99F:Country~~
* ~~#99F:Name~~
* Other fields

Format for Customising Multiple Fields;
%1 from %0

Expected to be seen in the dropdown: Bernard from Israel.
Result: Israel Bernard

{syntax type="tiki" editor="plain"}
On a Tiki25, I create a tracker with a username selector to be the owner of the items.

In the tracker properties, I set "User can see his own items".
^
User can see his own items
The tracker needs a user field with the item-owner activated. No extra permission is needed at the tracker permissions level to allow a user to see just his own items through Plugin TrackerList with the param view=user
^

And so, user can see his items and I can unassigned any tracker global permission.

I also set Restrict non admins to wiki page access only
^
Restrict non admins to wiki page access only
Only users with admin tracker permission (tiki_p_admin_trackers) can use the built-in tracker interfaces (tiki-view_tracker.php and tiki-view_tracker_item.php). This is useful if you want the users of these trackers to only access them via wiki pages, where you can use the various tracker plugins to embed forms and reports.
^

So I understand that only Admins can use the tracker interface.

And it is working fine.

However, if I need user to update their existing items using a modal in a plugin List (tracker-update) or inline-editing format the user see a permission denied.

I have to assign to the group the permission can change item (tiki_p_modify_tracker_items) and this allows users to edit his items on a plugin list.

But now;
* Restrict non admins to wiki page access only as no more effect. (user sees the tracker interface (/trackers | list, the tracker content | /tiki-view_tracker.php?trackerId=xx and /itemxx | the tracker item)
* They can edit any items (other users)

Which is pretty bad because it just cancelled:
# User can see his own items
# Restrict non admins to wiki page access only

There may be more with the tracker field additional permissions and other workaround, but this is just digging deeper and deeper.

In my point of view, it should be possible for an admin to set that user cannot see the tracker interface and can see/edit only their own items quickly (in the tracker properties) without risking display to one user items of another.

Using a Tiki at tiki-admin.php?page=login you can set a tracker to collect users information.
In the group (registered) tiki-admingroups.php you can define what field to display in the registration form.

This work fine.

You can also use a tracker plugin in a wiki page to fill a tracker item and include a registration.
However the input field displayed are limited to :
* Username *
* Email *
* Passcode to register * (if set)
* New Password *
* Confirm password *

And NOT the list of field you set in your Group (as above).
The tracker plugin Registration option shouldn't modify the fields require for the registration and the way the admin has set it.

I created an instance to demonstrate.

While __you are not logged__ if you go to register :http://bsfez-11581-7961.show2.tikiwiki.org/tiki-register.php

The page show ALL the fields I added for registration at :http://bsfez-11581-7961.show2.tikiwiki.org/tiki-admingroups.php?group=Registered

{img fileId="1661" thumb="box"}

Good.

Compare to the registrations fields proposed in the tracker plugin and you see all are missing.
http://bsfez-11581-7961.show2.tikiwiki.org/tiki-index.php?page=HomePage

{syntax type="tiki" editor="plain"}
When you monitor a page and do some changes then save, your user should not receive a notification.
This work, your user don't receives notifications on own changes.

But the success message is misleading, for exemple my user "me@blabla.com" edited a page and the feedback says:

 Success
Page 00Bernardplayground2 saved (version 88).
To review the changes you have just made compare the versions in history of this page.

 Notification sent to:
me@blabla.com, riki@blabla.com

Feedback is wrong, I won't be notified.

{syntax type="tiki" editor="plain"}
When displaying a Wiki page as slides the wrong favicon is displayed. I'm using 1.9.11 and the favicon from Xampp is displayed which is found in the root web directory ./htdocs/ rather than using the favicon found in the TikiWiki directory ./htdocs/tikiwiki/

{syntax type="tiki" editor="plain"}
When I create a link to a Wiki page, the editor changes the reference of the link until the fourth time when I edit the page, but this is not a problem. The problem occurs when the link points to a wiki that has a special character, for example - cabeçalho - which means header (in Portuguese from Brazil), since the editor corrupts the link and it crashes.

Here I have an example.

The link should point to the wiki - Projeto de Pesquisa Social: Quem somos nós ? Proeja 2010 - is corrupted by the editor and points for - Projeto+Pesquisa+Social:+Quem+somos+n%C3%83%C3%83%C3%83%C3%83%C3%83%C3%82%C2%B3s?+Proeja+2010 -


Here we have a wiki page as an example:
http://www.biblioteca.ifc-camboriu.edu.br/criacitec/tiki-index.php?page=Example

After upgrading a Tiki23 to 2322c5e8 it solved some previous issues I had (see related ticket) but there is still a difference between submitting manually my sitemap generated from Tiki and using the console command (scheduler).

If I look at tiki-admin_sitemap.php I'm suggested to submit : https://www.bernardsfez.com/tiki-sitemap.php?file=sitemap-index.xml
With this url, Google discover 42 URL.

But from what I see in the Google console search, seems the console command use a different URL, https://bernardsfez.com/storage/public/sitemap-index.xml, which allow to discover 96 URL.

From a quick calculation the missing 54 URL are my Articles.

{img fileId="1670" thumb="box"}

{syntax type="tiki" editor="plain"}
This seems solved in Tiki 5.

''type content'' : Problem, way to go around and may be a quick way to go to a solution

Hy,
4.0, 4.1

I test all functions including those that are not finalized.

The problems occurs with Firefox 3.5 not with IE8 (other ie not tested neither opera, google etc...)

In WISIWIG text editing WIKI obtained in circumstances that I can not confirm the background color of textarea is black when you scroll to the end of long text (the text is more long than the height of textarea).
The content text exist and you can see it if you select it and change the text background color.
The problem is the scroll with the background property color (in strasa css #F3FCFE color)

''Complements''
*Problems occurs in wysiwyg mode (not in view source mode)
*If you change the background color of the text you can see it
*The problem is directly linked to scroll, when you change the textarea size (for example go to "fullscreen" edit), the black background appears at the bottom just one line after beginning to scroll down



I hope to have provided informations to go straight to the bug.

Best regards

If you submit a form and there is a required Text Area (with WYSIWYG) that isn't input, the message "This field is required" shows up underneath the field (as it should).

However, unlike regular text fields and text areas (non-wysiwyg), when you start typing something in the field, the error stays there (usually, as you type something, the message is cleared).

Not a big deal in terms of usability/function but it is inconsistent and makes it look a little less polished.

WYSIWYG is now a basic feature in 12, but the panel is not visible from tiki-admin.php

{syntax type="tiki" editor="plain"}
We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

This bug is across all browsers.

Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it.

I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation.

I have tried in both IE 8 and FF 3.6 with the same result.

Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499]

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not format the header (color it red) without breaking the "header" status.

Currently we have a page with a ~np~{maketoc}~/np~ at the top and a bunch of h1, h2, h3 headers. We wanted to make the text color red for one of the h1 titles so it was more visible to users. Once we did this in the WYSIWYG editor, the header is no longer listed in the maketoc AND the Edit Section button is gone next to the header text. This ''may'' be associated with another bug [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3763].

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%% the lists (numbered and unordered) have irregular spacing between lines. Edited in Wiki normal and WYSIWYG Source modes work fine.

To reproduce create the following structure in a WYSIWYG editor{CODE()}*blah zaa zaa
*This is a list
**now indenting the list
**blah
*back out
**back in
***really far in
*all the way out{CODE} %%% this example displays for us as {CODE()} blah zaa zaa

This is a list

now indenting the list
blah

back out

back in

really far in
all the way out
{CODE} %%% Sometimes there is a break, other times there is not. If I Preview while editing it looks fine. If I edit the HTML via the Source WYSIWYG view and save then it looks fine until I save it in WYSIWYG mode again.