Category: Consistency

On a Tiki24 I set up multilingual, I setup a tracker with a few multilingual fields. (tracker field option)

{img fileId="1710" thumb="box"}
I add items and fill some multilingual fields.

Then, I disable multilingual.
When I go to the fields options, the multilingual checkbox is not displayed anymore. (good)
{img fileId="1711" thumb="box"}

When I go in the tracker interface to view items, the other language fields values are displayed. (weird... but do we allow loss of data ?)
When I go in the tracker interface to create a new item, the other language fields values are displayed. (wrong)
When I look at a wiki-plugin tracker the other language fields values are displayed. (wrong)

{img fileId="1712" thumb="box"}
{img fileId="1713" thumb="box"}

{syntax type="tiki" editor="plain"}
When adding a Multimedia field to a wiki page through the Plugin Tracker, the value attribute is unclosed, resulting in malformed HTML until the next quote.

E.g.:
Page is well formed with tracker added.
Click the Edit Plugin:Tracker link.
Add multimedia field to the Fields list.
Click submit.
The multimedia field drops to the end of the form (no matter where you placed it within the list of Fields).
The input tag is then:
{CODE(caption="Invalid value attribute",ishtml="0")}<input type="file" name="track[15]" value=" />{CODE}
Note the invalid value attribute; there's only one double quote.

{syntax type="tiki" editor="plain"}
it seems there is a bug in 4.1 not allowing to assign perms per file in file galleries. i can only download the file as anonymous if i assign tiki_p_download_files to the whole file gallery where the file is saved in but not when the file is categorized in category with that permission assigned (which should work)

In Tiki we have a "Duplicate" item action.
However this action has different name in different places.
At tiki-admin.php?page=trackers we use "Clone"
Under the action wrench on the tracker list item view we use "Duplicate".
The plugin listExecute https://doc.tiki.org/tiki22#PluginListExecute use "Duplicate"
They may be other places...

The pop up calendar in Calendar view only shows 24hr time and there seems to be no place to set this. It does not respect the time settings in admin/General as the rest of the Calendar does. Here in AM/PM land it makes it unusable and I've had to disable it in the template.

Sorry if I've entered this wrong -I'm a user and I'm not sure I'm even supposed to put things here.

{syntax type="tiki" editor="plain"}
When Tiki adds the antibot code to a form or table, there is no specific class assigned to the TD or TR. Sometime this results in odd UI (because sometimes the table is NORMAL, sometimes FORM, someimtes FORMCOLOR, etc.)

Newsletter sends text and html and no way to choose only one

Reproduced here:
https://tiki.org/tiki-send_newsletters.php?nlId=7

