Category: 18.x

I can't make a simple ((doc:PluginWysiwyg)) call to work as expected in Tiki18 (afaik it worked as expected up to Tiki16 at least; I didn't try in Tiki17).
{CODE(ln=1)}
{WYSIWYG()}
foo
{WYSIWYG}
{CODE}

Using wiki plain text editor.
Unluckily, I have NOT been able to reproduce the issue in a show.t.o instance
http://xavi-9794-6661.show.tikiwiki.org/tiki-index.php?page=Community
(it works as expected there)

And I've noticed that if I clone the same page contents from my production site to a page in the show.t.o instance, the issue can't be reproduced: admin user can open the wysiwyg editor coming from the plugin wysiwyg.
And if I add perms to the page in my production site so that anons can edit the wiki page, the issue vanishes
Odd, after adding and removing perms in that page in my production site, I can't reproduce the issue any more. :-/

Ok, I'll close this bug report, with a tag "works for me". Who knows what was going on.

The basic Tiki DB initalization IMHO contains an error. Maybe this is due to a change introduced later that made the INSERT incompatible to the CREATE. /db/tiki.sql contains this at lines 2867-2878:
{CODE(Colors="Tiki")}
DROP TABLE IF EXISTS `users_usergroups`;
CREATE TABLE `users_usergroups` (
`userId` int(8) NOT NULL default '0',
`groupName` varchar(255) NOT NULL default '',
`created` int(14) default NULL,
`expire` int(14) default NULL,
PRIMARY KEY (`userId`,`groupName`(225))
) ENGINE=MyISAM;

INSERT INTO users_groups (`groupName`,`groupDesc`) VALUES ('Anonymous','Public users not logged');
INSERT INTO users_groups (`groupName`,`groupDesc`) VALUES ('Registered','Users logged into the system');
INSERT INTO users_groups (`groupName`,`groupDesc`) VALUES ('Admins','Administrator and accounts managers.');
{CODE}

This should not work. Maybe the resulting error is just ignored? Values are entered into the non-existent column "groupDesc"...

Please correct me if I misunderstood this: To me the language system just translates one string of source language into another string of target language, is that right? At least that is suggested by the data structure of language.php.

If that is the case, then there is a fundamental flaw in it: The system cannot (by design) take into account that no function f exists that translations a string of source language into target language.

Because language has a context, and different contexts can radically change to correct translation!

One issue I have only seen now that I have shopping cart activated on one of my Tiki Wikis. There is a button "checkout" to log you off the wiki.

And there is a button "checkout" in the shopping cart, but this will NOT log off the wiki, but close an order, meaning the user requests payment.

The first button "Checkout" is at the moment correctly translated with default values into "Abmelden" in German.

But the second buttons "Checkout" on the shop makes no sense being called "Abmelden" as well, because the user pressing this button does not want to log off, he/she wants to pay, so the only correct translation would be "Bezahlen" (pay).

I believe this contextual change of meaning cannot be dealt with by the current language system, it cannot even handle exceptions?

(or, alternatively, wrong user input method) The admin UI for the facet feature describes, that the user shall enter a comma-separated list of categories, yet a multiselection window is presented.

Interestingly, in /lib/prefs/category, where this help string comes from, is text input specified ?! If that would be presented, the text would be right, but somehow it is not...

{CODE(Colors="Tiki")}
'category_custom_facets' => [
'name' => tr('Generate custom facets from categories'),
'description' => tr('Comma-separated list of category IDs.'),
'type' => 'text',
'size' => 15,
'filter' => 'int',
'separator' => ',',
'default' => '',
'profile_reference' => 'category',
],
{CODE}

cf. screenshot (attachment)

Prefix doubled when tracker item saved and wiki-page-tracker-field uses custom namespace
---
human error, not tiki error. The field to get the page name from was a mathematical calculation field, and I had written there the prefix aswell, not only in the params of the wiki-page tracker field.

Links added in a certain Tiki instance to that same Tiki instance should be wiki links when the target is a wiki page. If not, they should be relative links as much as possible, rather than absolute links. Using relative links eases domain name changes, and facilitates the management of several environments (for example, synchronizing a production environment with a development environment, like nextdev.tiki.org vs dev.tiki.org).

There may be cases where an absolute link is best, but these should be rare. When a user adds an external link to self with an absolute URL - for example "http://tiki.org/Foo" - which starts with one of the Tiki site root's base URL-s - for example "http://tiki.org/" - Tiki should detect the situation and convert to a relative link - for example "/Foo" - unless the user really wants an absolute URL.

One vector through which URL-s are commonly inserted is the External Link tool in the toolbars of parsed text fields. This tool should be modified to detect attempted insertions of absolute links to self and offer the user conversion to relative.

I imagine there should be an administrative preference to control behavior - either automatically convert to a relative link, or prompt users. Should there be more options?
I believe the default should be to prompt users.

User starts editing a tracker item, and wants to preview changes before submitting

