Category: 16.x

Tiki Wiki CMS Groupware v16.0svn (SVN) "Situla"
Last update from SVN (16.0svn): Monday 31 October 2016 12:39:28 GMT-0100- REV 60095

Users register to the site autonomously.
Registration is set to validation by Administrator.
Member of group Admins cannot validate the users - neither by the validation link in the notification email, nor by logging in and trying manual validation on-site.

So no new users possible at this site with registation moderation.
This is a crucial bug.

Update 6 Nov 2016: it was reportedt, that 'creation of users' is broken at all in current Tiki16.

I meant to ask if anyone has a clue what this could be caused by? I don't see anything in the console which baffles me. The regCapsLock error that Brendan mentions below might be a false lead - when I add tracker fields to the registration it works but that error is there too, so it may be unrelated.

In Tiki 16, there is a problem where user cannot register. After clicking "Register", the use sees "Saving..." spinner forever.

I can confirm the problem disappears if you add user tracker fields to the registration. i.e. the problem only occurs on the basic registration setup.

See below for more information.




On 06.11.2016 16:36, Brendan Ferguson wrote:
Ive confirmed its a JS error. When I disable javascript with NoScript, it works fine.

Brendan



On Nov 6, 2016, at 10:29 AM, Nelson Ko <nelson@citadelrock.com> wrote:

I finally managed to roll back to r60095 but it doesn't help. Which is bizarre since I can register on tiki.org. The registration form on tiki.org is more than the default one though (has tracker info). So maybe it has something to do with that but that is just a guess. So anyway if someone else has time to troubleshoot it will be great - I will have to check back later.

On Sun, Nov 6, 2016 at 10:20 AM, Brendan Ferguson <drsassafras@gmail.com> wrote:
Ive got a console error here.

ReferenceError: event is not defined

regCapsLock(event);

Its not my area of expertise.

Ive verified that user creation through the admin panel is unaffected.

Brendan

I've confirmed that there is no user creation in the database when this error occurres. It's what one would expect with this kind of error, but it's good to make sure :)
Dr Sassafras

Twice now, I have thought there was a Tiki bug because TableSorter decided to hide stuff.

Idea: have a little + where columns are hidden

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

Wiki pages can have pseudo-buttons, some of which allow to perform actions. For example, a link may allow editing the page. These icons are displayed at the top of the central column, aligned right. In Tiki 12, this region has a height of 19 pixels.

Starting in Tiki 13, this region no longer contains actual images by default, but rather glyphs, which increases the basic height to 20 or 21 pixels. Most importantly, a vertical padding of 12 to 16 pixels (6 px top and 6 px down for Fivealive, 8+8 in Journal) defined for .btn is added. In the end, the region's height is now between 34 and 40 pixels, which makes it more clear than before version 13 that this region uses the full column width, pushing all Wiki content by 34 to 40 pixels down.

This is of course highly inefficient, and IMO ugly. Since multilingual wikis have a language choice widget, this region can show even for unprivileged visitors.

This persists in trunk as of r60089.

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~"+-

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.

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.

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

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.

The front end comment options Reply, Edit, Delete, Archive disappear when clicked on and do not bring any menus up or carry out the actions they are meant to. (The rating option however still works ok).

This is happening when I am logged in as an Admin clicking on the comment options for Anonymous users. (I can use the Reply, Edit, Delete, Archive options on my own comments ok).

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

Actually to have the plugin listExecute action initiate by a cron job you have to use curl, send user (admin) credentials and use http(s) authentification which is not very safe.

{CODE()}curl -u admin:adminpassword "http://yourtiki.com/YourActionPage" --form "list_action=ActionName" --form "objects~0=ALL" {CODE}

It would be nice to to have a console task being able to execute listexecute actions on a particular page avoiding unsafe communications.

Convene plugin missplaces the counts in columns after the winning choice. See it reproduced in the screenshot below:

{img fileId="1093" thumb="box" width="600"}

In
https://tiki.org/Roundtable+Meeting+2016+09

After the count with the more votes (7, at the time of this writing), and the icon with the checkbox-like icon to indicate that this was the winning choice (Thu 15 Sep 2016 15:00 CEST), there is a button box in orange in the screenshot that should show a calendar icon, and that button allows to send that date to the pre-defined tiki calendar.
https://tiki.org/tiki-calendar_edit_item.php?todate=1473944400&calendarId=7

But no calendar icon is shown, and the count of votes for the next date (column in the table) is shown there instead ("3" instead of the calendar icon), and the next counts are also one column before where they should be.