Wasn't tehre a way to choose that in previous tiki versions? (tiki12 probably or earlier, I used that preference)
---
Show instance created by bchauchat and admin pass changed to adminadmin
See: [https://irc.tiki.org/irclogger_log/tikiwiki?date=2016-11-25,Fri&sel=58#l54]
---
Update:
This is affecting also the newsletter sending from tiki.org, to communicate new releases to the subscribed users, and it provides very bad image of the polishness of newsletters in our own servers. {sign user="xavi" datetime="2017-01-10T09:32:11+00:00"}

When you create a newsletter, in the course of creating one, you can save what you've done so far as drafts. Those drafts get faithfully collected.

But all you can do with a draft is send it out - or delete it. That's it. No editing... Not even a preview. You have to send it out blindly, trusting those "auto clippings" without seeing them before your recipients see them...

Newsletters (in Firefox and Chrome) do not show the list of emails being sent to, that page where the list got updated as emails where being sent.

In Chrome they are shown as usual (as in 12.x)

Using Firefox 46 on GNU/Linux 64 bit (Ubuntu 16.04).

Got it while testing this issue:
"Newsletter fails to be sent properly if article clipping is involved"
https://dev.tiki.org/item6040

Throtlling was in use, in case this matters.
Reproduced in tiki.org
https://tiki.org/tiki-send_newsletters.php?nlId=7
---
Update: using 16.x in t.o sites, and Chromium: I can't see the list of emails being sent either. (and unclear if all people receive the newsletter, but that is another story - even if that makes uncertain whether we are communicating properly security releases to all t.o-news-and-releases-newsletters subscribers ) {sign user="xavidp" datetime="2016-12-27T18:44:32+00:00"}

To reproduce, edit a bug and look at the category selector (ex.: Feature)

For some reason, there is no space to enter comments on dev.t.o. I am logged in, so I see no reason why I shouldn't be allowed to comment? I can edit bug reports, but being unable of posting my comments in the original bug report posting isn't very, ahem, polite to the original reporter...

__Update:__ it seems to be some AJAX loading (intermittent) issue? {sign user="luci" datetime="2022-03-25T20:58:02+00:00"}

There is no confirmation step on the delete action on -+tiki-user_watches.php#contentuser_watches-2+- as there is on other places in Tiki.

Using PluginTracker and after setting a wiki page language to Portuguese I was able to see the Portuguese version of the fields (including pre-defined ones), as well the translation of the box comment that says: "All fields with * are mandatory". However, after editing the pluging parameters clicking on the plugin icon settings on the page, the page loses its language definition and it must to be set again, every time I edit the plugin.

The following (without a space between braces) does not work anymore:

~np~
you can use the ~np~{{user} }~/np~ ~np~~/np~~/np~ ~np~((doc:Argument Variables|Argument Variable))
~/np~

Instead the Argument Variable which is inside __np__ gets parsed as current user login name.

__Update:__ updated the Subject field to more reflect what is the report about

When editing a Wiki-page and clicking on Wiki-Help there is a link to change the Help to Plugin-Help.

This link doesn't appear when editing forum or trackers..

{syntax type="tiki" editor="plain"}
#Create a new thread and type in a few words
#press PREVIEW to verify and press SAVE after that.
#verify that posting went well
#now reply to this initial posting by typing a few words and press PREVIEW to see that preview works fine
#now press SAVE and get the error message __
Notice: this variable may not be empty: $_POST["thread_sort_mode"]__
#wiki-button "back" leads to another __error message saying "no thread"__ or something like that (I can only see the german text "Kein Thread").
#to see and capture the text of your reply to your clipboard you need to press the back button of your browser
#now reply again to the initial posting, paste in the content of your clipboard and immediatelly press SAVE (without PREVIEW)
#see that saving your reply is fine


When logged in as a regular user this procedure applies and shows errors. When logged in as admin save after preview is fine.

Once again I stumbled upon texts of Tikis admin GUI had resisted being translated, and later I found that nonprinting characters were hardcoded that will block tra() or tr() from pattern matching. Even spaces can block a translation. I won't make new bug reports for those, but rather use this one as sort of an umbrella bug report which I will amend with comments.

So the first new occurency of nonprinting characters that block translations is found on line 130 of /lib/prefs/tracker.php:

{CODE(Colors="Tiki")}
'description' => tr("Require users to fill in a tracker form if not done already by prompting them with a modal dialog "),
{CODE}

Those two spaces (yes, two, not one or three...) may look like a little glitch from a dev's perspective, but since they do not print, you cannot translate this string by copy & pasting from the GUI into custom.php giving a translation: The pattern matching cannot find it. There is a workaround, but this may not be so easy for translators with little experience and with small toolboxes (Windows comes with FAR less useful tools for this than Linux...), since if you encounter those, you have to grep through the entirety (!) of Tiki source code to find the origin of the string, to be able to look at it's source code, to be able to copy & paste from there...

Plugin Tabs shows a button to toggle the display sections in tabs or one section below the other.

When you switch your site to mobile mode in 12.x, the button to toggle tabs is not shown even if the plugin param is properly set

Since a few days (may be a week+) I receive now a notification of my own post in the forum.

IE:
I replied to a post at : https://tiki.org/forumthread79371-Restrict-languages-in-i18n-crashes-website

I received the following email:
Bernard Sfez / Tiki Specialist __mentioned you__ in forum post "Restrict languages in i18n crashes website !"

You can view the mention by following this link:
https://tiki.org/tiki-view_forum_thread.php?threadId=79372#mentioned-bsfez-section-1

---

I'm pretty sure that I was not notified of my own post a few days ago which seems to me the normal behavior. (else we need a different text in the notification)

{syntax type="tiki" editor="plain"}
Hi, I know ''maketoc'' is said not to like other ''maketoc''s on a wiki page but it obviosly does not work correct (on my REV 24736) if inserted on another page than the first one. If inserted on e.g. the third page all links to headlines of the firstpage carry "pagenum=3" in the link instead of no pagenum or "pagenum=1".

{CODE(caption="Example")}
!# first page
!! test
test test test
!! test
test test test
...page...
!# second page
!! test
test test test
!! test
test test test
...page...
{maketoc}
!# third page
!! test
test test test
!! test
test test test
...page...
!# fourth page
!! test
test test test
!! test
test test test
{CODE}

My initial intention was to put a ''maketoc'' at every end of a subpage to be able to navigate back. BTW: on my REV 24736 multiple ''maketoc''s do not cause any additional problem.

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

I have set the following permissions for Anonymous

tiki_p_view
tiki_p_view_categories
tiki_p_view_categorized
etc

and the following category permissions

Anonymous tiki_p_view_categories
Registered tiki_p_admin_categories

Assign permissions automatically: Yes

Despite this neither Anonymous or Registered can view pages that have been categorized, the categories appear empty. Only way I can change this is by changing permissions on each individual page.
I've tried and tested this on 3 different installs, same problem each time. I am quite new to this but have spent many hours on this issue and would appreciate any advice.
I'm sure that there's a way but how?
Cheers

Wiki in question can be viewed at www.paddypaedia.com

Not sure if this is a small bug or a feature request - but now that I have used the very useful Dynamic Variable feature in a number of sites I realise that a quirk of the feature is that only the first instance of the use of an individual variable in an individual wiki page is editable.

If you use the same variable a number of times in an individual page then the 2nd and any subsequent uses are not linkable to the edit facility.

This seems a bit inconsistent and it would be much more useful if any/all instances could be used to update/change the variable.

If this is unavoidable then it would be useful to declare this in the documentation.

Closing this as its not that important any more (Geoff Aug 2013)

Organic Group Addon gone in current 14.x compared to what doc.t.o says about it

See http://doc.tiki.org/Installing+Addons?structure=HomePage+AdminGuide

But in 14.x svn r55196, no option to enable Organic Groups (no organic group seen at all in the Control Panel Features > Addons tab.)

See it reproduced here:
http://xavi-9794-5643.show.tikiwiki.org/tiki-admin.php?page=features#contentadmin_features-addons
u: admin
p: 12345

To reproduce , install a fresh Tiki 13. x from SVN.

{CODE(caption="spurious svn directory")}root@:/var/www/13x# svn st
? components
root@:/var/www/13x#{CODE}

What is this for? Why doesn't it get stored in vendor like the others?

I have a wiki site called "Peter Pan"
I include a page alias ~tc~(alias(Miki Mouse))~/tc~
Now I search for "Miki"
Result: Found "Miki" in 0 pages.

That's not what I found in the docs. There it says that the search is supported since tiki4

How can I solve that problem?
---
Edit {sign user="xavi" datetime="2015-02-02T10:53:28+00:00"}:
After confirming same issue in a trunk show instance also, I renamed bug to __'Unified Search Engine MFTS fails for any content'__ (from __'Page alias not found by search'__), and increased the importance to "9". Thanks agian hans for submitting this bug report in the first instance.
---