Category: 14.x

Bootstrap Sandbox with redacted data. Installed Amelia Bootswatch theme in order to see what elements have not yet been converted to Bootstrap Components.

Issues can be reported here:
http://themes.tiki.org/tracker2

Hi all,
sorry if is completely wrong what I do... (and maybe entered above), but I'm totally new to Tiki and installed the 14beta to get an impression, as -seen from my requirements list- Tiki14final is what I want to use live. So I'm really testing around - and thought this may not only help me, but also you. Okay, enough introduction.

I created a forum and tried to add more forums by copy the existing one. Maybe I did something wrong, but to me everything seems to work in the process - there was just no new forum in the end.

Thanks for taking care and
best regards
Uli

Hi Uli,

I did reset the admin passwort of your show-instance to 12345, as it's the only way, we can access and check the bug (or error 40) .
More then in the comments.

Greetz
Torsten

PS:
are you German language?
If yes, pls see: [tiki.org/detug]

When I have two words side by side like this:
link1 link2

Then I select the first one and add a link to a file using the FILE tool tip in the edition bar and all is well and I get:
~np~{FILES( fileId="1")}link1{FILES} link2~/np~

Then I want to do the same with the second word. This does not work because it does not add it on the second word. Instead it replaces the first:
~np~{FILES( fileId="2")}link2{FILES} link2~/np~

Calls to plugins which are inside a call to the WYSIWYG plugin produce no output (which usually means that their effect is invisible). Some plugins, such as FOOTNOTE, have effects other than causing output, so calls to these may keep part or all of their effect.

This bug was introduced by the changes to wikiplugin_wysiwyg.php in {commit id=50752}. Tiki versions 14 to 18+ are affected.

The following call to WYSIWYG demonstrates:
{CODE(theme="default")}{WYSIWYG(use_html="n")}
This dummy content is visible.{FOOTNOTE()}Note which is invisible, but should be indicated by a number which is actually invisible{FOOTNOTE}
{GROUP(groups="Admins")}This should be visible for admins{GROUP}
{FADE(label="This should be visible")}Hidden{FADE}
{WYSIWYG}{CODE}


This happens because plugin_execute() calls ParserLib::convert_plugin_for_ckeditor() since ck_editor is true, and therefore returns an empty string to parse_first(), and therefore to parse_data(). That parse_data() has its ck_editor option true, since it is called by parseToWysiwyg(), called by wikiplugin_wysiwyg().

Unfortunately, the revision bringing this regression also fixes WYSIWYG edition. So going back to the previous situation breaks edition again. One can only choose between working visualization and working edition.

I believe the way to fix is to go back to parse_data(), but re-parse the plugin call's content differently when editing.

When I click the delete icon for a user in the list at tiki-adminusers.php, a modal dialog displays that says only "null". But the user isn't deleted.

When we are log in and want to erase or change a recurrent event, we have this screen:

{img fileId="1021" thumb="y" rel="box[g]"}

Hey there,

talking about tiki-adminusers.php

Just recently tere was a new dialogue added to apply users. Today a popup opens and you can choose respectively multiselect groups to apply the users to or to remove users from.

I could not really test this good looking feature if it works spot on, or is tere would appear objections, because on save the user is not applied to the group - the setting is just ignored.

So on a site already having this update, I have to apply users to groups from tiki-admingroups.php tab 'members', which is a workaround, but not a good UX for te released system (thus a blocker).

I will look into it for a more detailed description lateron and try to find out who committed tis. Anyway, it would be nice, if someone of the coders could check and maybe fix ... I recon, that only a very little bit is missing.

Clicking "Create" button brings up pop-up which is lower z-index and thus unclickable than the grayed overlay. Clicking anything closes it again. Unable to create new tracker manually. Seen in FF.
{img fileId="955" thumb="y" rel="box[g]" width="640"}

https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396
offers a canonical of
https://tiki.org/forumthread50396

Good.

Now, it also has two links:
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396&display=print
https://tiki.org/tiki-view_forum_thread.php?comments_parentId=50396&display=print_all

The print versions should have the canonical as well.

When trying to use a tracker category field as a filter, only the value "Any" is displayed.

The very useful wiki plugin catorphans only works with wiki pages.

The documentation suggests it is sort of set up to deal with different types of uncategorised objects by setting the objects=> parameter to various values ie wiki|article|blog|faq|fgal|forum|igal|newsletter|poll|quizz|survey|tracker.

But looking at the plugin code, the code comments make it clear that the development is not yet complete and only the 'wiki' object has been coded.

The documentation has been updated to make this clear - but extending this plugin to the other features would be very useful now that Categorisation is the major permission/access control mechanism in Tiki

Yet, the regular mode works fine on my Android phone.

It'd be nice to have an option which would open a new browser or window when clicking a URL in the shoutbox.

Tiki mode is now part of CodeMirror:
https://github.com/marijnh/CodeMirror/tree/master/mode/tiki
http://codemirror.net/mode/tiki/

Be we also have a duplicate in Tiki code:
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/lib/codemirror_tiki/mode/tiki/tiki.js

When adding or editing sites through the Directory Site Admin interface (tiki-directory_admin_sites.php), the "Country" field is not sorted (on my install, it starts with "Sudan", ends with "Niger" and goes all over the place inbetween).

