Category: 18.x Regression

Several (all?) of my recent edits to ((Tiki18)) page here in dev.t.o send me (user "xavi") to the dev.t.o homepage . That's new, it didn't happen to me months ago (nior in earlier tiki versions).
Regression?
---
Update: reproduced similar issue in trunk (from yesterday) {sign user="xavi" datetime="2018-09-28T09:22:41+00:00"}

I used the Draw plugin in a wiki page, specifying an SVG file. After saving the page, when I click on the Edit icon for the image, the edit dialog displays with "Edit: <file name>" in the title bar, but in the body there is only a No Route Found error message.

I can select a theme stylesheet, apply it to the site, view the stylesheet , and edit the stylesheet. Checking the stylesheet update time, I can see the the edit took place, and I can find the updated CSS in the file. __But__, the site continues to use an unedited version of the stylesheet, it seems. A DOM inspector shows that my edit didn't take place (I changed the body font-size property from 14px to 16px). There's no visual evidense of this change in the page appearance.

What's worse, I can no longer change the site's theme. Using the Look & Feel selector, I can select another site theme, but the switch-theme module, which overrides the site default, can't be used (the selector dropdown is disabled in the HTML). So the theme that I edited (although in its pre-edit state) is stuck as the theme in use.

This feature should be fixed, or else killed, and people directed to use Custom Less or Custom CSS instead, IMO.

This is a duplicate of the bug report submitted by Xavi...

On a file gallery description if you copy/paste or insert an emojis from your mobile on save you’ll lost your edit and get a error 500.

Currently, German legislature is pondering the implementation of the dreaded article 17 (formerly Article 13) of the EU Copyright Directive into German law. Similar implementations must be under way in all member states.

This Article demands that "platform providers" (as general as this term sounds, this means everyone from Youtube down to a privately run Tiki installation) MUST provide online upload filtering of media that could possibly be copyrighted, which translates into "ALL media" AND a "red button" with which copyright holders are enabled to immediately (!) block content they find and deem infringes their held copyrights.

As the IT magazine "c't" informes, the proposed "German copyright service providers law" describes several stages that user uploaded media MUST go through before they may go online.

Platforms shall sign contracts with copyright organizations such as GEMA (for music) etc. Licensed content may go online directly. Other content will have to undergo online filtering. Depending on filtering results, content may be blocked or the copyright owner may be directly informed of the suspected infringement.

It has been speculated previously, that only VERY large companies like Youtube (Google) will at all be (technically) able to run such filter services, looking at the sheer amount of computing power and I/O bandwidth necessary. Youtube and Co could offer filter services for smaller platforms that lack the ressources, but possibly not free of charge. This has been critized as giving Youtube and Co. huge power and wide control over the internet, given the fact that technically there is no difference between filtering for copyright infringement and filtering for unwanted political content, in other words: Once installed, such filters could easily be used for censorship of the internet. This led to mass protest by young people all over Europe. The ruling conservative party promised angry voters that the implementation of the EU directive would not implement upload filtering, but apparently they broke their promise.

According to the government, filters SHALL be set to "mildly" filter, enabling the majority of content to go online, but mechanisms must be implemented for copyright owners to protest, as well as a "red button" with an immediate (!) takedown effect.

When you are in file galleries, some file galleries may contain more images than others. If you are on page 2 (or subsequent) of the sub-gallery you are currently browsing, the according page is loaded with parameter offset=25.

From this view, you can directly click another gallery from the tree that is displayed on the left-hand side.

But ALL subgalleries in the tree are linked with parameter offset=25, so when you click one that does not have more than 25 entries, you get the error message (information) that there is nothing to be displayed...

So either change the logic that all subgalleries in the left-hand tree are linked with their root (offset 0) or display the last possible page of that gallery, when it gets clicked. I would prefer the former.

Thanks
hman