Months ago trunk allowed to install (apply) profiles directly from the profiles wizard. I can't do that any more neither in 20.x nor in 18.x: same effect:
{QUOTE()}
Collaborative_Community_12x: See profile info below (may take a few seconds to load).Loading profile...
{QUOTE}

And you never get the profile loaded successfully, on link on the profile name, and therefore, you can't request that profile to get ready to be applied in your tiki install.

If you click at "find" button from that control panel ui, then you get the profile name clickable, and you can proceed as usual.

After 18.2 upgrade images with border and caption, if a caption contains quotes, the quotes are shown as %22text%22

The plugin list need a real "random" sort option to display trackeritem randomly in a list.
It will help to use it in many place.

For example at https://tiki.org/consultants
We use {CODE()} {sort mode="randommode" modes="tracker_field_tikiConsultantsUsername_asc, tracker_field_tikiConsultantsItemID_ndesc, tracker_field_tikiConsultantsItemID_asc, tracker_field_tikiConsultantsSorting_asc,tracker_field_tikiConsultantsName_asc, modification_date_asc, tracker_field_tikiConsultantsName_desc"}{CODE}

With all this parameters it even couldn't get the illusion it is random. Refresh 4 or 5 times the page and you will see that the list is permutation of the same order.

When using the contact page (see: https://www.wiki-to-yes.org/contact) for sending mails, anonymous user will see the recaptcha field and images. This is as it should be. Though they mark the captcha images correctly and the confirmation that they are no robots becomes visible, their mail will not go out. Instead users receive an error message: "captcha value is empty".
Of course I have entered the site key and the secret key on admin page.
I one likes to check see: https://www.wiki-to-yes.org/contact.

It would be nice when deleting (or renaming) a wiki page, if Tiki asked for a redirect (via the REDIRECT page). This would help visitors how have bookmarked the original page.

Use case:
#As admin, you select to DELETE (or RENAME) a wiki page.
#When Tiki prompts for confirmation, there could be a checkbox & text field asking for a redirect page.
+You should be able to enter ''either'' an existing wiki page or a fully qualified URL.
#If you select the checkbox (and enter a new page), Tiki does not ''delete'' the page. Instead Tiki edits the page to replace all existing content with a REDIRECT plugin.


There should be an option to have "301" headers so search engines know to update their DB.


There is a new page Alias feature in 3.0 Renamed pages could keep old URL as an alias. This could be done by appending an invisible page alias.

See attached images for UI example from MediaWiki

Related:
[wish1489|Wiki page name Alias]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

To reproduce:
* Admin registers a new user, with confirm email and change password checked (as is typical)
* User clicks on confirmation email link
** User sees change password form
* User closes password form
* User click links again and sees "you have already validated your email" message
* User doesn't know the previous password and isn't offered the change password form again

---
p.s. there is a similar issue if you fail to match the two passwords

The user gets the form back after clicking register, also group voice is quite broken.

There are maybe options and user trackers are definitely involved, but i'm going to set up a show instance to see if the simple registration setup that's been failing for me is reproducible.

!!! Confirmed
On the show instance all i did was enable registration, added the sender email address and it doesn't work. To reproduce go to

* http://jonnybradley-8515-6545.show.tikiwiki.org/tiki-register.php

and try, the registration fails and you get the form you just filled in back again.

I've upgraded this wish to "blocker" status...

Hi,

We use ' Last update from SVN (18.1svn): Thursday February 22, 2018 15:47:32 +01 - REV 65559 (InnoDB)'

'Default bootstrap theme' -- 'no customization'.

__The REMARKSBOX:__
{CODE(caption="The REMARKSBOX" colors="tiki" theme="default")}
{REMARKSBOX(type="information" title="Hva er Wiki")} ... {REMARKSBOX}{CODE}

We experience that AutoTOC is not rendered properly (some headings are missing) when a REMARKSBOX is present in the Wiki page:
{img fileId="1164" thumb="box"}

Thanks!

Erik Qvam

------

The first entries seem to be ok up to the point where there's a "REMARKSBOX" in a wiki page. after such a remarksbox, no more (sub-)headings appear in the "autotoc" list, it seems to be truncated.

This regression from Tiki 12 to Tiki 15 was first reported by cpeter in {wish id=5928}.

This does not happen if REMARKSBOX is called in a level 3 section.

Not possible to change icons in REMARKSBOX.

The scoring system is untranslatable as a whole.

It relies on labels written in English, and unlike some module parameters, where translators can mock the interface by rendering the translation in the explanation of the parameter, that won't be possible here, so that scoring cannot be translated, and to admins who do not speak English this entire feature/module becomes unusable, because it will be incomprehensible.

My proposal for rebuild with the least amount of work needed is: Prefill with IDs and have the current text be a mere label, but rendered through tra().

--Tiki 18.x no longer needs mods.tiki.org-- It would have been nice to delete mods before 18.0 but it's somewhat late now...

Ref: https://tiki.org/forumthread67983

Presumably, we shut down mods.tiki.org in April 2021, at the end of the support period for 15.x?
https://doc.tiki.org/Tiki15

Since upgrading from LTS18.7 to 18.8, we are now unable to remove specific versions of a wiki page.
So whilst we can edit a page to hide profanity, obsenity and the like, we can not physically remove that version of the page.

This might also mean a site would be unable to fully comply with a "right to be forgotten" style request.

As an admin or suitably privildges user, go to page history, add tick in box for the version to be deleted. Then from the drop down menu at the foot of the page select Remove and click on the OK button.

The "Please confirm" pop up is shown and then click on Delete button.

The Error message "No version were selected. Please select one or more versions" is shown at the top of the History screen. The screen shows a selection tick against the version it's just failed to delete.

This bug seems closely related to at least two other recently filed bugs ....
[https://dev.tiki.org/item8065-Wiki-pages-cannot-be-deleted] and
[https://dev.tiki.org/item8128--No-users-were-selected-error]

Hi,

There are issues with filtering on 'Date and Time picker' in TableSorter and PivotTable. I spoke with another team member who said they were "deep issues". I have confidence they will get solved some day, but date sorting, - by month and year, at least - is a basic necessity today.

I created a very simple workaround that is bullet-proof, which works across the board where applied. I added two dropdowns with:

1) year, i.e. '2019, 2018', etc.

2) month, i.e. '01-January, 02-February, etc.'

So now the user has two extra fields to click on (:sad:) (in addition to the 'Date and Time picker' field, as the day is important also) but, also have a TableSorter that works 100% (:biggrin:)

The 'Wish' would be to add separate fields ('months', 'year') in which:

month - has an option to have the current calendar month (based on the time and date settings off the users Tiki configuration) be the default option (yes/no)

date - same thing, option to have current year as default.

While some would argue, why not 'quarterly' or some other options, realistically, monthly or annualy is how the vast majority people view reports.

I strongly suspect this would be super easy and quick to accomplish as 90% of the code is already available.

br,
Mike

When we have a textarea in non wysiwyg mode, the textarea can be resized by moving the bottom right corner.
The mouse changes its style as illustrated on the attached snapshot.

This works fine for FireFox but not for Mac-chrome or linux-chromimum.

The textarea can be resized, but the bug is, there is no hint about it so people miss the information because the mouse does not change shape.

You can reproduce on this very textarea using chrome (no need for a show instance :-) )