Linked to BWL#4954 as the issue is similar (although that one relates to a different interface, and has since been fixed and closed).
---
__Edit 2015-11-22:__ No demonstration at this time due to [https://dev.tiki.org/item5768|BWL#5768]; pending that, it should be confirmable through any 14.x install with the Directory feature enabled, a user logged in that has Directory Admin privileges, and navigating to the __tiki-directory_admin_sites.php__ page.
---
__Edit 2015-11-23:__ As BWL#5768 is now closed, I have been able to demonstrate this on show.t.o. Just using the 'admin' user is fine to test, per the note above. On this instance, the "Country" field starts with "Finland" and ends with "Malawi" in the Directory Site Admin interface.
---
__Edit 2015-11-30:__ Am attempting to test a possible fix (courtesy __lindon__) using a trunk instance on show.t.o; the instance may be destroyed and re-created a few times until I get one that works.
---
__Edit 2015-12-15:__ Have a successfully set up v14.2svn instance on show.t.o. The bug persists in this instance.

Create a bash or php script which will convert the old type Tracker rating field to the new one for upgraders (people who upgrade) using this field.
---
We would benefit in the Tiki Community itself since we would re-use all the information added by users over the years to indicate which bugs in the bug tracker are more important to them. It could be a way to review the list of pending bugs by priority according to user's opinion expressed in that rating option. Thanks luci for filling this wish report {sign user="xavi" datetime="2014-09-21T07:04:05+00:00"}

Create a profile for an improved Issue Tracker (with linked trackers) using the latest improvements in 14x

See this discussion:
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2015-03-17,Tue&sel=180#l176]

I have stumbled upon a problem when a feature (especially Hotwords) is enabled it creates lot of issues incorrectly parsing the content of Wiki pages and other parts of Tiki where wiki or smarty syntax is involved resulting in links inside rendered HTML attributes or WSODs. So here is my wish:

It would be super useful to have a plugin which would prevent some enabled features auto-parsing or allow parsing of its body depending on params, something like:

__The next example would prevent (ignore) parsing of the Hotwords and CamelCase WikiWords in the plugin body.__

{CODE()}
{PARSE(ignore="feature_hotwords:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

__The next example would allow only parsing of Wiki syntax and WikiWords and nothing else in the plugin body.__

{CODE()}
{PARSE(only="wiki_syntax:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

Other candidates for the "ignore" and "only" params:
feature_wiki_allowhtml
feature_autolinks
feature_wiki_argvariable
feature_wiki_paragraph_formatting
smarty_syntax
wiki_plugins (meaning all wiki plugins)
wikiplugin_div (meaning specified wikiplugin)
etc.

I think it would be useful also for the LTS versions.

Anybody takes the challenge ?

{sign user="luci" datetime="2013-12-12T20:48:49+00:00"}

See: https://tiki.org/forumthread51287
---
Addendum: Make a plugin in Tiki to display the basic d3.js-based charts already developed in the past (in through PluginChart or other means)

Related: https://dev.tiki.org/item6263 - Make PluginChart optionally reuse some other lib already in Tiki to make js-based charts (raphaeljs, chartjs, d3.js, etc)

See:
https://dev.tiki.org/Data+Visualization#d3.js

Basic d3.js-based charts already made in Tiki:
http://marclaporte-11197-5155.show.tikiwiki.org/
u: admin
p: 12345

Date validation (at Registration) is not validation the date field correctly. Validation only accept if day of the date is under 12. It seems it understand the number as as months not days. And it is not themonth field, since the month field popup menu is just next to the date field.

I checked all the date formats and reseted it to the Tiki default and the error still persists.

Discussion here: ((BOM))

dev.t.o 14.x: only the last item in the multiple selection combo box is stored for this tracker item

See it reproduced here:
https://dev.tiki.org/item5464?from=Structure

Edited this item as user "xavi" (without admin rights, in case it matters), Selecting some other categories in the combo box for the field "Category" or the field "Version": => only the last category (or at least, only one from all the ones selected) is stored

The "perform action with checked" icons at the bottom of the tiki-list_file_gallery.php listing (in list view) requires additional code rewriting in order to convert to iconsets due to the fact that iconsets cannot be easily used for input images.

In Tiki 14, if a user sets their "Displayed timezone" preference (under __User Preferences__ > __Preferences__ > __Displayed timezone__) to "Site default" and saves this change, then whenever the Preferences page is loaded afterwards for that user:

*the "Displayed timezone" field is deactivated (i.e. cannot be changed by the user).
*the message "Warning: Site time zone xxxxx is enforced and overrides user preferences" is displayed below the field (where "xxxxx" is the default site timezone).

This occurs irrespective of __Displayed time zone__ setting under General Preferences (i.e. even if it is set to "Use time zone set from user preferences...", the setting still cannot be changed).
---
__Edit 2015-11-03:__ This bug does not appear when using admin privileges to edit a user's settings, only when the user themselves tries to.

When nested more times, it stops working and breaks the whole page parsing.
This works:
{CODE()}{DIV(class="level1")}
{DIV(class="level2")}
{DIV(class="level3")}
{DIV(class="level4")}
{DIV(class="level5")}
{DIV(class="level6")}
{DIV(class="level7")}
Foo Bar
{DIV}
{DIV}
{DIV}
{DIV}
{DIV}
{DIV}
{DIV}{CODE}

This breaks:
{CODE()}{DIV(class="level1")}
{DIV(class="level2")}
{DIV(class="level3")}
{DIV(class="level4")}
{DIV(class="level5")}
{DIV(class="level6")}
{DIV(class="level7")}
{DIV(class="level8")}
Foo Bar
{DIV}
{DIV}
{DIV}
{DIV}
{DIV}
{DIV}
{DIV}
{DIV}{CODE}

See the SHOW instance.

__Expected behaviour:__
Parsing nested plugins should work flawlessly no matter how many levels are nested or be limited to e.g. 20 levels (ideally should be configurable) but should not break up to that max level; only if above the limit, it could show the unparsed syntax instead of breaking whole content rendering.