Uploading png files to file galleries get them corrupted somehow. See screenshots (I'll upload them here in short). And a pdf file I uploaded to the file gallery, after I downloaded it again from tiki, I couldn't see its contents properly (see the other screenshot; some font seems to be missing). If I open the source pdf file (not passing through tiki file gallery but directly the one I had in my computer from elsewhere), I can see the contents of that pdf as expected
{img fileId="1191" thumb="box"}
{img fileId="1192" thumb="box"}
{img fileId="1193" thumb="box"}
{img fileId="1194" thumb="box"}

Fairly standard setup on Ubuntu 16.04 (see ((doc:Ubuntu Install)) ), with mysql 5.7.x, and php 7.0.x (originally, but same issue with php 5.6, 7.0.x, 7.1.x, 7.2.x). Using gd (imagemagick installed also after I hit the bug the first time, just in case it automagically helped, but it didn't - I didn't remove gd, btw)

I've tested also using tiki15svn, and I couldn't use it due to some weird error I had never seen before of zend session validator class not finding Id.php in place. (!). Therefore, I couldn't test tiki15svn in the same server.

I tested using tiki17svn, and file uploads worked as expected (nice!).
I tested using tiki18svn, or tiki trunk, and I got the issue I reported.

----
Gosh, similar issue might be happening on dev.t.o (at least for me; is it only me???): try to see the png files that I produced as screenshots, e.g.:
https://dev.tiki.org/tiki-list_file_gallery.php?galleryId=1&fileId=1194&view=page
----
Update: avoided the issue by means of changing the storage of files in file galleries from db to file system. {sign user="xavi" datetime="2018-05-10T14:07:57+00:00"}

Therefore, the issue might be specific to Tiki18+ and Mysql5.7 maybe? (in another production server of mine, the setup is fairly similar in Ubuntu 16.04, but with MariaDb instead of MySQL 5.7, and I didn't see the issue of images getting corrupted).
As a consequence, I removed the tag "Release blocker", since I'm not sure how many production server are out there with MySql 5.7 and storing files in database. Feel free anyone to re-tag to release blocker if this is too critical for someone else.


I removed "19.x" categorization because branch 19 doesn't exist yet. The category "regression from version 18 to 19" is accurate here and already assigned. {sign user="chibaguy" datetime="2018-07-12T07:47:53+00:00"}

The "Find" button on tiki-listpages.php only, when clicked, causes some page reloading but no form appears. I didn't see an JavaScript errors reported.

The sameas parameter was removed in Tiki 18. Therefore, if one attempts to re-use footnote number x using
{CODE(theme="default")}{footnote sameas="x"}{CODE}
the plugin call will display "Error: Empty footnote" instead of a reference to the existing footnote with the number x.

For example,
{CODE(colors="tiki" theme="default")}
Lorem ipsum dolor sit amet, pede reiciendis cras sapien, varius neque consectetuer tincidunt in ipsum, dui nec dis cras.{FOOTNOTE()}Wikipedia contributors. "George Nakashima." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 3 Oct. 2017. Web.10 Oct. 2017{FOOTNOTE} Dui dapibus cras ligula, aliquam ligula. Sit eu euismod aliquam orci orci hendrerit, nullam morbi, et cursus, maecenas quisque blandit enim.{footnote sameas="1"} Lacus sagittis dapibus sed, lorem lacus donec, fusce eros arcu rutrum adipiscing eget rutrum.
{CODE}
... displays:
Lorem ipsum dolor sit amet, pede reiciendis cras sapien, varius neque consectetuer tincidunt in ipsum, dui nec dis cras.{FOOTNOTE()}Wikipedia contributors. "George Nakashima." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 3 Oct. 2017. Web.10 Oct. 2017{FOOTNOTE} Dui dapibus cras ligula, aliquam ligula. Sit eu euismod aliquam orci orci hendrerit, nullam morbi, et cursus, maecenas quisque blandit enim.{footnote sameas="1"} Lacus sagittis dapibus sed, lorem lacus donec, fusce eros arcu rutrum adipiscing eget rutrum.
---
{footnotearea}
---
You can also go to this page at https://doc.tiki.org/PluginFootnote and please see the "Would produce" example, the same issue occurs.

After uploading .h5p files to unlock the different content types, some of the creation wizards do not display all of the necessary information, preventing the creation of the new content. I've compiled a list of the different content types and how functional the editor is with each:

✅ Accordion - Fully functional
? Agamotto - Only an option for a title
✅ Arithmetic Quiz - Fully functional
✅ Audio Recorder - Fully functional
? Chart - Partially functional - bar/slice color and text color cannot be set
❌ ~np~Collage - Only the text string '[field:group:collage:collage]' gets displayed~/np~
✅ Column - Appears to be fully functional
❌ ~np~Course Presentation - Only the text string '[field:group:coursepresentation:presentation]' gets displayed, as well as behavior and text overrides.~/np~
? Dialog Cards - Only some text boxes, no entries for changing/adding cards
? Documentation Tool - Only an option for a title
❌ ~np~Drag and Drop - Shows the text string '[field:group:wizard:question]', an empty collapse, and a collapse for text overrides~/np~
? Drag the Words - Functional, but has an empty collapse after the other content
? Fill in the Blanks - Functional, but has an empty collapse after the other content
❌ ~np~Find Multiple Hotspots - Just the text string '[field:group:wizard:imageMultipleHotspotQuestion]' gets displayed~/np~
❌ ~np~Find the Hotspot - Just the text string '[field:group:wizard:imageHotspotQuestion]' and a dropdown for text overrides get displayed~/np~
? Flashcards - Only a textbox for 'Task description' gets displayed
✅ Guess the Answer - Fully functional
❔ Iframe Embedder - Does not appear to get parsed by Tiki, which is probably for the best.
❌ ~np~Image Hotspots - Some inputs get displayed, but a number are only text, such as '[field:text:colorSelector:color]' and '[field:group:imageCoordinateSelector:position]'~/np~
? Image Juxtaposition - Mostly functional. When editing an image, error message comes up indicating 'Invalid format'.
✅ Image Sequencing - Fully functional
? ~np~Image Slider - Mostly functional, but appears to not parse one input, '[field:group:showWhen:aspectRatio]'~/np~
❌ ~np~Impressive Presentation - Only displays '[field:group:impressPresentationEditor:viewsGroup]', but it appears this content type is still in alpha~/np~
❌ ~np~Interactive Video - Only displays '[field:group:wizard:interactiveVideo]', behavioral settings, and text overrides. From my experience in other H5P editors, this input has something akin to tabs.~/np~
? Mark the Words - Appears functional, but has empty collapse after other inputs
❌ Memory Game - Displays nothing at all.
? Multiple Choice - Appears fully functional, but has blank collapse after other inputs
? ~np~Personality Quiz - Mostly functional, but has missing inputs '[field:text:colorSelector:buttonColor] and '[field:text:colorSelector:progressbarColor]'~/np~
❔ Questionnaire - Not parsed by tiki
? Quiz (Question Set) - No inputs for editing/adding questions, but everything else seemed functional
✅ Single Choice Set - Fully functional
Speak the Words - Not tested (requires browser with speech recognition)
Speak the Words Set - Not tested (requires browser with speech recognition)
✅ Summary - Fully functional
✅ Timeline - Fully functional
? ~np~True/False Question - No option to select correct answer, '[field:select:radioGroup:correct]'~/np~
✅ Twitter User Feed - Fully functional
---
''Legend:''
✅ Fully functional
? Partially working/partially broken
❌ Completely Unusable
❔ Unclear

If you inspect the HTTP headers of a page generated by Tiki, it has an Expires header in the past:
-+Expires: Thu, 19 Nov 1981 08:52:00 GMT+-

Beside that, I also suggest to enable caching, at least in the Raw page display (tiki-index_raw.php?page=), it enables the browser to cache frequently used information by something like the AJAXLoad plugin and improves performance.
Now the Pragma header has:
-+Pragma: no-cache+-
And the cache-control header:
-+Cache-Control: no-store, no-cache, must-revalidate+-

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

When you enter text into an article, or when you edit an article's content, there might come a situation where you want to use a character that is not readily on your keyboard.

Unfortunately, in standard setting, you cannot enter it's unicode address directly with ampersand hash.

That is the time to use the edit feature 'special characters', represented by a keyboard symbol. Clicking this opens a pop-up window containing several special chars, among them are some greek characters.

Btw, strangely there is a greek uppercase chi, but I did not see a lowercase one. The font (currently I use EB Garamond) not only carries all greek chars, but even accented greek and diacritic greek...

This is what happened:
But I just needed an uppercase chi, and it was there, so I clicked it to insert that into the text. It was inserted, the text looked okay, so I clicked on Save. Result: ALL text after the chi was gone, and instead of a chi there was just a ]6.

I was lucky, there were just two sentences after the chi, which I could reproduce. I tried to replay the scenario, and it could be replicated. Each and every time the text gets truncated at the chi. And because articles do not have a history (I'll have to open a feature request to have that added, it's dearly needed) this leads to immediate loss of data (once again, that is not available as a bug classification).

Users can sign in, but the groups they are in are not being synced.

Worked ok in version 5. I've upgraded to version 18.3 via version 12 and now I'm stuck.

No errors in the tiki log.

The only odd line is this:
Searching for user information with filter: (cn=wiki_user) at line 280 in /srv/tiki-18.3/lib/auth/ldap.php

I would expect the filter to read "memberUid" ..
{img fileId="1283" thumb="box"}

I've tried the fix here: https://dev.tiki.org/item5657, but just a got a white-screen of death :-)

Hi

On Tiki 17x :
https://ibb.co/mw5qiR
(As Admin I can see all the activated features) - no relation to the Admins group)

