Category: 17.x

Username rename in trackers doesn't work when there are multiple values.

The wysiwyg_wiki_parsed preference influences WYSIWYG edition, [https://tiki.org/forumthread67421|even if it was not supposed to]. When it is enabled, what one sees in the WYSIWYG HTML (wysiwyg_htmltowiki disabled) editor is not necessarily what one gets. For example, if one enters ~np~"__Text__"~/np~, "Text" will be displayed in bold after parsing, the underscores parsed as if the page contained wiki syntax.

This issue persists in trunk as of r65130. Moreover, following r30245 (2010-10-23), this behavior is "specified" by the editor's help. So fixing this may be considered as a semantic change for existing data. A simple fix without data conversion could disappoint user expectations. Plus, HTML WYSIWYG does not have equivalents to some wiki features, such as plugins.

[https://dev.tiki.org/item6532|Ticket #6532] reports a corresponding bug when wysiwyg_htmltowiki is enabled.

The WYSIWYG wiki editor (feature_wysiwyg enabled) allows typing HTML tags. But if "Use Wiki syntax in WYSIWYG" (wysiwyg_htmltowiki) is enabled, this HTML is not interpreted, just displayed literally.

This does not work however. As soon as the editor switches to Source, or saves the page, an attempt to convert all HTML markup to Tiki markup is done. This conversion is lossy and loss is quiet. For example, if I have...
{CODE(colors="htmlmixed" theme="default")}<table><caption>Title</caption><tr><td>Value</td></tr></table>{CODE}
...it will be converted to...
{CODE(colors="tiki" theme="default")}||TitleValue||{CODE}
Unsupported tags are apparently just removed.

Strangely, if one copies a string with HTML in the WYSIWYG textarea and pastes it in the same area, the paste shows the result of interpretation (the HTML tags are no longer displayed literally).

[https://dev.tiki.org/item6523|Ticket #6523] reports a corresponding bug when wysiwyg_htmltowiki is disabled.

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}

Wiki Feed fails with maximum memory error, or max execution time (sometimes) error.

I have created a show instance with a page that will kill it.

I am sure it is plugin related somehow. When I disable all the plugins, it runs just fine, Even with the same page content.

I had previously formatted this page with wiki syntax, but it was just too much for any tiki functions to work properly, so I reformatted it to use HTML and only when wiki plugins offer functionality that goes beyond formatting do I use them, (things that would be impossible to do with just HTML formatting, such as TOC and Footnoes).

Error messages:

PHP Fatal error: Maximum execution time of 30 seconds exceeded in /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPantsTypographer.php on line 431
PHP Stack trace:
PHP 1. {main}() /Sites/tiki/tiki-wiki_rss.php:0
PHP 2. TikiLib->parse_data() /Sites/tiki/tiki-wiki_rss.php:75
PHP 3. ParserLib->parse_data() /Sites/tiki/lib/tikilib.php:139
PHP 4. typography() /Sites/tiki/lib/parser/parserlib.php:1723
PHP 5. Michelf\SmartyPants->transform() /tiki/lib/init/typography.php:59
PHP 6. Michelf\SmartyPantsTypographer->educate() /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPants.php:194
PHP 7. Michelf\SmartyPantsTypographer->spaceUnit() /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPantsTypographer.php:192
PHP 8. preg_replace() /Sites/tiki/vendor/michelf/php-smartypants/Michelf/SmartyPantsTypographer.php:431

or

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 262144 bytes) in /Sites/tiki/lib/diff/Diff.php on line 501
PHP Stack trace:
PHP 1. {main}() /Sites/tiki/tiki-wiki_rss.php:0
PHP 2. diff2() /Sites/tiki/tiki-wiki_rss.php:80
PHP 3. Text_Diff->__construct() /Sites/tiki/lib/diff/difflib.php:98
PHP 4. Text_Diff_Engine_native->diff() /Sites/tiki/lib/diff/Diff.php:44
PHP 5. Text_Diff_Engine_native->_compareseq() /Sites/tiki/lib/diff/Diff.php:379
PHP 6. Text_Diff_Engine_native->_diag() /Sites/tiki/lib/diff/Diff.php:586

Typical plugins we'll want to use:

https://doc.tiki.org/PluginInclude
https://doc.tiki.org/PluginTracker
https://doc.tiki.org/PluginTrackerList

This would permit more parameters.

Ex.: make invisible

{CODE()}
{alias page=oldpagename visible=no}
{CODE}

There should be a conversion script so every time Tiki detects the old syntax, it converts to the new one.



Related: {wish id=wish2450}

plugin include does not work on Tiki18 as reliably as on Tiki15

start and stop parameters are not respected

-+start="~tc​~ includeon ~/tc~" stop="~ tc​~ includeoff ~/tc~"+-

Font Awesome (and maybe others?) supports rotating the icon, and some of the icon instances in Tiki are rotated (like the "sitemap" icon is used for Tiki's categories feature, rotated 270 degrees). So a PluginIcon parameter like ''rotate="270"'' would be a great addition.

If I want to update an image that's used in a wiki page, or for some other reason find an image in the file galleries when I only know its ID, as in "display290", it would be great to be able to find it by simply searching for the ID number or display code. This doesn't seem to be possible now.

I've been using for many semesters this workspace template (See below) which allowed me to create a bunch of pages, groups, category, and a few other objects. I've recently updated to 16.2svn , attempted to create the new workspace "2017a Spring" for this new semester based on this same template, and so far I saw that only the default group __Courses:_:2017a Spring__ was created and not the two subgroups "Courses:_:2017a Spring Faculty" and "Courses:_:2017a Spring Students".

So something is borked, and I presume that other parts of the workspace where not created properly (untested yet)



{CODE(caption="YAML")}
---
objects:
-
type: categorize
data:
type: wiki_page
object: $50f320f6d7ffe
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d7ffe
data:
name: $profilerequest:namespace$undefined$
namespace:
content:
-
type: categorize
data:
type: wiki_page
object: $50f320f6d822c
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d822c
data:
name: Sessions
namespace: $profilerequest:namespace$undefined$
content:
structure: 0
-
type: categorize
data:
type: wiki_page
object: $50f320f6d82c4
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d82c4
data:
name: Menu
namespace: $profilerequest:namespace$undefined$
content:
-
type: categorize
data:
type: wiki_page
object: $50f320f6d8383
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d8383
data:
name: Final Paper
namespace: $profilerequest:namespace$undefined$
content:
structure: 0
-
type: categorize
data:
type: wiki_page
object: $reffinalpapertemplate
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: reffinalpapertemplate
data:
name: Final Paper Template
namespace: $profilerequest:namespace$undefined$
content:
-
type: categorize
data:
type: forum
object: $forumref
categories:
- $profilerequest:category$undefined$
-
type: forum
ref: forumref
data:
name: Main forum
namespace: $profilerequest:namespace$undefined$
attachments: everyone
list: [ topic_reads ]
content:
mappings:
Base: $profilerequest:group$undefined$
Students: >
$profilerequest:group$undefined$
Students
Faculty: $profilerequest:group$undefined$ Faculty
permissions:
Base:
description: $profilerequest:group$undefined$
autojoin: y
objects:
-
type: category
id: $profilerequest:category$undefined$
allow:
- admin_categories
- add_object
- remove_object
- post_comments
- read_comments
- download_files
- upload_files
- view_file_gallery
- edit_gallery_file
- view_fgal_explorer
- view_fgal_path
- forum_edit_own_posts
- forum_post
- forum_post_topic
- forum_read
- forum_vote
- view_freetags
- freetags_tag
- unassign_freetags
- group_view
- group_view_members
- group_add_member
- group_remove_member
- perspective_view
- view_sheet
- view_sheet_history
- tracker_view_attachments
- tracker_view_comments
- create_tracker_items
- tracker_view_ratings
- tracker_vote_ratings
- tracker_revote_ratings
- view_trackers
- view
- edit
- wiki_view_history
- edit_structures
- rename
- rollback
- upload_picture
- wiki_view_comments
- wiki_view_source
- site_report
- modify_object_categories
-
type: group
id: Base
allow:
- group_view
- group_view_members
- group_add_member
- group_remove_member
-
type: group
id: Students
allow:
- group_view
- group_view_members
- group_add_member
- group_remove_member
-
type: group
id: Faculty
allow:
- group_view
- group_view_members
- group_add_member
- group_remove_member
Students:
description: >
$profilerequest:group$undefined$
Students
objects:
-
type: category
id: $profilerequest:category$undefined$
allow:
- admin_categories
- add_object
- remove_object
- post_comments
- read_comments
- edit_gallery_file
- forum_edit_own_posts
- forum_post
- forum_post_topic
- forum_read
- forum_vote
- view_freetags
- freetags_tag
- unassign_freetags
- edit_sheet
- view_sheet
- view_sheet_history
-
type: group
id: Base
allow:
- group_view
- group_view_members
-
type: group
id: Students
allow:
- group_view
- group_view_members
-
type: group
id: Faculty
allow:
- group_view
- group_view_members
Faculty:
description: $profilerequest:group$undefined$ Faculty
autojoin: y
objects:
-
type: category
id: $profilerequest:category$undefined$
allow:
- admin_categories
- view_category
- add_object
- remove_object
- assign_perm_category
- post_comments
- read_comments
- admin_comments
- edit_comments
- remove_comments
- dsn_query
- admin_file_galleries
- assign_perm_file_gallery
- batch_upload_files
- create_file_galleries
- edit_gallery_file
- remove_files
- admin_forum
- forum_attach
- forum_autoapp
- forum_edit_own_posts
- forum_post
- forum_post_topic
- forum_read
- forums_report
- forum_vote
- view_freetags
- admin_freetags
- freetags_tag
- unassign_freetags
- broadcast
- perspective_edit
- perspective_admin
- admin_sheet
- edit_sheet
- view_sheet
- view_sheet_history
- admin_trackers
- attach_trackers
- tracker_view_attachments
- comment_tracker_items
- modify_tracker_items
- modify_tracker_items_pending
- modify_tracker_items_closed
- remove_tracker_items
- remove_tracker_items_pending
- remove_tracker_items_closed
- tracker_view_ratings
- view_trackers_closed
- view_trackers_pending
- watch_trackers
- export_tracker
- admin_wiki
- assign_perm_wiki_page
- lock
- remove
- use_as_template
- wiki_view_ref
- wiki_admin_attachments
- wiki_attach_files
- wiki_view_attachments
- workspace_instantiate
-
type: group
id: Base
allow:
- group_view
- group_view_members
-
type: group
id: Students
allow:
- group_view
- group_view_members
-
type: group
id: Faculty
allow:
- group_view
- group_view_members

{CODE}

1/ Wrong calculation

There is some issue with the the filtering on status (open, pending, close) and the item count.

The average is calculated on the TOTAL of the item in the tracker and not on the total of the item displayed and thats wrong.

Fixed : https://sourceforge.net/p/tikiwiki/code/61412/

2/ Item list fields are not displayed properly.

See instance.

Hi all,
i've just installed Tiki and i'm experimenting with multi configurations (at the moment on my Windows pc).
I've seen there is a problem in caching the templates compilations.

In lib/init/smarty.php there is:
{CODE(theme="default")}$this->setCompileDir(TIKI_PATH . "/temp/templates_c");{CODE}
while instead in multi configuration it should be "/temp/templates_c/$tikidomain"

Infact in tiki-admin_system.php there is:
{CODE(theme="default")}$templates_c = $cachelib->count_cache_files("temp/templates_c/$tikidomain");{CODE}

This means that in "System Administration/Clear Cache Content" panel, the cache content is always shown as 0 and files cached by smarty compilations in "/temp/templates_c" cannot be deleted from that panel and must be cleared manually.

Regards,
Gabriele

When using WYSIWYG in HTML mode (wysiwyg_htmltowiki disabled), the WYSIWYG help available by clicking the blue question mark at the right assumes that the wysiwyg_wiki_parsed preference is enabled:
# The first tab claims that "Wiki plugins can be used and edited in WYSIWYG mode" since r30245.
# The second tab offers adding plugin calls, as if they would be interpreted.

In fact, it is known that the implementation "is not designed to work best" when wysiwyg_wiki_parsed is disabled (even though [https://tiki.org/tiki-view_forum_thread.php?comments_parentId=67421|the idea behind wysiwyg_wiki_parsed is unrelated to WYSIWYG]). The first tab contains:
{QUOTE()}
This new implementation is designed to work best with some site preferences set in a certain way. These can all be found on the WYSIWYG admin page. A profile to set these up correctly can be found on profiles.tiki.org which can be applied using the profiles admin page.
{QUOTE}
The WYSIWYG_6x profile enables wysiwyg_wiki_parsed.

When I create a WYSIWYG table using the editor WYSIWYG table editor is create a code like this is one and single row:

{CODE()}||table|a|b %%% 1| |  %%% 2| | ||{CODE}
Carriage returns are turned into wiki syntax and therefor it break the table

It should have been:
{CODE()}||table|a|b
1| | 
2| | ||{CODE}

Importing of a XML zip fails.

Attached is an XML zip created on 12.x

This is a php7 issue. It works fine with php 5.x

PHP Error: PHP Parse error: syntax error, unexpected 'new' (T_NEW) in /Sites/tiki/vendor_extra/pear/XML_Parser/Parser.php on line 611

Tiki show instance not useful as its hosted on php 5.x

I have a xml.zip attached for trial reasons, but it does not matter what is being imported, it all fails.

On module creation :
( ! ) Fatal error: Class 'convertToTiki9' not found in /Users/Bernard/Documents/Shocksite/www/htdocs/retroRGB/lib/modules/modlib.php on line 76

The module is created.

__Setup:__ tiki 17.1 on Linux, nginx, mysql, php 5.6
I have standard text editor and default file gallery stuff..

Short story: I cannot put images into blog post via "Choose or upload images" button. The files are being downloaded instead of inserted into opened blog post.
It is something regarding __SEF URL__ feature.. when I enable it .. the bug is being triggered.. when I disable it it works as before.

The other strange thing is that I cannot edit already inserted images via double clicking.

__Steps to reproduce:__
1, open blog post
2, click "Choose or upload images" - three squares behind each other icon
3, Upload screen is opened in another window
4, click Browse Galleries
5, choose gallery and hover on the particular image
6, popup with thumbnail of image and caption "Download" shows
7, after clicking the image starts downloading via browser

This is the screenshot showing that it will download instead insert:
{img fileId="1143" thumb="box"}

This is the failed-to-construct edit image dialogue:
{img fileId="1144" thumb="box"}

__What I was doing:__
Enabling SEF URL..
Fiddling with some settings, not sure if related - user settings, permissions, batch directory, disabled image gallery etc.
I tried Batch directory in File Galleries, it worked via syncthing.. then I processed the files.. probably it caused the thing..
Moved files from database to directory.

__Show tiki instance:__
I was not able to demonstrate bug so far (I have SEF URL set)

Password for admin: 12345 .. test/test123 set/set123 if anybody is interested in playing with that.

Wiki Page properties "Show Page Title" Off

When choosing to turn off page titles on a per page basis by page properties and toggling Show Page Title to Off, this action has no effect on the wiki page title, the title still displays.

Using the following code in a Wiki Parsed module

{CODE(caption=>example module code)}
{if isset($objectCategoryIds) and in_array(42, $objectCategoryIds)}
In category
{/if}
{CODE}

should show the text "In Category" when the wiki page currently shown in the center column is in the category with id 42.
--This works only on pages without spaces in their names.-- Things seem to have changed. This works with pages that have spaces in their name, but not if the spaces are being replaced by dashes.

The above code should also work when on a wiki page with spaces in it's name.

Tiki smileys are so 90s... It look very bad.

:)
;)
(:santa:)
(:twisted:)

Really ?

--drsassafras begin--
This seems related to : https://dev.tiki.org/item6191 and https://dev.tiki.org/item6189

I looked into the issue not so long ago. Almost all browsers now support emoji. Desktop and mobile. If we enable the saving of emoji in our database, they will all show nicely, and will always be kept up to date with the OS/Browser.

A little emoji selector could be made for users who dont have a emoji keyboard set up, and the existing similes used here could be integrated.

Although, it might be easier to replace the emoticons with new ones in the mean time.
--drsassafras end--

Hi, I just want to get a fresh pre-17 trunk show instance to have a look wether and how the H5P integration proceeds and how to use.
{sign user="Torsten" datetime="2017-03-13T23:15:30+00:00"}

chosen lib prevents changing the sorted order display of fields from an items-list tracker field with the translation smarty system

Workaround: disable chosen lib temporarily, make your changes to the selection of fields to be displayed, and/or the sort order, save (and reindex if necessary), and you can enable chosen lib again later on.
At least this worked for me so far.

Reproduced in trunk and 16.x:

Inability to post a comment-Issue (due to highlighter)
Reproduced in trunk in:
* Login as admin in http://xavi-9794-3214.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=5
u: admin
p: 12345

And in 16.x in:
http://xavi-9794-6132.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=5
u: admin
p: 12345

It's currently also affecting https://dev.tiki.org bug tracker comments. {sign user="xavi" datetime="2016-10-14T10:17:35+00:00"}

When codemirror highlighter is on (desired behavior in some setups, and the one produced by the new profile "Bug_Tracker_15" by default) when you click at submit your comment, you get: "__content is empty__", so you need to disable the highlighting before you can safely submit your comment.

This feature works as expected in Tiki15.

Configuration Wizard, setting not applied (WYSIWYG) on the HomePage, the very first page Admin will land and will want to change.

Tested on new install of Tiki15.x, 16.x and trunk.

Step to reproduce:
Install Tiki : tiki-install.php.
At the end of the install go to Configuration Wizard to Select Editor type.
Enable WYSIWYG => save and continue.

The Wysiwyg editor screen show:

Compatible Wiki mode Use wiki syntax for saved pages.
This is the most compatible with Tiki functionality and the most stable editor mode.
Tools and functions in the editor toolbar will be limited.

Full WYSIWYG editor is displayed by default : enable
__So all is set and the wizard tells you that WYSIWYG will be used by default on the Wiki page.__

Exit the wizard, edit the HomePage.
It is not WYSIWYG but Wiki syntax. The HomePage is created by the install process and an extra step is missing in the wizard (it should change the HomePage editor to WYSIWYG).