Category: Bug

In lib/prefs/wiki.php there is a strange feature name I cannot translate. After the experience with all the tabs and newlines and stuff in feature.php, I did check this string with a hex-editor: No special characters. It as plain as it looks: "inline auto-toc". And it is correctly pumped through tr(), so it should translate. But it doesn't. Event if I copy & past this string directly. Please have a look at line 706:

{CODE(Colors="Tiki")}
'wiki_inline_auto_toc' => [
'name' => tr('Inline auto-toc'),
'description' => tr('Change the display of the table of contents for wiki pages to inline.'),
'type' => 'flag',
'default' => 'n',
'dependencies' => [
'wiki_auto_toc',
],
{CODE}

1. I have (show page title set to yes in the user preference).
2. I have a structure as a menu item in a module.
3. For each page in the structure I go to edit> properties > Show Page title = Off.
4. Page by page as I set this option the "House Navigation widget" disappeared.
5.In effect Two features are being controlled by one user preference.
{img fileId="2126" thumb="box"}

Structure Menu does not update after page-name changes

# you have a page in a structure and the structure Menu is activated
# you change the page name
# in the breadcumb navigation the changed page name shows up
# but in the Structure menu the old name did not change, but when clicking on it the page shows up anyway.
# in the Structure page the correct name is shown anyway

e.g. changed page ITSystemFiltered to ITSystemActiveFiltered

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

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

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

This is demonstrated here:
http://user-11990-7501.show2.tikiwiki.org

With a wiki page this code
{CODE(theme="default")}Table of contents:{toc structId="1" shownum="1"} {CODE}
will produce this with a PDF generated:
{img fileId="1444" thumb="box"}

It does not matter if the wiki page is part of the structure or not.
On screen there are only numbers shown:
{img fileId="1445" thumb="box"}

I have an issue where if my sub-headings exceed 9 then the auto-numbering and autoToc is screwed up.

This does not happen on first saved, rather after the next edit and save.

To replicate the issue:

1. Create new wiki page.
2. Add a H1 Heading, e.g. 'Section 1'
3. Add 10+ H2 Headings underneath the 'Section 1' Heading
4. Add another H1 heading, e.g. 'Section 2'
5. Save
6. Edit Wiki page
7. Save again

H2 Headings are OK up unitl section 1.9 and then the system seems to add an additional hard coded 1.x on to the end of the auto number.
An additional hardcoded number is added with each subsequent edit & save.

I am using Tiki 24.2 on a fresh install on CentOS 8, MariaDB 10.3.28 (InnoDB) and on client side Ubuntu 22.04 with Firefox 107.0.

Just added a new category, works fine. Added a subcategory. This subcategory is there (showing in various menus as "category::subcategory" where i have to select a category), but it is not showing at all when just listing the categories. In Tiki 21.5, categories with subcategories are shown with a little triangle left to them, so they can be opened to show the subcategories. In 24.2 this triangle is not shown at all, I cannot access the subcategory at all.

I noticed a link text beneith the search form "show subcategories", but it does exactly nothing.

Easiest fix would be to revert behaviour to what it was in Tiki 21.5 as it was working fine.

When you edit a Wiki page, the page gets reloaded, with an additional "success" information for the user, painted in green. This success message includes the version number and a reference to the history feature.

Unfortunately the revision no. given is not the new current version number, but the old one, before the edit was done...

Not a big deal, but could be irritating to non-tech users IMHO, because if you look at the history, which is what the success info encourages, you will not find your edit under the given revision number.

If you add a headline to your survey (I do not find it very intuitive that headlines are to be entered as "questions", but so be it at the moment).

When you add a heading that is given in the help text/hint "y,h4" strange things happen.

h4 is understandable (at least to an admin...), headline size 4. But I wonder why the example list "y"? I don't recall a tiki syntax tag "y". From what it does it seems to be an undocumented newpage, introducing a new page afterwards. But the help text mentions ("newpage") (btw, missing translation - or the help text must be changed to indicate this is supposed to be English in all localizations)

BUT when you add a new headline exactly as written in the hint text "y, h4" you get ''nothing at all'', all of the questions are seemingly gone once you take the survey! On the empty survey page, there is a pagination -- but it is "0/0". If you nonetheless click on "previous" or "next" (if there really were 0 pages this should be meaningless) then you immediately get back all your questions and a correct pagination, too.

Newpage works well, but y,h4 yields this strange 0/0.

So "y,h4" somehow disturbs pagination.

While doing the translation of the survey feature, I added some test surveys. But so far I have not participated in a any of those. Consequently, the statistics page of survey has NO entry under "taken". But every (!) survey has an entry under "last taken". This cannot be true. When there is no participation at all, there cannot be a last participation...

When you create a survey, and add questions of the type "Rate (1 to 5)" (or 1 to 10), when you take the survey, all you get is the text of the quesion, and (if applicable) the red asterisk indicating mandatory answers) but underneath that __not__ the expected either 5 or 10 radio buttons or a 1 or 2 digit numeric input field, but only the text "1 0" (one space zero, in __both__ cases)! Nothing can be entered at all...

