Category: Regression

https://tiki.org/forum26 = a white screen.
Seems to be stuck 6 month ago
{img fileId="1430" thumb="box"}

When displaying diff and you have some non-ascii characters in page content, e.g. "é" in French language or others, the characters do not show up in the diff output anymore. It happens when viewing diff in page history and also in the email notifications when you watch a page. The rest of the page source displays them though so it is only happening in the diff part.
Example of page with missing characters in diff:
http://tiki.org/tiki-pagehistory.php?page=Home,cs&history_offset=1&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=23&tra_lang=sq&paginate=on&history_pagesize=50

The behavior for browsing categories has changed, and not to my liking. If this was not intentional, then it is a regression (as I've listed it). If this was intended, then please consider this a "wish" to restore the old behavior or (perhaps better yet) provide a plugin that allows me to control the display.

I have two versions available for viewing. They are not show.tiki.org, but they should do for demonstration.

11.2-
http://www.hrsms.org/home/cat74?deep=on&type=wiki+page&sort_mode=name_asc

9.2-
http://www.hrsms.org/home9/cat74?deep=on&type=wiki+page&sort_mode=name_asc

I like that in 9.2 it only shows the current category, and without watch links.

In 11.2, all categories are shown, with watch links (which in my opinion just add clutter to the page), and the category listing is expanded to the last viewed, not the current. To see this:
a) Browse categories on this site
b) Expand "How To-->Hulls"
c) On left menu, select "Models-->By Nationality"
d) Note that the results displayed are for nationality, but the category listing is still expanded to "how to--> hulls". Confusing to the viewer.
e) Change current URL from ..\home\.. to ..\home9\.. to see how "nationalities" looked in the old version. I much, much, much prefer this way.

I tried using PluginCategory for the same purpose, but I could not get the desired results. Indeed, I'm not even certain I get the results that should be expected. Based on my understanding of the parameters, I would expect the categories AND sub-categories to be displayed, and the results split when the category changes. That does not happen. You can see that here:
http://www.hrsms.org/home/Models

{CODE()}{category id="4" types="wiki" sort="name_asc" split="y" sub="y" showdescription="y" showname="y" showtype="n" one="y" showlinks="y" categoryshowlink="y" maxRecords="1000" showTitle="n"}{CODE}

Hello,

When you use an existing database (UTF8 coded but charset=latin1 and collate=latin1-swedish-ci) converted by tiki-install 5.0 :

1- the titles and contents are displayed : as pure utf8 is saying the French texts (tables defined charset=latin1) :

A- Titles of any item
"L'échec et ses conséquences" is displayed :
" L'échecs et ses conséquences"

B- Texts of dictionnary (language.php UTF8 encoded) as
"créé à partir d'une structure" (comment the update or creation origin of a document) is too displayed
"créé à partir d'une structure"

C- Contents of Wiki or articles : id

D- Menu options : are well displayed
The text comes from the same file language.php (fr)

E- Tiles of column of tables etc. : well displayed

F- Warning messages ?

Everything behaves like the titles and contents even defined as charset=latin1 are dsiplyed as UTF8 while the others are threated well.
Is it a relation with the fact that "modify" action never displays anything because of the query, I will try to understand.

Everything was displayed well in 4.x versions

trebly

