Category: Conflict of two features (each works well independently)

The wiki "edit plugin" feature fails when the CODE plugin is used to quote a plugin that is used further down the page. "edit plugin" is not properly ignoring the contents of the CODE plugin.

For example, if I have the following in a wiki page:

{CODE()} {EQUATION()}A{EQUATION}{CODE}

{EQUATION()}B{EQUATION}

{EQUATION()}C{EQUATION}

If I click the "edit plugin" button to change {EQUATION()}B{EQUATION} -> {EQUATION()}D{EQUATION}, instead the edit is applied to the EQUATION plugin in the CODE block, resulting in:

{CODE()} {EQUATION()}D{EQUATION}{CODE}

{EQUATION()}B{EQUATION}

{EQUATION()}C{EQUATION}

The "edit plugin" function is apparently counting the number of EQUATION() plugins when it edits and is not properly skipping the ones embedded in the CODE plugin.
(This happens for any plugin, not just EQUATION)

{syntax type="tiki" editor="plain"}
__unified_incremental_update doesn't check for feature_search__

Unified Search with Lucene is awesome and is "the future of Tiki".

Now, on certain server configurations, it doesn't work well. An easy workaround is to simply revert to the legacy MySQL Full Text Search.

However, even when using MySQL Full Text Search, unified_incremental_update is defaulted to yes, and tried to update Lucene index, and generates an error message

Workaround is to deactivate unified_incremental_update, or even better, upgrade to 12.x and use Unified Index, with MySQL as storage.
---
Update: this issue has been reproduced in 12.x svn (and untested in 14.x so far, afaik) also with Mysql Full Text Search as unified search engine (on a multitiki install). See: [item5673] . {sign user="xavi" datetime="2015-05-19T09:10:57+00:00"}

How to reproduce:

Using WYSIWYG, edit a page which has a link to a wiki page which has an accented character and the link will change from accentué to accentu�


Workaround:

* Avoid non-English characters (éàç) in page names

{syntax type="tiki" editor="plain"}
!!!After upgrade the admin can't login anymore

!!!The failure sequence :
#Create a new directory or repository for the new version
#Update with your files (particularly images or icons)
#Site enable (example a sub-domain) on Apache
#Copy the database on new name
#Install manually .htaccess (compare and insert your valid options )
#Update "local.php"
#run <your new domain>/tiki-install.php. Goto the end (note an error occurs if your say at the end "run tiki" without locking or not because tiki-setup tries to re-open a session already automatically opened by installer). You just launch again (default tiki-index)
#~~#F00:__Try to login as admin : You will be rejected as wrong password __~~

!!Analysis - many possible reasons :
There are a lot of reasons to be in this situations. So to be successful a lot of conditions must be satisfied :

#If your new version uses the same current domain (after upgrade for my own I defines the same "servername" as current one and then keep the other when a particular name containng the version :
- The Cookies of session will try to reconnect an older version and a trace shows that the password is not the one you have given (generally empty). So the cookies of the site name must be cleared on your navigator

#The temp files or session table contain too wrong data : they must be cleared on server for your current copy (SVN update case)

#Your admin record in user_user record contains sessions data : they create a conflict which makes crash your login

#Be careful of the fact that you can have an open session in your navigator with the same site (sometimes we uses a lot of tab management which can create this : on firefox use showcase and search to clear your old sessions

#Generally avoid these problem is sufficient but at the end you will be prompt to update your password (as for the first login as admin with password admin). This can fail for the following reason : if the .htaccess is not set or modrewrite not well operational the <site name> will include the "port" used by your server. If your NAT translates the port address (i.e. 80-> 4397) you will get the following url <site>:4397/.... which fails

It is sure that if you use only one site close everything and upgrade you will get the minimum of problems but you will get someone anywhere.


!!~~#099:This situation is common and complex for whom have to manage product and data migration from one version (or several) of tiki to a new one.~~
It is not seen generally by developers, because it is not at all their common upgrade process nor test.

{syntax type="tiki" editor="plain"}
Wiki plugins, like ((doc:PluginBigBlueButton)), you can have the situation where the cached version of the page reports "Last time we checked, the room you requested did not exist.", but since, it has been created, and this prevent people from joining the conference.

So in the plugin code, you should be able to override the wiki page cache setting.

{syntax type="tiki" editor="plain"}
as the topic says

if you youse the redirect plugin in an article you cannot edit the article as it redirect the page even in edit mode

{syntax type="tiki" editor="plain"}
Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)

If you create a tracker with one field which is a text area set to WYSIWYG, plus another field which is an Item Link that has the "Add Items" options set, the WYSIWYG editor will not load using the TRACKER module. It must be a conflict in the two scripts. Disabling the "Add Items" option allows the WYSIWYG editor to load fine.