Also, there is a completely empty blue info box above the survey...

See the screenshot attached.

Since survey is such an old feature, I guess the functionality was at one point in time lost with the coming of a new version...

{syntax type="tiki" editor="plain"}
There is a setting with which the admin can block SVG (scalable vector graphics) uploading to the file galleries, because of the inherent security risks SVG files ''may'' pose.

If this block is active, it over-reacts. If a user wants to upload multiple files (via multi selection), and ONE of them is SVG, each an every file gets blocked from upload claiming a security block. This does happen with PNG (portable network graphics) and JPG files, which do not pose security risks (at least not the same as SVG).

I'm trying to create a Content Template that indicates intention to use markdown, like shown on this page (for example): [https://markdownthemes.tiki.org/tiki-pagehistory.php?page=Markdown+Plain&source=0]
After I put the following code at the top of that Template
{CODE(theme="default")}{syntax type=markdown}{CODE}
and then Save the template, this code disappears after I re-open for editing.
If the template is used in a Wiki Page, the above code is also invisible.
Unfortunately, the content of the template only shows as a binary blob in the database, so it can't be edited directly and cleaned up.

After a fresh install on Ubuntu Server 20.04, the system menu (42) is missing and inaccessible if the admin tries to incorporate it in a module.

{syntax type="tiki" editor="plain"}
Should be a simple enough fix, "export only" fields (obviously) should bnot be needed as columns in the csv being imported.

I created a fairly basic tiki setup using a brand new Tiki 21 instance (aimed to be used in production next week)

I applied the Collaborative_community_12x profile.

When attempting to edit the registered group to remove the homepage, or select anonymous in the inheritance field, I can't save because this errors blocks the process:

^ Template Group children cannot have permission: Editors ^

I didn't select anything with editors at that level. Nor I did attempt to do anything with templated groups yet, but I was aiming to change basic options yet.

What's going on? Is this "templated groups" feature ready for production?
How can I disable the templated groups and roles options, in order to avoid their issues with basic behavior and setup of a basic Tiki site not requiring that level of complexity?

It should be optional, shouldn't it?
---
Reproduced cleanly in a brand new site at show2.t.o (on trunk since 21.x is not available yet at show2.t.o), and it's clearer to me that this is candidate to release blocker: too serious of an issue with a basic setup and expected change by tiki site admins willing to tweak the basic groups to their needs.

Steps to reproduce:
(1) Log in as admin here:
http://xavi-9794-7325.show2.tikiwiki.org/tiki-admingroups.php?group=Registered
u: admin
p: 12345

(2) Remove the contents of the homepage field and attempt to save. Error message is triggered.

HTH

{syntax type="tiki" editor="plain"}
Test again

{syntax type="tiki" editor="plain"}

__Update:__
{MARKDOWN()}Sorry, but this is wrong - a misunderstanding of what should be the correct behavior and an error in the code. There is no reason to put the URL as the popover title.

