Category: 16.x

PluginConvene UI doesn't allow editing date choices for a user anymore

Reproduced here:
https://tiki.org/Roundtable+Meeting+2016+11

Add a user, and then, attempt to edit the user choices: the dropdowns to choose from the options for each date are not shown, but same page is reloaded, with a very long url, etc.

PluginChart doesn't produce the expected chart, just the legend

Try to reproduce the example at the documentation, and you'll get the issue reproduced, like in the https://doc.tiki.org/PluginChart

Strategic feature to get Spreadsheets and charts out of them in the game again.

^__Please note:__
This request is to have the png & jpg versions of the charts produced ( see: https://doc.tiki.org/Spreadsheet+Graphics+and+Charts#Select_the_Graphic_Type_and_Output_Format ), not some js based solution (like reusing raphaeljs or chartjs lib, etc.), since this implies an easy solution for charts in PDF reports working automagically without requiring complex solutions to get js-based charts incluided in PDF reports. A different request/wish will be added to add some optional parameter to get the chart produced with some JS lib already in Tiki like the ones cited above.
^

PluginFade shows nothing in 16.x. It works as expected in 15.x, and in trunk, a new param has been added (bootstrap=y) which allows the plugin to at least show up.

Workaround? backport that ENH of param to fix PluginFade so that at least there is a way to make it work in 16.x

I create a demo on the instance {sign user="Bsfez" datetime="2016-12-31T06:54:06+00:00"}

{CODE()}
{FONT(size="30")}This is OK
This is OK
This is OK
This is OK
{FONT}
{CODE}
will generate:
{FONT(size="30")}This is OK
This is OK
This is OK
This is OK
{FONT}

But

{CODE()}
{FONT(size="30")}This is OK
This is OK

This is not OK
This is not OK
{FONT}
{CODE}
will generate:
{FONT(size="30")}This is OK
This is OK

This is not OK
This is not OK
{FONT}

Wasn't that fixed already in 15.x+?

The preference "Force users to fill tracker information" in the tiki admin secton "login" broke a newly installed Tiki 16 (from svn) shortly after installation, at the moment of activation.

I just have had started the configuration. Trackers was not yet active, so not User Tracker aswell. I will activate Trackers and User Tracker prior to activate the preference in the show instance.

This is the error message I had after activation, representing a full WSOD for logged in admin
(Please mind: the anonymous user still could see the website):

{CODE()}
Fatal error: Call to a member function getUserField() on boolean in /www/htdocs/.../tiki/.../currentroot/lib/setup/tracker_force_fill.php on line 18
{CODE}

__Update:__
When I first setup Tacker and User Tracker in the show instance, the "Force users to fill tracker information" continuously forces users to again and again create a new tracker item, even when multiple exist.
Try now with autouser field.

__Update2:__
User field with auto assign helped, but Tracker is creating multiple items, when updating info. Obviously I forgot to set "only one tem per user"! ...

__Update3:__
It is NOT working correctly. When updating user data (in tracker) from the 'my Account' -> 'my info' -> 'Additional Information' tab, multiple Tracker items are created.

When using 'FANCYTABLE' and the user selects preview, the preview does not display it.

Code used:

{FANCYTABLE(head="Info/Config" sortable="type:reset;text:*****" sortList="[0,0]")}

a
y
z
{FANCYTABLE}

I updated a previously working 16.x trunk instance.

With preview/save/cancel buttons at top and button.
After editing a page
*The bottom save button saves the edit, but returns you to the edit page again.
*The top button saves the edit and returns you to the normal page as it should.

However, all properties are lost when saved.
*cannot turn on or off comments for the page
*Previously stored tags and description are cleared.

This profile, for instance, has some file defined in the file gallery that is created by the profile, and only the first is created through the profile, instead of the whole set as in the past (Tiki12), and the rest of the profile is not applied. If you remove the init_files then the whole profile is applied.
https://profiles.tiki.org/Easy+GeoBlog

These are the type of error messages (after many notices) shown in the shell when the profile is applied with
{CODE(colors="shell")}
php console.php d:i --force; php console.php p:a "Easy GeoBlog" > log_egb.txt 2>&1
{CODE}

{CODE(colors="shell")}
(...)
PHP Warning: preg_match() expects parameter 2 to be string, object given in /var/www/html/16.x/lib/filegals/filegallib.php on line 3932
PHP Stack trace:
PHP 1. {main}() /var/www/html/16.x/console.php:0
PHP 2. Symfony\Component\Console\Application->run() /var/www/html/16.x/console.php:184
PHP 3. Symfony\Component\Console\Application->doRun() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Application.php:126
PHP 4. Symfony\Component\Console\Application->doRunCommand() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Application.php:195
PHP 5. Symfony\Component\Console\Command\Command->run() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Application.php:874
PHP 6. Tiki\Command\ProfileInstallCommand->execute() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:253
PHP 7. Tiki_Profile_Installer->install() /var/www/html/16.x/lib/core/Tiki/Command/ProfileInstallCommand.php:67
PHP 8. Tiki_Profile_Installer->doInstall() /var/www/html/16.x/lib/core/Tiki/Profile/Installer.php:375
PHP 9. Tiki_Profile_InstallHandler->install() /var/www/html/16.x/lib/core/Tiki/Profile/Installer.php:450
PHP 10. Tiki_Profile_InstallHandler_FileGallery->_install() /var/www/html/16.x/lib/core/Tiki/Profile/InstallHandler.php:24
PHP 11. Tiki_Profile_InstallHandler_FileGallery->upload() /var/www/html/16.x/lib/core/Tiki/Profile/InstallHandler/FileGallery.php:159
PHP 12. FileGalLib->get_info_from_url() /var/www/html/16.x/lib/core/Tiki/Profile/InstallHandler/FileGallery.php:173
PHP 13. FileGalLib->get_info_from_http() /var/www/html/16.x/lib/filegals/filegallib.php:3889
PHP 14. preg_match() /var/www/html/16.x/lib/filegals/filegallib.php:3932
PHP Catchable fatal error: Object of class Zend\Http\Header\Etag could not be converted to string in /var/www/html/16.x/lib/core/TikiDb/Pdo.php on line 77
PHP Stack trace:
PHP 1. {main}() /var/www/html/16.x/console.php:0
PHP 2. Symfony\Component\Console\Application->run() /var/www/html/16.x/console.php:184
PHP 3. Symfony\Component\Console\Application->doRun() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Application.php:126
PHP 4. Symfony\Component\Console\Application->doRunCommand() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Application.php:195
PHP 5. Symfony\Component\Console\Command\Command->run() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Application.php:874
PHP 6. Tiki\Command\ProfileInstallCommand->execute() /var/www/html/16.x/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:253
PHP 7. Tiki_Profile_Installer->install() /var/www/html/16.x/lib/core/Tiki/Command/ProfileInstallCommand.php:67
PHP 8. Tiki_Profile_Installer->doInstall() /var/www/html/16.x/lib/core/Tiki/Profile/Installer.php:375
PHP 9. Tiki_Profile_InstallHandler->install() /var/www/html/16.x/lib/core/Tiki/Profile/Installer.php:450
PHP 10. Tiki_Profile_InstallHandler_FileGallery->_install() /var/www/html/16.x/lib/core/Tiki/Profile/InstallHandler.php:24
PHP 11. Tiki_Profile_InstallHandler_FileGallery->upload() /var/www/html/16.x/lib/core/Tiki/Profile/InstallHandler/FileGallery.php:159
PHP 12. FileGalLib->attach_file_source() /var/www/html/16.x/lib/core/Tiki/Profile/InstallHandler/FileGallery.php:185
PHP 13. AttributeLib->set_attribute() /var/www/html/16.x/lib/filegals/filegallib.php:3983
PHP 14. TikiDb_Table->insertOrUpdate() /var/www/html/16.x/lib/attributes/attributelib.php:89
PHP 15. TikiDb->queryException() /var/www/html/16.x/lib/core/TikiDb/Table.php:56
PHP 16. TikiDb_Pdo->query() /var/www/html/16.x/lib/core/TikiDb.php:72
PHP 17. TikiDb_Pdo->_query() /var/www/html/16.x/lib/core/TikiDb/Pdo.php:118
PHP 18. PDOStatement->execute() /var/www/html/16.x/lib/core/TikiDb/Pdo.php:77
{CODE}

By the way, In Tiki15, not a single file is added to the file gallery.

When applying profile some profiles have possibility to input custom user value(s), for example:
{CODE()}name: $profilerequest:User Tracker Name$User Tracker${CODE}
It displays a text input field before applying profile with label User Tracker Name and prefilled value "User Tracker".
If user tries to change that e.g. to "My User Tracker" instead, after applying the profile the user value gets ignored and uses the pre-defined one "User Tracker" anyway.

This used to work in the past Tiki versions I am pretty sure.

To replicate try searching for [https://profiles.tiki.org/User_Tracker|User Tracker] profile on the -+tiki-admin.php?page=profiles+- and before applying the profile change some value in the fields.

Provide a tablesorter-powered list of profiles in the Profiles Wizard bundled in Tiki to filter on features, tags, names and such

((doc:Profiles Wizard)) has many profiles, and sometimes the admin wants to filter those by feature name that they have enabled, or by tags (demo, learning, advanced, etc).

I don't know yet how to do that at the profiles wizard itself (first screen of that wizard? or second, just after the featured? ....)
There seem to be nice and advanced ways to display the whole list but allowing clever filtering, as seen here:
https://doc.tiki.org/TableSorter

---
Work started to have ((doc:tags)) added to the profiles in profiles.t.o, so that they can be searched/filtered by the features used in them, etc.

provide some button for users to save their choices (or cancel) other than the edit button they clicked on to display the options to choose from to make it more consistent with the rest of tiki

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

When using quick perms leaving a group on "advanced" perms setting removes all permission for that group, instead of leaving them as they are.

Not good :(

Google ReCaptcha is displayed in english only.
This is wrong, it should use the selected language by the page (tiki) and be displayed in the corresponding language.

https://developers.google.com/recaptcha/docs/language

You can test and check at : http://bsfez-11581-6186.show.tikiwiki.org/tiki-register.php
Change the language, the recaptcha stays in english.

Quick sensation in a production site of mine:

A new page in a wiki structure doesn't inherit categ perms from structure parent but only object perms (unexpected for intranet type of sections of wiki structures)

It does inherit permissions from the parent when local permissions are applied to the parent wiki page. However, in my opinion, category permissions (when there are no object permissions but category permissions) should be either applied by default to the new child page from the parent in the structure, or at least offer/warn the user about it with a checkbox for the user to select to copy categ. permissions also.

Regression: 'Users accept internal messages by default' is not applied to new users, therefore, no one can write them internal messages until they go there to allow that one by one. This is not the expected behavior in places like education, where plenty of students are created each semester, but there is not an easy way to preset that you can write to them (or among themselves) by default with nor further tweaking their preferences one by one.

Current behavior:
When searching for a term and selecting a language (for example German (DE)) the search results will highlight the searched languages letters (in our example "DE") as well.

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

Expected behavior:
The search results only highlight the searched term and not the chosen language as well.

Step to reproduce:
Search any term in using the search module and the language filters.

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

Possible workaround:
Disable the whole highlighting using CSS.

Selecting a new wiki homepage "Courses:_:Foo" got understood as "Courses" as the new wiki homepage.

I'm using :-: as the default namespace separator for workspaces.

This was working as expected in Tiki12.
---
Reproduced here:
http://xavi-9794-6103.show.tikiwiki.org/tiki-admin.php?page=wiki
u: admin
p: 12345

page selected as homepage was:
Course_Template:_:2016 Fall:_:Course Outline

but it was stored as:
Course_Template

In addition, there are some other oddities with workspaces in 15.x, but that is another story (to be reported aside elsewhere)

This profile https://profiles.tiki.org/Bug_Tracker_15 makes an attempt to allow the user to set the sender_email if they haven't done so yet (which is usually the case when we are creating new show.t.o instances, or reproducing some scenario in localhost to debug some feature, etc.)

I'm using the same type of syntax which seems to be working in other profiles:
But this one in Bug_Tracker_15 profile seems not to work:
{CODE()}
sender_email: $profilerequest:sender_email$YourEmail@example.com$
{CODE}

while these other ones, in [https://profiles.tiki.org/Easy+GeoBlog|Easy GeoBlog], for instance, work as expected:
{CODE()}
style: $profilerequest:style$gradiant.css$
sitetitle: $profilerequest:sitetitle$My Easy GeoBlog$
sitesubtitle: $profilerequest:sitesubtitle$My thoughts and musings$
browsertitle: $profilerequest:browsertitle$Easy GeoBlog$
{CODE}

I tried if the issue was adding an "@" character in the working fields of Easy Geoblog, but that worked as expected also even if an email was written there.

So, i am encountering this error while running setup.sh on Bluehost shared environment.

PHP 5.2, 5.4 & 5.6 are installed and available for my use.

Currently PHP Version 5.6.17 is the default php version (confirmed with phpinfo), which has been set by an apache set-handler in the .htaccess.

After many attempts to modify setup.sh, I managed to by pass the warning by manually changing the php calls to php56s (my local php5.6). Now I get a error with composer saying that it should be run with the command line version of php. This has clearly gone past my expertise. Help please!

I have set this as a bug as I have met the requirements outlined and have followed the documentation here: https://dev.tiki.org/Get+code

I have solved the issue on bluest shared environments. I wrote a little tutorial on how to fix it located on the [https://tiki.org/Bluehost|Bluehost page].

I updated the ((Get code|Get code)) page, so if one reads and follows the whole, thing, it will eventually lead to the Bluehost page.

showlinks=n param in plugin trackerlist does not prevent link from isMain field from showing

Wasn't that the expected behavior from that param?
At least, that what some users expect from its name and documentation.

http://doc.tiki.org/PluginTrackerList

"Show links to each tracker item (not shown by default). At least one field needs to be set as Public in order for this to work."

Or is the expected output of that param something different?

[https://sourceforge.net/p/tikiwiki/code/34340/|This change] was made because IE7 & IE8 has trouble with a page which starts with "<!-- TPL:". However, for a new developer, it's useful to know about tiki.tpl and error.tpl

Suggested layout:

{CODE()}<!DOCTYPE html> <!-- TPL: tiki.tpl is used as the global page container -->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<!-- TPL: header.tpl --><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />{CODE}


{CODE()}<!DOCTYPE html> <!-- TPL: error.tpl is used as the global page container -->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<!-- TPL: header.tpl --><meta http-equiv="Content-Type" content="text/html; charset=utf-8" />{CODE}

At https://doc.tiki.org/PluginToc#Only_second_level_and_sorted_from_A_to_Z it show:

__D__ocumentation Lifecycle
__F__eature Page Template
__d__elete
__e__rrors
help
in progress
merge
...

It should be ordered from A to Z
(OR some importance is given to CAPS vs notCAPS ?)

~~#F00:__EDIT__~~ : I created an instance to reproduce and I couldn’t so it may be something with Tiki.org
http://bsfez-11581-6285.show.tikiwiki.org

Spreadsheets (jquery --s5-- sheets) do not work as expected in a productive environment, even not for use in an internal team.
This is a regression, as they have been working before.

Issue: __The edit menu and it's subitems had no effect (Edit | View | Style).__

--Before considering it a bug I want to test here with a show instance.--
__Tested. Fix needed.__

[http://torsten-11143-6133.show.tikiwiki.org/tiki-view_sheets.php?sheetId=1&parse=edit|try here (show/show => admin/12345)]

Regards,
Torsten

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