Use Firefox to visit [http://zukakakina.com/tiki-listpages.php] for an example. If Tablesorter is turned on, div class="table-responsive" will be out of position, offset far to the right.

The div containing the wide table is positioned correctly in Opera 12, Recent Opera (webkit), and IE11. But in Firefox (latest version), this div (.table-responsive) is positioned so that just the left edge of the table is inside the div and the rest of the table extends to the right, under the right column of the page.

Another table with tablesorter applied, on tiki-adminusers.php, doesn't show this problem in Firefox.

At https://doc.tiki.org/PluginCode the different samples with colors parameters are not doing anything.

I attempted to upload a simple image to a doc.t.o page (it seems to be using 19.x and elfinder) and I got error message about CSRF
{QUOTE()}
Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.
{QUOTE}

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

I had to disable elFinder to allow uploading images to doc.t.o.

Feel free to re-enable elFinder feature in doc.t.o anyone once it's confirmed to have been fixed.

Please see:
https://doc.tiki.org/Blog+User

{img fileId="914"}

{syntax type="tiki" editor="plain"}
Background info:
http://tiki.org/tiki-view_forum_thread.php?comments_parentId=46281

So when you visit http://doc.tiki.org/Features, the actual list of features comes and goes.

You can see from the video below (I put a watch alert on that page) that it has been going on for months:
{flash type="url" movie="display251" width="1126" height="528"}

I am not sure if this is planned or not, but it makes it difficult to work with inline editing.

Also inline editing has a separate permission, thus the user may lack edit permission in full wysiwyg mode.

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.

Ive noticed that drop down menus and hovers seem to have stopped working in trunk. Seems like it might be related to bootstrap upgrade.

Features that I use regularly that no longer work include the login dropdown and hover help in preferences.

When the same footnote is reproduced, this was detected in Tiki12 and both had the same number and would link to the same item in footnotearea

Now, as can be seen in our explanation page: [https://doc.tiki.org/PluginFootnote] duplicated footnotes are shown twice (the 3 & 4 both show ''Ibid.'')

Using "sameas" option is not really a good solution because adding a footnote above other footnotes does not recalculate the sameas parameter even though the number of the previous footnote changed.

It seems the regression was introduced by: http://sourceforge.net/p/tikiwiki/code/53263 but a simple rollback would remove the "class" option.

I suggest recovering the duplicate detection and also adding two new optional options:
Id (alnum)
sameasId (alnum)

so we can express that a footnote is the same as another by Id. This way, adding new footnotes only changes the numbers (displayed), not the Ids (not displayed).

{syntax type="tiki" editor="plain"}
Check the duplicate tracker item option is enable.
On a tracker duplicate an item.

It used to open in a modal which look ok.
Now it open in full page.
It doesn't look good.

Dynamic Content like {content id=1} no longer works, but is blank

I have tested 'Dynamic Item List' tracker field at version 12.0 alpha for upgrading from version 10. According from my simple test, it does not work.

Thanks,
Joon

Dynamic items list displays just one item in the 2nd dropdown, See it reproduced with the PRofile "Dynamic items list"
---
Invalid, it works as expected., it seems. {sign user="xavi" datetime="2016-06-07T12:54:51+00:00"}

"Dynamic items list" stopped working in trackers with current tiki3 code. It seemed to worked with tiki2, according to the nice documentation and screenshots created by ricks99:
http://doc.tikiwiki.org/Dynamic+items+list

I can provide a testing db if needed (or a site to check this behavior):
http://intercanvis.net

(fields right now only visible to admins, until this field type works again)

edit article doesn't save if you change any setting in the advanced tab: to email.

Reproduced in
https://tiki.org/tiki-edit_article.php?articleId=442#content_edit_article1-5

Add any email in the "to" field, and you won't be able to save your edition, or your new article if it was the first time you were writing that.

The action log, in addition, says:
{CODE()}
/New article post at tiki.org [Invalid "To" header; contains no addresses]
{CODE}

{syntax type="tiki" editor="plain"}
Editing by admin saved the file intact, but the file wasn't renamed. Editing by a registered user created a 0-byte file (also not renamed with -username added). I checked in a Tiki 3.2, which has the same problem.

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.

Tested in my Chrome browser all edit plugin helper icons do nothing currently on tiki.org
E.g. clicking the jigsaw puzzle icon on https://tiki.org/Roundtable+Meeting+2020+01 (with javascript:void() link) does nothing. Same on doc.tiki.org

No errors in Google chrome Console appearing.

Can anybody confirm/reproduce?

Google Chrome is up to date
Version 79.0.3945.130 (Official Build) (64-bit)

{syntax type="tiki" editor="plain"}
In Opera (no need to mention version number; every Opera user uses the lastest version ;-) ), in the last day or so the edit textareas in branch 6 have been missing or misplaced, for wiki pages and trackers, that I've noticed so far. (Forum post forms are ok.) On the wiki edit page, the edit textarea is far down from the toolbar. Sometimes clicking on fullscreen edit and back again will bring it up to the toolbar. On the dev.t.o bug-submitting tracker form, the textareas for description and solution don't appear at all. I clicked on fullscreen editing and back, and a textarea appeared but it seems to be the solution textarea, not the one for the bug description. This affects the regular wiki editor; I didn't check yet about the wysiwyg editor.

Using strasa.css in demo.t.o/11.x (reproduced else where also)

Log in as admin
Edit a wiki page,
click at a tool in the toolbar (help icon clicked in the screenshot below)
popup box is shown under the text area, no button are shown, most controls are hidden, etc.

See screenshot

{img fileId="288" thumb="y" rel="box[g]"}

There is a z-index problem with the edit help modal when editing a calendar event. The help modal displays behind the edit event form.

A related still-open bug report is at [https://dev.tiki.org/item5788-Z-index-issue-in-tiki-calendar-php].