{syntax type="tiki" editor="plain"}
When Gzip output is enabled under Admin | Spped & Performance, it is not possible to send out newsletters greater than 100 in number, if at all. When attempting to send newsletters, it shows a 'Cannot load page' message in the frame where the log of email addresses normally appears.

Any other Plugin used within PluginTabs doesn't show the edit button. It is not possible to edit them itself like it was before.
For Example, Tab1 with CODE and Tab2 with FANCYTABLE:

{TABS(tabs="code|fancytable|box" toggle="y")}
{CODE()}{CODE}
/////
{FANCYTABLE()}{FANCYTABLE}
/////
{BOX()}{BOX}
/////{TABS}

{syntax type="tiki" editor="plain"}
several problems in Fancytable:
1. Field separator '|' (pipe) is not working with plugins. (must use '~|~' to get it work)
2. any plugin which is used in fancytable is looking fine when only one line is in. When you add a second line, you will get a lot of html viewed.

here is an example i used to figure out these problems:
{FANCYTABLE(head="code|box" colwidths="50%|50%")}{CODE(caption="code with 1 line" colors="sql")}select sysdate from dual;{CODE}~|~{BOX(title="box with 1 line")}1st line in a box{BOX}
{CODE(caption="code with 2 lines" colors="sql")}select sysdate from dual;
select sysdate from dual;{CODE}~|~{BOX(title="box with 2 lines")}1st line in a box
2nd line in a box{BOX}{FANCYTABLE}

Typing a page into Quick Edit, either in the Quick Edit module (I know it is depreciated but was testing this as well) or from the Create a Wiki Page tab on the List Wiki Pages seems to bypass category permissions and allows editing of pages which should be locked for the user. This happens if the page which is entered does not EXACTLY match the case of the existing page.
For example, in Global Permissions, Registered Users have Edit permissions; a category Alpha has Edit permissions assigned only to group Alpha, Registered Users have no edit permissions on this category. A page called Alpha exists in category Alpha. If a Registered User who is not part of group Alpha tries to create/edit page "Alpha", they receive the proper error about not having permissions to edit the page. Should that same user try to create/edit page "ALPHA", "alpha" or any variation which does not match exactly "Alpha", they will be allowed to edit the existing page "Alpha". This will also work if they enter the URL to edit the page directly with a different case (i.e. "tiki-editpage.php?page=Alpha" will prevent editing whereas "tiki-editpage.php?page=ALPHA" will allow editing).

Calling plugins in headings in pages where maketoc is used can cause breakage. For example, this happens when calling the ANAME or FOOTNOTE plugins.

! Effect on ANAME
Although Tiki generates anchors for all headings automatically, I find using ANAME is a great way of creating manageable and easily memorable Anchors for otherwise unwieldy headings
If a heading within a tiki page is coded as follows
{CODE(caption="1. Tiki Source Code snippet" wrap=1)}
!! Fourth and Even More Forgetful Heading{ANAME()}Quick4{ANAME}
{CODE}then Tiki generates the following HTML code
{CODE(caption="2. Generated HTML snippet" wrap=1)}
<h3 class="showhide_heading" id="Fourth_and_Even_More_Forgetful_Heading"> Fourth and Even More Forgetful Heading<a id="Quick4"></a></h3>
{CODE}which can be exploited by
{CODE(caption="3. Tiki Source Code snippet" wrap=1)}
{ALINK(aname=Quick4)}Link to Fourth Heading by its Quick4 Anchor{ALINK}
{CODE}All the above works flawlessly.

However, add MAKETOC to the page above the source line where ANAME is last used and it breaks the ANAME anchor(s). For this example, the maketoc is restricted to level 2 headings only as ~np~{maketoc levels="2"}~/np~ which makes the generated HTML a little more compact.
Tiki generates the following HTML in response to the inclusion of maketoc
{CODE(caption="Generated HTML for maketoc snippet 3" wrap=1)}
<ul><li><a href='#First_Level_Two_Heading' class='link'> First Level Two Heading</a>
</li><li><a href='#Second_Long_and_Equally_Unmemorable_Heading' class='link'> Second Long and Equally Unmemorable Heading</a>
</li><li><a href='#Third_Painfully_Difficult_Heading' class='link'> Third Painfully Difficult Heading</a>
</li><li><a href='#Fourth_and_Even_More_Forgetful_Heading' class='link'> Fourth and Even More Forgetful Heading<a id="Quick4"></a></a>
</li><li><a href='#Fifth_Long_and_Not_Very_Memorable_Heading' class='link'> Fifth Long and Not Very Memorable Heading</a>
</li></ul></li></ul><!--toc--></div><br />
{CODE}Note how the entry for the Fourth Paragraph has the anchor "Quick4" associated with it. The HTML code generated for the Fourth Paragraph heading remains identical.