{include page=Roles and Permissions}

Firefox has the RSS feed reader function removed for some while now, MS Edge still carries it. You can add a feed into MS Outlook.

When you add the Feed Indicator add-on to Firefox, it will display RSS feeds available (if you turned the feature on in the Control Panels.

So you can have Outlook and Firefox display, for instance, the Article feed from your Tiki. It will display just headlines and the introduction, and display a link to read the full article. But that link is broken...

Example: Link to article #72 is this:
{CODE(Colors="Tiki")}
WEBSITE/tiki-read_article.php%3FarticleId%3D72
{CODE}

This will only produce a 500 Internal Server Error... The correct syntax would have been:
{CODE(Colors="Tiki")}
WEBSITE/tiki-read_article.php?articleId=72
{CODE}

A look into the generated XML shows this:
{CODE(Colors="Tiki")}
<entry>
<title type="html">TITLE TEXT</title>
<summary type="html">
<strong>HEADLINE</strong>
</summary>
<published>2022-03-02T03:53:00+00:00</published>
<updated>2022-03-02T03:53:00+00:00</updated>
<link rel="alternate" type="text/html" href="WEBSITE/tiki-read_article.php%3FarticleId%3D72"/>
<id>
WEBSITE/tiki-read_article.php%3FarticleId%3D72
</id>
</entry>
{CODE}

So both the question mark and the equals sign got encoded into hex, which shouldn't be...

The admin UI for the schedular contains some help text that is strangely totally untranslateable.

/templates/tiki-admin_schedulers.tpl contains this at line 147:
{CODE(Colors="Tiki")}
{remarksbox type="note" title="{tr}Information{/tr}"}
{tr}Use CRON format to enter the values in "Run Time":
<br>
Minute, Hour, Day of Month, Month, Day of Week
<br>
Eg. every 5 minutes: */5 * * * *{/tr}
{/remarksbox}
{CODE}

Since the text is correctly enclosed in tr in curly braces. I am at a loss why this is the case, and why it throws no error?

Also, I seem unable to translate the task descriptions. These are ConsoleCommand, ShellCommand, HTTPGetCommand. I cannot even find the location where they are set. While I figure that admins who want to use schedulers might understand those terms, so task descriptors are slightly less important, but the help text about CRON syntax isn't.

It would be good to make the 'User' (i.e. user name) a required field when adding a new Tiki User (Admin Users)

Recently, I tested adding a new user without this (left blank), but added the password (2x) and an email. Tiki went the the next step, 'Confirm adding new user', then went to the full user list. Of course it was not visible anywhere in the full list of users (only one page, under 10 users total).

Also, it might make sense to change the name from 'user' to 'user name', or even more direct 'login'.

br,
Mike