Category: 17.x Regression

'Show creation (or modification) date when viewing items' shows nothing any more when tracker section format is set to Tabs

I have setup a forum for a freshly upgraded Tiki pre-17 trunk :
''( Last Update from SVN (17.0svn): Wednesday, 22 March 2017, 19:03:57 CET- REV 61822 )''
Then I added an eMail to send to from the forum to the email address, what works.

After that I added another email - a pop account - and saved and then the forum is not accessible in view mode anymore: my.example.com/forum5 shows a WSOD white screen.
Deleting the mail account, the forum works fine again.

As we are using this feature on tiki.org heavily and other users might also, I consider this a a 'Release Blocker'.

#

tiki-admin.php?page=textarea#contentadmin_textarea-2 had its main section (Plugins) changed in r61597. It mostly works now, but there is still a problem when searching for short terms, i.e. those under [https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_ft_min_word_len|ft_min_word_len] (for MyISAM; the limit for InnoDB tables is controlled by a different variable).

If the query contains nothing but terms under the limit, all plugins are displayed. If the query contains at least one sufficiently long term, the too short terms are ignored.

One solution would be to display a warning about short terms next to "Plugins found containing: foo".

I am however wondering if we couldn't just go back to the previous code, which didn't have this problem (adapted to not show all plugins by default?). I guess one important reason for the change was to speed up page load, but page generation takes about 7 seconds here, which appears to be the same as, for example, Admin Profiles, so the gain is not obvious.

Trying to revert the change causes important conflicts.

Related: issue 6307

tiki-admin.php?page=textarea#contentadmin_textarea-2 is failing to show several plugins since r61597. For example, the SNARF plugin won't show if using search terms "content" or "snarf".

Since r61597, the full list of plugins is no longer displayed. One needs to write a search term or press Enter to have everything.

I tried reverting the change, but this causes a significant conflict.

After upgrade from tiki 16 to trunk, index rebuild fails.

{CODE()}php console.php index:rebuild
PHP Notice: Undefined index: pass_chr_num in /var/www/trunk/lib/user/blacklistlib.php on line 51
Started rebuilding index...



[TikiDb_Exception]
Specified key was too long; max key length is 1000 bytes{CODE}

The anchor link on title (h1, h2, h3) are now always displayed even if I don’t mouseover.

Pretty ugly :)

{img type="fileId" fileId="1134" thumb="box"}

I didn’t see that on dev... Only on instance for 17.x is a weird situation...

It is not possible to use tiki-batch_upload_files.php to sent file into a file gallery (directory storage).
The process seems to run but no files are uploaded (and removed).

I found a workaround, check any of the checkbox at the bottom :
*Upload into galleries according to sub-directories
*Use the last sub directory name as description

And it work (even when there is no subdirectory)

At the community site, just updated to Tiki 17, on https://tiki.org/Tiki%2Bvs%2BXWiki , the heading anchor icons work properly in Firefox (they are the correct size and display on hover), but they don't in Chrome or Vivaldi (they're too large and always display). (Both of these browsers, along with Opera, use the Blink rendering engine.)

When I preview a blog post at themes.tiki.org, which is now at version 17.0, instead of the blog post title displaying, the text "No object information provided." displays.

This isn't a big problem as a practical matter since I don't really need to see a preview of the post title, but it would give a blog author the impression that something is broken in the preview function.

The browser tab favicon settings are missing. They used to be in tiki-admin.php?page=look under "Miscellaneous".
And once a path was assigned, a choice had to be made what type of file is your favicon, such .ico, .png etc.

At this point, a browser tab favicon cannot be chosen through admin/look and feel.
Please see screen shot of what it used to look like at the admin/look and feel/miscellaneous
{img fileId="1125" thumb="box"}

I did several upgrade lately from Tiki 15.x, Tiki16.x, Trunk, 15.4 package, 16.2 package and today’s daily from 16.3.

Somewhere near 15.4 release something was broken and the browsertitle pref is empty instead of showing previous data at tiki-install.php / Configure General Settings.

Example of url generated through the Profiles Wizard:
http://xavi-9794-6372.show.tikiwiki.org/tiki-admin.php?profile=Bug_Tracker_16&show_details_for=Bug_Tracker_16&categories%5B%5D=17.x&repository=http%3a%2f%2fprofiles.tiki.org%2fprofiles&page=profiles&preloadlist=y&list=List#step2

Example of equivalent profile applied through the Profiles Control panel:
http://xavi-9794-6372.show.tikiwiki.org/tiki-admin.php?ticket=4884aea2d5b951c86ed8b5fba540158a&daconfirm=y&profile=Bug_Tracker_16&repository=&page=profiles&redirect=0&list=Find

That show.t.o instance has:
u: admin
p: 12345

Through control panel there sems to be some __ticket__ param which is missing in the profiles wizard. Is this just the only thing which is missing?
---
UPDATE {sign user="xavi" datetime="2017-10-10T08:54:20+00:00"}
17.x svn ( -+Last update from SVN (17.2svn): Monday October 9, 2017 16:39:25 GMT-0200 - REV 64187 (MyISAM)+- ) is confirmed to suffer from this issue still. Please, pay attention to the fact that the button to apply the profile is shown, but when you click, the page reloads, and no profile is applied.
URL from profiles wizard is still like:
http://xavi-9794-6374.show.tikiwiki.org/tiki-admin.php?profile=Collaborative_Community_12x&show_details_for=Collaborative_Community_12x&categories%5B%5D=17.x&categories%5B%5D=Featured+profiles&repository=http%3a%2f%2fprofiles.tiki.org%2fprofiles&page=profiles&preloadlist=y&list=List#step2