On Trunk:
https://ibb.co/g1Lecm
https://ibb.co/fDQecm
(Admin cannot see some features Admin groups checked or not)

All details here : https://tiki.org/tiki-view_forum_thread.php?threadId=66964

Also reproducable at next: https://nextdev.tiki.org/tiki-objectpermissions.php

---

The show instance doesn’t show it BUT instance is not the last version...

Last Changed Rev: 63640
Last Changed Date: 2017-08-24 06:41:36 +0200 (Thu, 24 Aug 2017)

Hi Tiki community,

I want to validate if from Tiki 18 the displayed number of a TOC is by default always showing the first Level of a title even if we specify only the second level
{maketoc levels=2 }
!!# La fonction « recherche » dans le moteur de recherche de Foncierpédia

We had in TIki 15 :

TABLE DES MATIÈRES
1. La fonction « recherche » dans le moteur de recherche de Foncierpédia
1. Les mots clés à éviter

Now we have in Tiki18.4

TABLE DES MATIÈRES
1.1. La fonction « recherche » dans le moteur de recherche de Foncierpédia
1.2. Les mots clés à éviter

Part of the code where it seems to make the difference in parserlib.php file : V15

// Update last_hdr info for the next header
$last_hdr = $hdr_structure[$nb_hdrs];
$nb_last_hdr = count($last_hdr);


