Category: Bug

The User favorites feature (enabled by preference user_favorites and [https://doc.tiki.org/Favorites|documented]) allows users to define favorites, but does not let them view the favorites they have defined.

A controller similar tiki tiki-user_watches.php could be added so that users can actually use the feature.

Hi

When using the ~np~{maketoc}~/np~ plugin, an ampersand in a heading is rendered as "~np~&~/np~" in the generated table of contents, under certain circumstances.

This will exhibit the faulty behaviour:
~np~! Foo&Bar~/np~

Whereas this won't (notice the white space):
~np~! Foo & Bar~/np~

When choosing to "edit" an "Item Link" type tracker field, saving will always convert the Item Link type field to a "Relations" tracker field.

The reason for this can be seen - in the "Advanced" part of the edit popup, the only option in the "Field Type" dropdown is "Relations".

I realise that an Item link may just be a kind of relation in the "backend", however the interface for both configuring and using an item link is much better than the relations field, and any paramaters entered in to the item link do not trafer to the new "relations" field.

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

Tiki 18.01 running on Ubuntu 16.04 LTS

Getting errors when running composer install:
{CODE()} - Installing jcbrand/converse.js (v4.2.0): Loading from cache
- Applying patches for jcbrand/converse.js
../installer/composer-patches/jcbrand-conversejs_remove-native-javascript-for-bootstrap.patch (Remove native javascript for bootstrap)
Could not apply patch! Skipping. The error was: Cannot apply patch ../installer/composer-patches/jcbrand-conversejs_remove-native-javascript-for-bootstrap.patch
{CODE}

When you define workspace areas, there is no mechanism to delete them. They can be edited, but not deleted.

This can be viewed both as a bug report or a feature request:

The logic for article images breaks standard Tiki admin logic in that you cannot (!) use images from the file galleries. You have to upload them separately into where ever they get stored (unknown), stripping users of the ability to centralize image storage and scaling images by demand. This also means that the user must use a local image manipulation tool for scaling...

This is true for both standard images (by topic) and for user images!

{syntax type="tiki" editor="plain"}
As seen in the video attached to this item. (demo tiki)
The own image article is lost if the classification (topic or type) of an article is changed.

To reproduce;
In the Tiki Articles I create an article and set his own image.
I save, the image is displayed.

I edit the article change the topic or the type of the article and save.
The image is gone.
It was working fine, __this is a regression on Tiki 29__.

After the creation of an article, it can be observed that the number of readings of this article does not change, even when changing users or the access permissions of a user. The number always remains at __(0 Reads)__.
I was using Chrome Version 75.0 and Opera Version:60.0

When you create articles, e.g. with some news, you can format the text, the headline, and so on. You are presented some styling options, after all, like italic, bold, and so on.

But they don't work. Tiki displays the Wiki format commands as if they were regular text, it doesn't resolve (and execute) them!

Then there is a checkbox "allow full HTML". When you check that, you can at least throw in some bold and italic HTML tags. This works. In the preview... When you save that article, the checkbox magically resets to being unset. Even if done by admin...

Images are another shortcoming, you can upload your own. But you cannot use one from the file galleries?!? Yes, you can insert an image tag, and that does work. But it's the opposite of intuitional...

Thanks
hman

On article you can set the image, Own Image and you can set Read Article, Maximum dimensions of custom image in view mode, Width.

If this field had a value and you empty it and save you the article may display a random image.
This because reseting to an empty value broke the linkeage between the article and the previously uploaded image.

It is happening randomly (happened to me twice)

On next we have an article; https://next.tiki.org/article497-Biggest-Tiki-Release-Ever-Tiki-25
''To be sure I can see what is happening with the maximum width available I disabled fixed width''

As you can see on the video, the image displayed width is 555px. (fixed with disabled + 27inch screen)

On article settings (https://next.tiki.org/tiki-edit_article.php?articleId=497#content-edit_article1-4), Read Article: Maximum dimensions of custom image in view mode, Width = 720px.
Visibly (fill-width with a very wide scree) this is not applied.

Demonstrated on next.t.o
{mediaplayer src="display2131"}

When you sort a listing of articles, you can have the results sorted on the size of the articles. But the result is illogical, which is more visible when sorting descending, but in principle ascending is affected as well: The sorting is done NOT numerical (which you would expect on a numerical value like size), but by string representation.

The result is e.g. that "456 bytes" is being considered larger than "1.2 kBytes"...

If you go to articles home, and have your articles listed, you can have the list sorted by clicking on the column header. By clicking that again, you can change sorting direction (ascending/descending).

This doesn't work with the ID of articles. They are always listed ascending. However, the small arrow indicating the order DOES change to descending, but the listing isn't altered at all.

I have trackers with the field "Category" and a list of categories for the tracker to be assigned to upon item creation. The item never makes it into the category chosen.
A show instance will be created.

On a field of type ''text'' with options ''multilingual'' and ''autocomplete'', the autocomplete displays the json array of the field which has all languages instead of text strings.

Like: ~np~{"en":"3rd Test Event","fr":"3rd Evenement de Test "}~/np~

This bug is similar to {wish id=6703}, but about the FOOTNOTE plugin instead of SUP. As explained there:
{QUOTE(replyto="Chealer")}The auto-TOC implementation does not know how to deal with advanced titles. When titles contain plugin calls, since the links can't contain HTML, auto-TOC just strips HTML tags (see the declaration of ''aText'' in autoToc.js (''var aText = $.trim($this.text());''), which may or may not give a valid result.{QUOTE}

For FOOTNOTE, this causes the footnote number to be displayed raw (not in superscript), and clicking on the number brings to the section, rather than to the footnote. For example, with the following heading:
~np~! Buggy{FOOTNOTE()}For now{FOOTNOTE} heading~/np~
...the TOC entry would just display a raw "Buggy1 heading".

I believe it would be best to hide the number, as Microsoft Word 2013 does in TOC-s. Otherwise, it should be in superscript.

This bug (like #6703) is similar to its maketoc pseudo-equivalent: {wish id=4235}.

The auto-TOC implementation does not know how to deal with advanced titles. When titles contain plugin calls, since the links can't contain HTML, auto-TOC just strips HTML tags (see the declaration of aText in autoToc.js (var aText = $.trim($this.text());), which may or may not give a valid result. For example, with the following heading:
~np~! The mind behind e=mc{SUP()}2{SUP}~/np~
...the TOC entry would just display a raw "The mind behind e=mc2", with nothing in superscript, which - of course - is mathematically highly invalid.

This bug is similar to {wish id=6705}, but about the SUP plugin instead of FOOTNOTE.

In /lib/prefs/feature.php is a help string that does not work in English __and__ makes life of translators hard, because it is badly escaped (actually, not at all):
In line 550 you will find:

{CODE(Colors="Tiki")}
'feature_comments_send_author_name' => [
'name' => tra('Add author name in From email header'),
'description' => tra('Add the name of the comment author in the email header "From", making the email look like sent from "John Doe <noreply@example.com>"'),
'help' => 'Comments',
'type' => 'flag',
'default' => 'n',
'tags' => ['basic'],
],
{CODE}

The problem is the mock sender's mail address contained in braces. It IS the notation most mail clients use, real name and address in less than and greater than signs. But tra() seems to be unable to handle this. Possibly tra() interprets it as HTML entity (?) and discards it, so output of this description stops after John Doe. The address is omitted, as well as the closing quote sign.

And for translators this is hard, because if you add the string that is displayed to your custom.php, the pattern matching won't find it.

Hello everyone. Right now i am experiencing an issue while trying to upload a file using the the {FILES} plugin.

__What i did__
# I created a page and added the {FILES} plugin inside of it.

{CODE(wrap="1" theme="default")} {files galleryId="9" sort="name_desc" showtitle="n" showicon="y" showname="y" showfilename="n" showdescription="y" showmodified="n" showmodtimedate="n" showthumb="n" showupload="y" showaction="y" showid="n" showcreated="y"}{CODE}

# Then i added a simple .txt file by clicking the "browse.. " button.

# By click the "Upload" button i receive a blank page with url -+/tiki-upload_file.php+-


__tiki-syslog.php output__
# For my upload attempt i get this message
-+Request to /tiki-ajax_services.php failed CSRF check. Ticket does not match or is missing.+-

# When i try to enter into tiki-syslog.php i receive this log message
-+Request to /tiki-syslog.php failed CSRF check. Requesting site could not be identified because HTTP_ORIGIN and HTTP_REFERER were empty.+-

To be honest i don't know if those 2 messages are connected somehow

__Server Info__
* Release: Debian GNU/Linux 10 (buster)
* Database Version: 10.3.23-MariaDB-0+deb10u1
* PHP version: 7.3.19-1
*upload_max_filesize : 64M
*upload_tmp_dir: Unknown

No matter how often I visit the three blogs in my installation of 18.5, and no matter whether I do that as registered user, as admin or as anonymous and no matter how many blog entries I click:

All three visits counters are stuck at zero!

When the site layout is set to "Classic Bootstrap (fixed top navbar)", and a site's title and subtitle is given, then the those will be shown twice.


Screenshot:
https://i.postimg.cc/RqrgKmXy/Tiki21-site-title.jpg


Steps for reproduction:
* Fresh install of Tiki21
* Look&Feel: Switched to site layout "Classic Bootstrap (fixed top navbar)"
* Removed the logo link
* Added title and subtitle

That's it.
Then you should get, what is shown on the screenshot.

This bug is also present in Tiki20.1.

A modal should show when you click the icon, but it doesnt. The modal contents load in a full page, and with limited functionality, such as not having a "save" button.

{img type="fileId" fileId="1291"}

Seen in Tikis 18 with r. 69798 and r. 69918

/templates/layout_fullscreen_check.tpl line 8: Broken icon call.
{CODE(Colors="Tiki")}
{self_link fullscreen="y" _ajax='n' _icon_name=expand _title="{tr}Fullscreen{/tr}"}{/self_link}
{CODE}

_icon_name is set to expand, without quotation marks around 'expand'. Whether _title is correct with a starting underscore I don't know. Also, there is no icon named "expand" (with quotation marks), but there is an "expanded", that is redirected to bullet_toggle_minus.png.

Search offered by browsers (Ctrl+F) looks in text areas. So if editing a wiki page (for example), browser search should allow finding a term in the wiki page's source. Unfortunately, CodeMirror does not find terms reliably, in Tiki 17 as well as trunk (r63983).

It's not exactly clear when search works and when it doesn't, but apparently occurrences of the search term inside the visible zone will be found. Those outside will not necessarily though.

For example, searching for "Smarty templates" in https://dev.tiki.org/DevTips only finds 1 of 3 occurences if the editor is at its default positioning (top).

This affects at least Firefox 55.0.3 and Google Chrome 61.0.

I consider this a serious bug for CodeMirror.

One of the wizards displays one particular bubble help beginning WAY off the browser window, that is Random Header Images on /templates/wizard/profiles_useful_micro_confs.tpl. It starts a couple of hundred pixels outside the browser window, which means that all lines start with invisible (!) sentence beginnings... This is so far the only bubble help that starts off-screen, the others behave normally.