The effect of this is that the tiki anchor Quick4 is now incorrectly linked to the TOC entry, being the first instance of HTML ANCHOR within the HTML file.

If the MAKETOC plugin is included below the ANAME, then the ANAME works as intended, since that is the first occurrence of the generated HTML ANCHOR statement.

I have a couple of test pages which illustrate this issue, if they are of any use in your testing.

! Effect on FOOTNOTE
Calling FOOTNOTE returns an HTML A element with an id, so using that same identifier twice causes invalid HTML. Additionally, since browsers favor the first element using the identifier in such cases, the TOC's instance wins if ~np~{maketoc}~/np~ precedes headings, which is not what we want.

! Cause
Plugin calls are executed in parse_first(). (Calls to plugins in "html" format are replaced by alphanumeric fingerprints.) After, parse_data_process_maketoc() is called and expands "~np~{maketoc}~/np~" to headings, so that each plugin call in a heading in the TOC has its result (or fingerprint) twice in the source. (After, replace_preparse() replaces fingerprints with the result of plugin functions (stored during parse_first's execution).)

This issue happens because maketoc therefore causes a plugin call's result to be repeated in the TOC (instead of possibly executed again specifically for TOC-s), which has 2 problems:
* plugins don't expect their output included twice in the page, so some (such as ANAME) may use HTML's id attribute in a manner incompatible with maketoc, causing invalid HTML
* plugins don't expect their output to be included in an HTML A element, so some (such as FOOTNOTE) for example generate links themselves, again causing invalid HTML

{syntax type="tiki" editor="plain"}
Using my version is 8.4 (MyISAM), installed via softaculous, when WYSIWYG is enabled the editor does not show up on the Admin>ContentTemplate page. I looked at the generated source code where the editor should appear and what it shows is this :
~lt~tr>
~lt~td/>

instead it should show:
~lt~tr>
~lt~td>
(code for WYSIWYG editor goes here)
~lt~/td>

Both features work fine independently, just not simultaneously.

! GROUP Plugin breaks CODE Plugin

Affects both v6.7 and this site. Worked OK on v4.3

{CODE(caption="1. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}

Now add a ~np~{GROUP(groups=>Registered)}~/np~ include the same code snippet and close out the ~np~{GROUP}~/np~. Start of CODE within GROUP

{GROUP(groups=>Registered)}
{CODE(caption="2. Code inside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}
{GROUP}

End of CODE within GROUP. On v6.7 the code box is displayed and the code snippet is truncated at the start of the Else statement fro a registered user. On this site, the code box is not displayed and the code is truncated at the same point for a registered user.

For an anonymous user, on both versions, there is no code box and the user see ~np~"other content{GROUP}{CODE} "~/np~

Repeating the code snippet again outside of the restricting Group statement works
{CODE(caption="3. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}.

The code example is lifted from [http://doc.tiki.org/PluginGroup] with a caption statement added.

Happy to help test any patch,

Martin.

{syntax type="tiki" editor="plain"}
To reproduce

# Install a fresh Tiki
# Create some usernames as usual
# Set "Use email as username" feature to yes
# Create more users (this time, username will be the email)
# Create a newsletter
# Subscribe the Registered group to the newsletter
# Send a newsletter

The system will crash and be unable to send the newsletter because some users don't have valid emails. If you error reporting is activated, you will get a message like this:

{CODE()}
System error.

The following error message was returned:

Duplicate entry '3-mcradmin-g' for key 'PRIMARY'
The query was:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES (?,?,?,?,?,?,?)
Values:

3
mcradmin
6b78cc21c16e768dd8fbb6b538c6bf78
y
1339700591
g
n
The built query was likely:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES ('3','mcradmin','6b78cc21c16e768dd8fbb6b538c6bf78','y','1339700591','g','n')
Things to check:

Is your database up and running?
Is your database corrupt? Please see how to repair your database
Are your database credentials accurate? (username, database name, etc in db/local.php)
Did you complete the Tiki Installer?
Please see the documentation for more information.
{CODE}

{syntax type="tiki" editor="plain"}
It is not possible to delete a calendar as long it contains a recurring event. The User does not get proper feedback as why he can not delete the calendar.

Conflict detection when page is saved would be nice too. Often happens when people are translating pages.


It should offer disambiguation page...

For example http://dev.tiki.org/Download gives an error but it does contain
{CODE()} (alias(Download)) {CODE}
As you can see here:
http://dev.tiki.org/tiki-pagehistory.php?page=Get+code&source=0

So the page is not found, but when you try to create, you get:
{img fileId="562"}

So clearly it exists...

Using wiki page cache, it happens that page cache is generated by a user who set his language to Italian. And then, the page is visited by someone who has language to something else, but sees Italian.


Workaround: turn off wiki page cache if you have a multilingual site

On doc.tiki.org/Installation, there is a link to doc.tiki.org/tiki-index.php/page=Installation

{img fileId=54}

And then, this page is broken, and it has many new links to index, most of which are invalid.

{img fileId=55}


Another example:
{img fileId=63}

I created a file gallery in my tiki installation and set all php *upload_size* etc. parameters in my .htaccess correctly. According to these parameters I can upload files up to a size of 8 MByte, which works without any problem, if I do this directly from the file gallery.

Now I try to use this file gal in a tracker via the tracker field "file". Everything seems to work well, uploads are shown with a progress indicator from 0 - 100%. But uploading quietly fails for files larger than 600 kByte.

The files are shown in the gallery, but on the server they have a size of 0 (zero) Bytes, files smaller than approx. 600 kByte work well.

To point it out, the problem is only existent from within a tracker using the new drag and drop (html5??) interface. With an older Internet Explorer, which does not show the progress indicator, uploading works well from within a tracker, too.

I cannot find a reason or a solution...thanks in advance...

{syntax type="tiki" editor="plain"}
Using a pretty tracker as registration form doesn't allow to de-activate the captcha.
Since one of the point of using a tracker for registration is to allow special questions which robots can't answer, what is the point of forcing the use of the captcha (through which robots can easily pass)?
Maybe a duplicate of bug #1818, I'm unsure.

SHOW admin password: 01234

Adding many users at once to a group fails in 12.x, and it used to work nicely in 9.x LTS at least.

I had Jquery Chosen enabled, and when I disabled it, I was able to add them to a group through tiki-adminusers.php as usual.


To reproduce, go to:
http://xavi-9794-5163.show.tikiwiki.org/tiki-adminusers.php

u: admin
p: 12345

select both users (user1 & user2), click at "Manage group assignments", and choose to assign them to group "Admins". Validate the confirmation step. Nothing happens (they are not added to the Admins group).

Repeat without JQuery Chosen, and it will work as expected.
---
Update {sign user="xavi" datetime="2014-04-07T07:44:15+00:00"}
Actions on multiple users with chosen and sortable tables work, but the second dropdown is not shown properly:
{img fileId="742" thumb="y" rel="box[g]"}
---
Update {sign user="xavi" datetime="2015-04-02T08:04:24+00:00"}
You can't even select any groups at the step to choose group in the multi selection combo box.
{img fileId="992" thumb="y" rel="box[g]"}
---
Update {sign user="lindon" datetime="2015-04-07T03:41:55+00:00"}
I am not able to recreate this [[the former issue report related to jquery sortable tables] using my local 12x - I am able to add or remove multiple users to multiple groups. Did it with 25 users with no issue. The list of groups came up properly and I was able to multi-select.
---
Update {sign user="xavi" datetime="2015-12-16T07:59:32+00:00"}: removed references to Tablesorter as I could confirm that at least with current code (thanks lindon for checking!) the issue seems to be attibuted to Chosen only.

Going to Admin Categories > Bug on dev.tiki.org returns alerts on top of the page:
{CODE()}
ErrorErrorError
Tracker list_items ran out of memory after 0 items.Malformed search query: Parsing search query failed: "org.elasticsearch.common.ParsingException: [_na] query malformed, must start with start_object"Notice: invalid variable value: $_GET["maxRecords"] = undefined
{CODE}

At tiki-admin.php?page=login , Username, when I enable "Use email as username" some username settings are now hidden (meaning not in use) but they are still applied.

Minimum length
Maximum length
(And may be "Force lowercase")

I created an instance to test and reproduce.
You need to "really" register a user, not using the admin user to create new users.

How to reproduce :
# Go to Admin, Control Panels and switch to "Advanced" (to see advanced preferences)
# Go to log-in : tiki-admin.php?page=login, Registration & Log in
# Enable : Users can register
# Disable : Validate new user registrations by email (we don't want to validate email)
# Go to : Username and set "Maximum length" to 6
# Apply (save)
# Use a different browser (check you are not logged), go to the Tiki and register a new user
# Try to input more than 6 characters for the username, you will see this error:
+ {img fileId="1689" thumb="box"}
# Go back to your previous browser (logged as admin), log-in : tiki-admin.php?page=login, Username
# Enable "Use email as username" option
+ The parameters Minimum length, Maximum length, (And may be "Force lowercase") will be hidden has not relevant anymore.
# Go back to your different browser (check you are not logged)
# Create a new user with an email for login (obviously longer than 6 characters).
+ You won't see an error on focus
# Submit your registration and you will see the error:
+ {img fileId="1690" thumb="box"}

The difference of treatment in the process make me think there is some wrong additional condition that should be cancelled if "Use email as username" is enable.