$current_title_real_num = implode('.', $hdr_structure[$nb_hdrs]).'. ';


// Update the current title number to hide all parents levels numbers if the parent has no autonumbering
$hideall = false;
for ( $j = $hdrlevel ; $j > 0 ; $j-- ) {
if ( $hideall || empty($show_title_level[$j]) ) {
unset($hdr_structure[$nb_hdrs][$j - 1]);
$hideall = true;
}
}

// Store the title number to use only if it has to be shown (if the '#' char is used)


$current_title_num = $show_title_level[$hdrlevel] ? implode('.', $hdr_structure[$nb_hdrs]).'. ' : '';


$nb_hdrs++;

In v18
// Update last_hdr info for the next header
$last_hdr = $hdr_structure[$nb_hdrs];
$nb_last_hdr = count($last_hdr);

~~#FF0:if (is_array($last_hdr)) {~~
$current_title_real_num = implode('.', ~~#FF0:$last_hdr~~) . '. ';
~~#FF0:} else {
$current_title_real_num = $last_hdr . '. ';
}~~

// Update the current title number to hide all parents levels numbers if the parent has no autonumbering
$hideall = false;
for ($j = $hdrlevel; $j > 0; $j--) {
if ($hideall || empty($show_title_level[$j])) {
unset(~~#FF0:$hdr_structure~~[$j - 1]);
$hideall = true;
}
}

// Store the title number to use only if it has to be shown (if the '#' char is used)
~~#FF0:$current_title_num = '';
if (isset($show_title_level[$hdrlevel]) && isset($hdr_structure[$nb_hdrs])) ~~{
$current_title_num = $show_title_level[$hdrlevel] ? implode('.', $hdr_structure[$nb_hdrs]) . '. ' : '';
~~#FF0:}~~

$nb_hdrs++;

Using (or not) structure to create a menu, the first item (top menu item) i not clickable anymore.

Check : http://bsfez-11581-6514.show.tikiwiki.org/tiki-index.php

Minify JavaScript breaks codemirror in doc.t.o 18.x.
Once minify js is disabled in the performance control panel, syntax highlighting works again as expected.
I detected it comparing the settings in dev.t.o (where codemirror worked as expected) and doc.t.o (where it didn't; and codemirror modes dropdown, when attempting to change highlighter, showed "null").
HTH

When I create a wiki page to edit trackers using PluginTracker associated with a template and the fields option contains at least one field number, any other fields I put in the template is empty and can not be filled. On item creation, it works.

This is a big issue when the fields are meant to be displayed and not filled (itemlist fields, etc)

This seems to be a general issue: I also can't show the values which I should be able to put in the template according to this page: [https://doc.tiki.org/Pretty-Tracker#Syntax_tips]
{CODE(theme="default")}{$f_created}: created date
{$f_status_input}: status input field
{$f_status}: status (output)
{$f_itemId}: the item id
{$f_lastmodif}: last modified date (this will display unix date, for human readable date look below)
{$itemoff}: the iteration number of each item
{$tr_offset}: the offset of the item, i.e. this is the nth item of the total number of x items
{CODE}

Same issue with sending emails
{CODE()}{TRACKER(trackerId="5" fields="72" action="Submit" overwrite="y" itemId="{ {itemId} }" showdesc="n" url="/Concours" tpl="projet-soumission-Initiative_stratégique.tpl" email="noreply@xxx.ca|createdBy|projet-soumis-membre.tpl" emailformat="text" )}{TRACKER}{CODE}

Will not recognize and include ~np~{$f_49}~/np~ or ~np~{$mail_item_desc}~/np~ (this should show the title field, which happens to be 49 also) in -+templates/mail/projet-soumis-membre.tpl+-

But :
{CODE()}{TRACKER(trackerId="5" fields="72:49" action="Submit" overwrite="y" itemId="{ {itemId} }" showdesc="n" url="/Concours" tpl="projet-soumission-Initiative_stratégique.tpl" email="noreply@xxx.ca|createdBy|projet-soumis-membre.tpl" emailformat="text" )}{TRACKER}{CODE}
Will replace ~np~{$f_49} ~/np~with its value but still not ~np~{$mail_item_desc}~/np~

This is an issue because the fields to display in the mail are not always the same as are present in the tracker edition form. For instance, I want people to only update the field 72 (a checkbox) and get a confirmation email but all the rest was already filled on other forms.

Tiki18svn Version 64923

On the module calendar the arrow are not placed properly.
{img fileId="1141" thumb="box"}

If someone is looking at it, they are also in the wrong direction using rtl
{img fileId="1142" thumb="box"}

when trackers set to show comments below tracker items, and section headings are shown as tabs: comments are shown below each one of the tabs of the tracker item printed (therefore, duplicated info many times)

some images are printed, but some others are not, and they seem to need to have no other params params than the minimum, however, using standard syntax from a brand new tiki site embeds wiki pages with a syntax that mpdf is not able to make it just work, and images are not shown in the pdf produced.

Reproduced here:
http://seeds4c.org/Ubuntu+16.04+LTS+for+Human+Beans
(you can produce the pdf by yourself there)

Code that mpdf doesn't seem to like:
{CODE(ln="1" colors="tiki")}
{img src="display466" link="display466" width="400" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
{img fileId="60" thumb="box"}
{CODE}

Code that mpdf seems to like:
{CODE(ln="1" colors="tiki")}
{img src="https://www.hecticgeek.com/wp-content/uploads/2012/09/Editing-the-disable_wol-script-in-Ubuntu-12.04.jpg"}
{img src="display550" width=600}
{CODE}

(removed the examples with params like src="dl437&display" since they were written by the time when tiki accepted that oldish syntax by mistake){sign user="xavi" datetime="2018-07-24T23:05:08+00:00"}

---
Update: {sign user="xavi" datetime="2018-06-21T11:04:30+00:00"}
In a production server in our work, no images are shown in the pdf at all, with neither syntax. Is there any log file with potential information on why no images are shown in the pdf produced by mpdf?
I confirm that we have php7.0.* and php modules gd, & mbstring installed server side.

Xavier

I removed "19.x" categorization because branch 19 doesn't exist yet. The category "regression from version 18 to 19" is accurate here and already assigned. {sign user="chibaguy" datetime="2018-07-12T07:46:41+00:00"}
---
Update answering luci (Why can't standard users reply to comments, such as my user "xavi" wit no admin rights? :-/ ). Answering here instead (lacking time):{sign user="xavi" datetime="2018-07-24T23:02:41+00:00"}
* replacing that old syntax with new and valid syntax (? intead of &) still yields some broken images in the pdf produced by mpdf. I granted access to amnabilal to a server where she can reproduce. I didn't hear any more feedback from her about it, but I confirm that this issue still exists in several servers of mine, with different setups.{sign user="xavi" datetime="2018-07-24T23:02:41+00:00"}
---
Update: Default syntax with param -+thumb="box"+- keeps images away from the printed pdf (even with valid https cert and fully valid params aside of mpdf) {sign user="xavi" datetime="2018-11-26T22:16:13+00:00"}
Example:
{CODE()}
{img fileId="60" thumb="box"}
{CODE}
---
Issue with -+thumb="box"+- or -+thumb="zoombox"+- for instance, confirmed still in 21.5vcs as of today {sign user="xavi" datetime="2021-11-19T16:14:52+00:00"}

On a tracker I set a tracker field file with option;
File Count : 1
Replace Existing File : Yes

I upload a file (all good)
I upload another file and now the dialog shows like I have 2 files for this item instead of the last one only.

{img fileId="1157" thumb="box"} (from the instance)

It is confusing for the user even if on save or create they will be only on file assigned.
It used to display only one and a single file from the start to the end.

~~#F00:__EDIT: Could not Reproduce in Show! I try to fix with an upgrade. Reducing the importance of this bug report for now.__~~

__Setup:__

* Wiki Structure: on
* Namespaces: on
** seperator: __~__
** tested also with: __:__
* Hide namespace indicator in structure path: ticked (on)
* Hide namespace indicator in page title: ticked (on)
* Force all non-namespace page links to the same namespace: both settings (on/off)

* Create a wiki page with a namespace name example:
+ __example~startstructure__
* Make a Structure from it
* Create a new page __mywikipage__ into the structure
+ page gets correctly named __example~mywikipage__

__Problem:__

When in default settings the ''__Wiki URL scheme__'' is ''__URL encode (Tiki classic)__'' in /tiki-admin.php?page=wiki.
Then the Namespace rewrite does not work and the links / urls are __example+startstructure__ instead of __example~startstructure__, why Tiki does not find the page and either gives an error message or a create page notice or a redirect to the HomePage, depending on further configurations.

__Workaround:__

When the ''__Wiki URL scheme__'' is set to ''__Replace Spaces with dashes__'' in /tiki-admin.php?page=wiki, the links / urls are still wrongly rewritten , but with dash instead of plus: __example-startstructure__ and they do correctly redirect to __example~startstructure__ .

__Additional remarks:__

I think, that the rewrite of the structures feature (wiki structure breadcrumb menu AND plugin toc) from the seperator to the dash (or otherwise the plus) is still wrong.
When I create a page __example-mywikipage__, then I can access the original page with following URLs / Links:
* __example~mywikipage?structure=example~startstructure__
* __example~mywikipage__
* __example-mywikipage?structure=example~startstructure__
* __example-mywikipage-2__

Where __example-mywikipage-2__ is somehow defined as alternative URL from Tiki (18.x) without creating that page at all.
Only __example-mywikipage__ directs to the new page!
__example-mywikipage?structure=example~startstructure__ directs to the old page!

The wiki structure feature uses __example-mywikipage?structure=example~startstructure__ as URL for __example~mywikipage__ respectively instead of __example~mywikipage?structure=example~startstructure__

I'll try to reproduce with a show instance.