1. The URLs should never be translated
2. Someone put that `$url` var in the wrong place in the code
3. The tooltip popover should display what is separated by the ":" character actually, so it should be `$ret = '<a title="' . htmlentities($desc, ENT_COMPAT, 'UTF-8') . '"` (the fix would be just removing the `' . $url . '|` part from the line 61 in the **tikihelplib.php**
{MARKDOWN}

__Original report:__ Go to tiki-user_information.php -> click to the button "Send Me a message" - window "Send Me a Message" will shown.
Here do a mouseover over a questionmark near to "Reply-to my email" and check popup window title -> "__User+Information__".
This string ===cannot be translated===. Translation string ===doesn't exists in language.php===.
Same also for "Send me a copy" quickhelp ....

I have an issue where if I add the section heading toggle e.g. !-# or !+#, then they are lost after the next edit.

To replicate:

1. Create a new wiki page with a number of headings, toggle syntax and text. E.g. !-#Section 1, !-Section 2, etc.
2. Save and all is ok.
3. Edit page again.

When i go to source, all toggle tokens are missing from source e.g. + and - are removed from heading code. e.g. !-# is now !#

User information page
On the tiki-user_information.php -> select wikis and blogs too, and check page description text for both.
Both are the identical.

Shows: "This user has contributed to the following wiki pages" - for wikis and for blogs also.

I think, for blog should be description text as: "This user has contributed to the following __blogs__"

Settings → Users → ''Add or remove from a group'' option from the right-hand spanner

On a new Tiki it opens the "Change group assignments for selected users" modal which helps place the user in groups and set the default group. ''This is fine''.

On a Tiki with a lot of groups, the modal fails to show up and the javascript console reveals that Tiki tries to send the huge list of groups using method GET.
Unsurprisingly, this is met with « 414 Request-URI Too Long »
__This is not fine__ :-(

No show instance with hundreds of groups is necessary : I hope this can be fixed by changing the GET query into a POST.

{syntax type="tiki" editor="plain"}
Hello, when UAB was introduced the admin aside menu was collapsable.
Like Wordpress admin side menu.

It is not anymore and I wonder why as this is very useful on small screen.

The Admin Aside menu should be collapsable.

https://ibb.co/ccfgngXq
https://ibb.co/zhRwkZbQ

{syntax type="tiki" editor="plain"}
Today I installed a new Tiki28.x from CVS (gitlab).
After importing the database I went on the General setting screen.
The Browser Title displayed was "My Tiki" as it should have been on a default install with a new database.
Not with an update.
Other informations (like my email) where ok.

I changed it to the original Browser Title.
I have no idea if only the display on the install screen was wrong or if saving would have obliterate the initial Browser Title of this Tiki.

Tested on a second Tiki, continued the installation... the Title Browser is replaced with My Tiki.
Highly unpleasant and damageable for SEO if you don't pay attention it happened.

Screenshot: https://ibb.co/zKW33B6

{syntax type="tiki" editor="plain"}
Up to Tiki26x it was possible to add a class to certain elements of the CustomSearch plugin interface.

For example:
{CODE()}
{categories _parent="4" _style="select" class="faq-input-field selectCategory bg-primary-light h-100 mt-2 mt-md-0 mt-lg-0 mt-xl-0 mt-xxl-0" _firstlabel="Search..." _showdeep="y"}
{CODE}

On Tiki27 due to the usage of "Select2" the class is omitted.
This doesn't happen for all CustomSearch fields, but do on selectors.

{img fileId="3060"}

{syntax type="tiki" editor="plain"}
When you duplicate a Wiki Page you have 2 additional options:
* Duplicate categories
* Duplicate tags

Both never worked for me as far as I can recall.
When I duplicate a page that are categorized and have tags the new page won't have them.

It should be fixed OR even removed as no one seems to use this (never worked for me since Tiki24 or even more)

It is giving a bad image of Tiki.