It seems like for every added user it duplicates the votes entries in the plugin body.

It works when the duplicates are manually deleted from there so presumably the duplication is unnecessary and unwanted.

See:
https://tiki.org/tiki-pagehistory.php?page=Roundtable%20Meeting%202016%2009&compare=1&oldver=23&newver=24

Same thing is happening still with tiki 20.x on t.o. Reproduced these weeks here:
https://tiki.org/201909-TAG-Meeting?latest=1&amp;page_ref_id=1318

I just edited this morning a couple of options in my choices, through the convene UI, and the edition added itself in the background a clone of the plugin body several times {sign user="xavi" datetime="2019-08-28T13:35:45+00:00"}:
https://tiki.org/tiki-pagehistory.php?page=201909+TAG+Meeting&newver=45&oldver=44

convene plugin: prevent the user to add default info (Add or Add user string) instead of the real username or a different string

See it reproduced here:
https://tiki.org/Roundtable+Meeting+2016+09

I just made a fresh installation on a shared hosting service (all-inkl.com) via svn and did not get the Tiki running after successfull installation.

The installation was made in a PHP7 document root.

Two problems:

1. Site never stopped loading
2. Dropdowns) did not work (all dropdowns like login, quickadmin, etc) and added a # hashtag to the url in the address bar of the browser.

After a while (minutes) the site mentioned some JavaScript error in a popup error message.

I did change the PHP to PHP5.6 and then after a few minutes the site worked as fine as expected.
There seems to be some coherence with the PHP version.

Is that maybe related with Xavi's [https://dev.tiki.org/item6035|Bug 6035] ?
Torsten

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

In 1.10 now we can set to login as e-mail and display realname wherever possible. But the user wiki page by default is set to 'UserCreate<e-mail>. We should still allow user to create his page with 'UserCreate<username/real name>'.

The recommended behaviour should be if user chooses e-mail to be private or it could be if admin sets to disaply realname wherever possible, then it should use 'UserCreate<realname>' other cases it can be based on e-mail.

If you are using user tracker information, when you delete a user there is a new feature that ask you if you want to delete the user items in trackers and it displays a list of trackers.

"Delete user items from these trackers Warning: Experimental "

It shows the tracker used to store the user information giving the "wrong" impression that you are able to control if the user information will be deleted or saved.

The text is a bit confusing but no matter if you select a tracker or you don’t select it, user item in the tracker used to store the user information will be deleted.

Admin should be able to deactivate this option and it should not be set by default (erasing data cannot be default) as they are case you want to delete users but not the item created at their registration as it can lead to disrupt data cohesion on different area of your website (especially if you use on trackers and other created items relies on the user information data).

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

For example for [https://suite.tiki.org/tiki-pagehistory.php?page=Tiki%20Suite%20alternatives&compare=1&oldver=84&newver=85|this diff] change in the e-mail notification there is this empty HTML plugin shown instead of showing its content:

{CODE()}
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -Lines: 143-146 changed to +Lines: 143-150 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!!!! Freedombone
{HTML()}{HTML}
+
+ !!!! Cloudron
+ {HTML()}{HTML}
+

!! Services
{CODE}

display a single chart with plugin sheet fails (with mode simple=y or n)

Related to this other bug report:
https://dev.tiki.org/item6265 - "Page with many PluginSheet calls should respect their own uses of parameter 'simple=y/n' "

After bug6265 is fixed, you now display only the sheet which were displaying charts normally, but when shown in mode "simple=y" charts are not shown.

Well, in fact, chart is not shown even if simple=n.

How complicated is it to get the charts shown?
See:
* http://xavi-9794-6265.show.tikiwiki.org/tiki-index.php?page=Spreadsheet-demo-instructions#Show_Only_Charts
* http://xavi-9794-6265.show.tikiwiki.org/tiki-index.php?page=Spreadsheet-demo-instructions#Display_only_One_Chart
u: admin
p:12345

Thanks!

In the toc we can set maxdepth (how many sub-level) we wan to display.
However there are case you need only sub-level to be displayed.

A structure ''Europe'' with several children (''France'', ''England'', etc) that have them self (''Paris'', ''London'', etc) children.

''Europe'' (top level)
-> ''France'' (sub-level 1)
-> ''Paris'' (sub-level 2)
-> ''England'' (sub-level 1)
-> ''London'' (sub-level 2)

Using the wikiplugin_toc we want to show all the second child (sub-level 2) for all the structure Europe and not any of the level above it.

The toc will show:
Paris (level 2)
London (level 2)