u: admin
p: 12345
---

This is a regression from r((rev:61862)). The "$access->ticketMatch()" condition returns false, because the checkAuthenticity() method (called from tiki-admin.php) sets its property to false because a ticket is missing. And because the daconfirm request parameter is missing, the failure is silent.

__Pending re-test and backports to 18.x.__ {sign user="luci" datetime="2018-08-17T08:00:43+00:00"}

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.

Tried on 12, 15, 16 and 17 to create a plugin alias based on : https://doc.tiki.org/Plugin+Alias

Work only in 12x.

I created an instance.

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.

When trying to Upload Translations using a Custom Translations file I got the following (tested on Mac and Windows).

Error
Invalid file type (expected file type: php)

In my localhost trunk installations, I'm finding an extra period (.) appended to each footnote. This is true for pre-existing footnotes and newly added ones. I want to make a show instance to check trunk on another server.

Extra site logo (tiki logo) and sitetitle shown at the top left corner after upgrade to 16.2svn (a.navbar-brand)

Workaround?: hide it with custom css. See:
https://doc.tiki.org/Tiki16#Known_Issues

I presume that this is needed for the display of the site logo when in smartphones and tablets, etc. but it should only be shown in that case, not always, and not if the other site logo and site name (from the feature and the module logo) are shown already.

In corner cases, a footnote number in the footnote area will display alone on its line. The beginning of the note itself will go to the next line. There are 2 conditions needed for a footnote to be affected:
#it contains an HTML paragraph (<p>)
#it has a line long enough to wrap, as in the following:
{CODE(caption="Example" colors="tiki" theme="default")}Content{FOOTNOTE()}
Paragraph with at least one really long line which continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues, continues...
*Dummy item in a list which makes the preceding paragraph a real paragraph
{FOOTNOTE}
{footnotearea}
{CODE}

This was caused by a switch to parse_data_plugin() in r61394. That being said, the previous situation was already not ideal. The footnote number is inside the horizontal space occupied by the footnote itself (data), so there is no real distinction between the footnote number and some number which would be at the beginning of a footnote. I believe each footnote should be displayed using 2 rectangles with equal height. The content of a footnote should be in a rectangle to the right of a small rectangle containing only the footnote's number. This would match [https://en.wikipedia.org/wiki/Wikipedia#References|Wikipedia's behavior]. wikiplugin_footnotearea.tpl could be modified accordingly, but adopting the HTML used by Wikipedia would require us to change behavior a bit.

After upgrade from Tiki12, testing:
https://site.domain.com/ shows
^Error
No name indicated for wiki page^

I was expecting HomePage

The same upgrade from Tiki12 to Tiki15 does not have this issue.

I can access the normal HomePage through https://site.domain.com/tiki-index.php?page=HomePage

I look up in https://site.domain.com/tiki-admin.php?page=wiki and I do see
Wiki homepage: HomePage

As confirmed in CLI:
web# php console.php preferences:get wikiHomePage
Preference wikiHomePage has value HomePage

Note: option ''Group Homepages'' is active and Anonymous does not have one. In Tiki 15 and before, it would logically default to the ''wikiHomePage'' value, i.e. HomePage

I can't change a field of type "attachment" to any other kind of field.
No error message, no feedback. It just does not happen.
Rebuilding the index does not help.

I have set : Preference tracker change field type enabled (Preference name: tracker_change_field_type)

I can change the type of a field of type text, but not of type attachment :-(

This worked on Tiki16.x

Reproduced here:
http://stirus-11828-6082.show.tikiwiki.org/tiki-sheets.php
u: admin
p: 12345

I tried the following:

1-created a spreadsheet with two columns; row one had headings, row two data
* http://stirus-11828-6082.show.tikiwiki.org/tiki-view_sheets.php?sheetId=1
2-exported the spreadsheet in CSV format, UTF-8 character set
3-renamed the export file
4-edit the exported file with UltraEdit; changed one field; saved with UTF-8
5-created an empty spreadsheet
* http://stirus-11828-6082.show.tikiwiki.org/tiki-view_sheets.php?sheetId=2
6-ran import CSV with UTF-8
7-no data imported, and the sheet just says "Array".

We get {CODE()}Indexing failed while processing “5578” (type comment) with the error “analyzer [sortable] not found for field [sort]”{CODE} on this site.

Hmm, temporary issue? Seems gone after couple of seconds I filled this bug report.

Ah, nope, just replaced by "all shards failed" error while saving this bug report now.

Some options for tracker field Item Links are broken;

Multiple Fields display type : table is not working anymore a single check box is displayed without any text.

When setting Display to Link and Select multiple values to yes (Multiple Fields display type: dropdown - table is broken as explained above) no link is displayed only text.

Will create an instance as soon as instance are back online.

When a mandatory field like a title is multilingual if you fail to enter a value in all languages the form submits with a hidden error and fails to create the item or show why