Category: Consistency

When using tiki-print.php the page's real name is displayed instead of its alias. This is probably caused by the same regression which caused real names to be displayed as the page title instead of the alias as was addressed in [https://dev.tiki.org/item4722?from=user|this] bug report that has been completed.

I believe that the fix implimented in the bug report linked above does not remedy this, as I applied that fix to one of my local installs and the problem was still there.

I think the reason this happens is because the code that sets the page title as an alias gets that information from the structure_path object that is somehow tied to the breadcrumbs module, and the breadcrumbs module is absent when viewing the page content through tiki-print.php.

Possible solutions would include getting access to alias information through another way (generating a structure_path object on the fly if one does not exist), or perhaps simply generating breadcrumbs on the tiki-print.php page to have access to the object and setting their visibility to hidden.

See {img fileId="1237" thumb="box"}

I discovered a problem where one of our users had created a page containing the words SeaMonkey in the description. When she later tried to link to this page with the syntax ((PageName|This is the link text)), the link broke, and tried to embed a link to create a new page titled SeaMonkey among other things. The cause of the problem, was that the description of the page she linked to, was inserted as the title of the <a>-tag.

{syntax type="tiki" editor="plain"}
I'm using staging and approving wiki pages and recognized, that the page description disappears under some conditions. I tried to find out this "some conditions" and hope to give sufficient informations:

* First a user or admin creates a new (wiki) page with description.

* The page is saved as staging page with the description.

* If the page is edited before approval (by user or admin), the description remains in the field.

* If the page is approved by an approver (= user with permission), the description remains in the field, too.

* If the page is approved by admin, the description is away.

* If the approved page with a description (equal, if approved by an approver or by admin with rewriting of the description) is reopened for edit, the page description field is blank.

With "page description disappears" I mean, that

a) the description is not saved when approving the page by admin and

b) the description field prior filled with a description is then blank, when the page is opened for editing (after approval).


__TikiWiki version:__

* 2.1 new installation

__Staging and approval settings:__

__Group permissions:__

Anonymous

tiki_p_view
tiki_p_view_categorized

Registered

tiki_p_wiki_view_history
tiki_p_wiki_view_source

Editors

tiki_p_view_categories
tiki_p_lock
tiki_p_minor

Approvers

tiki_p_rename
tiki_p_rollback

__Category permissions:__

Staging

Registered : tiki_p_view_categorized
Registered : tiki_p_edit_categorized
Editors : tiki_p_view_categories

Approved

Anonymous : tiki_p_view_categorized
Editors : tiki_p_view_categories
Approvers : tiki_p_edit_categorized

__Wiki staging settings:__

Use wiki page staging and approval : yes
Category for staging pages : Staging
Category for approved pages : Approved
Category for pages out of sync : none (see group settings above)
Force bounce of editing of approved pages to staging : yes
Delete staging pages at approval : yes
If not in the group, edit is always redirected to the staging page edit : Approvers

__Group settings:__

Default category assigned to uncategorized objects edited by a user with this default group :

Registered : Staging
Editors : Staging
Approvers : Approved

__Other Wiki settings:__

Page description: activated/checked
History only for data, description, comment change: not checked
Individual cache: I tried with and without activating/checking - no difference

{syntax type="tiki" editor="plain"}
The file gallery displays great, except that it does not browse with the page numbers, neither the paging arrows (next page, last page).

There are several times that a HTML wiki page will fail to render a paragraph.

*In a footnote, the paragraph will fail to render when there is one paragraph, however all paragraphs will render correctly (more or less) if there is two or more paragraphs.

*A paragraph within a opening and closing HTML pair will fail to render in a similar way.

There is a tiki instance that clearly demonstrates this.

not intuitive for new users:
{THUMB(id=34)/}

dthacker: I'm not seeing this as of SVN on 2008/04/01. Please retest in IE on current version.

Try
https://dev.tiki.org/Payment
it simply yields a 503 error "service unavailable"...

Thanks
hman

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

This happens in the same context as my others tracks (3029 - 3057).

This is a problem that is completely identified.
In my opinion it is important.

!!Context
!!!system
The database has been saved in SQL and loaded with upgraded versions of mysql and php 5.3.2.
There is in my opinion no relation with the system context.

!!!Program execution
During start the current session prefs contained into cache participate to generation of the query launch to reinit the context of previous current session.

!!ERROR
__A fatal error occurs in tikisession-pdo.php on line 44 function write statement <$sth->execute();>

!!!Message
PDOException: SQLSTATE[HY093]: Invalid parameter number: no parameters were bound in D:\Trebly\Teawik-ld8-422a\lib\tikisession-pdo.php on line 44__

!!!Analyze
The var_dump($qry) in "prepare" function (see my interface in Class TikiDb_Pdo) gives (extract)

''object(PDOStatement)[42]
public 'queryString' => string 'update sessions set data='need_reload_prefs|b:0;serialized_prefs|a:9:{i:0;s:27:"feature....''

!! Problem identified
The problem comes from the fact that into the session->data you can find the HOMEPAGE article "title" which is, in this case (French):

''__s:46:"Page d'accueil spécifique des administrateurs";__''

so the " ' " not escaped generates the crash of the request.


!!Solution ?
!!! Proposal, basis :
When the titles of articles (or any text which can occur into prefs or any query) are stored the " ' " must be escaped into the database.

!!! Proposal for compatibility :
#identify any text which can be used into queries
#be sure that these text have " ' " escaped everywhere, if not
- upgrade database
- upgrade display for these text with escaped " ' "
- upgrade when text is got from forms the data transfer to database with the escaped " ' "
- set a test on syntax queries to catch this error. A simple test of " ' " into query which display error message (because it is impossible to execute a validate successful query).

!!!Note :
Note : Temporarily I have implemented for me a syntax control and a validation test for " ' " into the query which escapes the incongruous " ' " with a warning message. This because with this title the content will not be found... but the query don't answers in a right manner.
To execute completely I have suppressed in my test database the " ' " into the titles. This can't be used in an operational config.

This occurs because I use for test an homepage which depend of the main group of users of the user.
So I have severals homepages managed as articles with a link to categories.

On his homepage a user can in this way find :
# his main homepage
# links to secondary homepages depending of his roles into the site

The GUI layout in tiki-calendar_edit_item.php breaks if localization comes into play. Look at the screenshot (attachment) to see these issues, that surface when you want to introduce a repeated event. They are:
a) in "monthly" all ordinals below 10 have a leading zero, which is unnessary. It would do no harm, but surprisingly the leading 0 is separated by the number with a space, which together render wider than the space that was allocated for that, leaving only the leading 0 visible... There is no dot, although ordinals in German have a dot "sixth" is spelled "6." in German.
b) in "yearly", where you can for instance define "every 6th of a month", there is the dot, but as a text input field? Actually you cannot write in there, but is is layouted as a text input field (white background). And here also the width is highly insufficient.

c) I cannot translate the "End period" string. Even if I add the array_merge to custom.php (see the bug report for that). And in tiki-calendar_edit_item.php I do see tr in curly braces, so it should respond to language.php and custom.php, but it doesn't?

We have a __global__ permission tiki_p_list_trackers that should allow or deny groups to be able to see the list of trackers (tiki-list_trackers.php). This permission is only listed in the global permission (not object) so it is definitely __all__ trackers.

__Tested with a fresh Tiki25.x__
See in the attached video: {mediaplayer src="display1797"}

It seems this permissions is simply ignored.

#Visiting the tracker list page as anonymous I can see the tracker list page with an empty table.
+ What a un-happy UX/UI...When the is nothing to see, the user/visitor should clearly see nothing ? and eventually the reason he sees nothing. Not an empty table.
# If you change the __object__ permission "tiki_p_view_trackers" for a tracker, it will be listed.

Doesn't make sense to me.
See my suggestions in the Solution field below.


{FADE(label="before test in Tiki25" icon="y")})

Tested at https://nextdev.tiki.org Last updated (GIT 23.x:19611): Thursday 09 September, 2021

Global permission Can list trackers (tiki_p_list_trackers) disable
{img fileId="1587" thumb="box"}

Anonymous can see in the trackers list different trackers
{img fileId="1588" thumb="box"}

---
Test 2 disabling ALL global permissions for trackers for anonymous (for all)
{img fileId="1589" thumb="box"}

Anonymous can now only see tracker5 listed
{img fileId="1590" thumb="box"}
---
Test 3 disabling Can view trackers (tiki_p_view_trackers) object permission for tracker5
{img fileId="1591" thumb="box"}

This (tracker) object permissions Can view trackers (tiki_p_view_trackers) is enable.
---
Test 4
Disabling this (tracker) object permissions Can view trackers (tiki_p_view_trackers)

Anonymous can't see the tracker5 listed, but still can see tiki-list_trackers.php and the menu item
---
Test 5
If I enable (one by one) for Anonymous:
Can create new tracker items (tiki_p_create_tracker_items)
Can change tracker items (tiki_p_modify_tracker_items)
Can remove tracker items (tiki_p_remove_tracker_items)
(I stopped here)

Anonymous can't see any trackers listed, but still can see tiki-list_trackers.php and the menu item
---

My understanding is that, as there is NO tiki_p_list_trackers permissions per tracker object is that this permission is a top layer that should be applied to display or hide tiki-list_trackers.php trackers=>list trackers

There are many cases you want users (groups) to access item(s) but not to see the trackers list without redoing the all display interface. "tiki_p_list_trackers" permission was an easy and cleaner (no empty list or un-useful menu item) way to be sure this doesn't happen. While there are other ways to achieve this, those are complicate and require power users knowledge.

I believe that in time something was omitted (broken) and it went under the radar.
May be because the permission label "Can view trackers (tiki_p_view_trackers)" is not clear enough vs "Can list trackers". It should have been "Can view tracker ===items===" .
{FADE}

Please add a feature to Tiki to automatically sort marked content. And please use it on tiki-admin.php, because due to the translation, the list of plugins is__totally__ ill-sorted, making the use much harder than necessary. The same goes for permissions...

Only an automated sorting would automatically apply to every translation, and would not have to be redone after changes....

Thanks

Please clarify: /img/flags/flagnames.php contains several flags with duplicated entries. With and without underscores or spaces.

American Samoa, several British territories, Bosnia and Herzegovina, practically all country names that contain spaces have double listings. One with spaces and one with underscores.

The remark in the source code says
// Here come the dynamically generated strings for img/flags/*.gif
// This file ensures that the following strings will be included in the language translation files.

There I do not see any flags with filenames containing spaces (although on today's operating systems they wouldn't pose any problem.

So is this some historical relic? Then please clear this up, it unnecessarily inflates ALL (!) languages' translations.

Thanks.

P.S: Fun fact, there is even a flag "low germany" which does not exist. It was composed from the existing flags of Germany and the Netherlands.

P.P.S: Two flags are missing, since 2019 North Macedonia:
https://en.wikipedia.org/wiki/North_Macedonia
In 2018 Sudan split up in North (Republic of Sudan) and South:
https://en.wikipedia.org/wiki/South_Sudan

While refining the localization for German (de_de), I came across voting, polling and surveys in Tiki.

Unfortunately (because Tiki just makes "blind" (or "dumb") string matching disregarding context, votes and poll answers and results are mixed up, especially when they are called "vote", making it very hard to translate (because the translations for those differ vastly).

The entire systems for voting, polling, surveying (and rating) should be proof-read to ensure a consistent language (and here I speak about English) throughout Tiki. Maybe this should be supervised by a native speaker of English (which I am not, so read the following cum grano salis).

To show you what I mean by that:
A poll is NOT a voting (election). A poll is (mostly) a survey done by researchers or journalists. Even if it is done in front of an official place to cast votes (unfortunately here even language itself being imprecise, calling such places "polling stations"), the so-called "exit poll", voters of the actual election are asked (!) about their votes or ballots.

What these people answer to the poller are NOT votes (votes are cast inside and are mostly secret!). These are answers that voters give voluntarily, and may or MAY NOT be identical to the actual votes (people are entitled to lie to a poller!).

So do not call answers to a poll "vote", please. They are votes if they are part of an actual decision making process in the operation of a Tiki installation.

We should therefore distinguish between poll and election.
If users are asked about opinions, these are answers.

And rating is something different, here users give gradually defined answers, best example is "school grades" (side remark from your fellow translator: In the US those are from A to F, in Germany they are from 1 to 6, A und 1 being the best)

While searching for a string that I did not find in Tiki's source code, I came across /lib/wiki-plugins/wikiplugin_registermemberpayment.php. It does contain Javascript! And quite a lot. Almost half of the file is after the statement
{CODE(Colors="Tiki")}
$headerlib->add_jq_onready(<<<JS
{CODE}

My request for the devs would be: If you have full-fledged Javascript programs, please separate them off into their own .js files. The reason is that PHP's tokenizer will not parse Javascript behind a <<< statement, which is token T_START_HEREDOC (which is eventually ended in a T_END_HEREDOC), and a call to tr() will be inside a huge block of T_ENCAPSED_AND_WHITESPACE, and not in one T_STRING (with the string to be translated in a T_CONSTANT_ENCAPSED_STRING)...

Thanks from your fellow translator
hman

The PluginCarousel seems to be behave quite poorly with any combination of parameters applied, I have tried to add a carousel to the top of a wiki page, I have tried to constrain the Carousel within a Bootstrap grid fluid container and regular container and it seems no matter what I do, the Carousel fly's out of the containers, and main body area and into the rest of the page. Using basic syntax as:
{CODE(theme="default")}{carousel fgalId="6"}{CODE}
I would think it should work out of the box, but I can't seem to get the correct combination of commands to make the carousel work.
Please see show instance.

e

When looking at version of the page the inline editing should be disable.

To reproduce, go to https://tiki.org/tiki-pagehistory.php?page=Roundtable+Meeting+2017+04
View a previous version (not the last one) on your screen.
You are able to edit the convene plugin.
This is wrong.

Inline editing (any editing) should be disable.
A warning (notice) should tell the user something like: "Editing is not permitted on previous version of a page. If you want to use this version and edit it, first rollback the page then you’ll be able to edit it."

Select for Image Source an scr on the internet. Save.
{img type="src" src="img/tiki/Tiki_WCG.png" responsive="y"}

Reopen the plugin dialog change Image Source to file in the File Gallery and enter a valid ID. Save.
The new image will be displayed now. (good fix).
However the module still contain the previous ans unused image src.

{img type="fileId" fileId="2" src="img/tiki/Tiki_WCG.png" responsive="y"}

Creating a simple page with
{trackerfilter(trackerId="2" filters="6/d" fields="6:7" editableall="y"){trackerfilter}
The field 7 is a choice among 3 options.
When filtering, I can see the filtered results, but clicking on any of the fields refreshes the view and does nothing. Is that normal or new to 15x?
Thanks for any suggestion for troubleshooting.
cheers, hj

Plugin TrackerToggle doesn't display the hidden field if attempting to change value in a previously saved itemId

I followed the documentation found here:
https://doc.tiki.org/PluginTrackerToggle
with this type of syntax in a pretty tracker page:
{CODE()}{TRACKER(trackerId="1" fields="2:5:10:11" showtitle="n" showdesc="n" showfieldsdesc="y" showmandatory="y" showstatus="y" wiki="Template1")}{TRACKER}

{trackertoggle fieldId="5" value=1 visible="y" id="condiv"}
{CODE}

And the wiki page Template1 contains:
{CODE()}
Field 2: {$f_2}
Field 5: {$f_5}
{DIV(id=condiv)}Field 10: {$f_10}{DIV}
Field11: {$f_11}
{CODE}

and the field is hidden by default, however it doesn't get displayed when the radio button gets the value "1" (yes) when visiting a previously saved item; e.g., with the url like:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage&itemId=3

(please note that this itemId3 has field5 stored with value 0 (case A). That's why even if you click (at item edition time) to the second value of the radio button (value 1 - case B), nothing is shown (because field5 has value 0 stored or in the session or something).

---

See it reproduced here:
http://xavi-9794-5689.show.tikiwiki.org/tiki-index.php?page=HomePage&itemId=3
u: admin
p: 12345

This doesn't work:

{CODE()}{button href="show:Slideshow+Test" _text="Click here to start slideshow"}{CODE}

Can be seen here:
https://dev.tiki.org/Slideshow+test Click "Click here to start"

I can't demonstrate on show.tiki.org because SEFURL is not working there

The wiki plugin, PluginFade, no longer fades out, but still fades in.
Observed in Tiki6 for IE 8 and Firefox 3.6


!!!!{FADE(label="Click to Reveal, Then to Hide")}

~~#F00:__Reveal works, but Hide Does not work__~~

~~#00C:Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus nec mollis erat. Morbi cursus nunc quis metus semper euismod. Ut facilisis est ligula, eget lacinia metus. Nulla tempor semper risus ut viverra. In faucibus purus et eros consequat pharetra. Fusce mattis arcu lorem, non hendrerit erat. Nulla eu mauris urna. Pellentesque nec velit mi, eu rutrum eros. Quisque nec leo enim, id rutrum metus. Mauris luctus sapien nec nulla scelerisque ultrices. Cras sodales, justo nec elementum imperdiet, elit nulla sagittis ante, at tempus ante risus ut nunc. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi nec risus eu ante pellentesque adipiscing vel eget risus. ~~

{FADE}

It is possible to discard others content when editing directly a plugin of a previous version of a page.

At : https://tiki.org/Roundtable+Meeting+2017+04
Load the page and keep it on your screen / browser (A).
Have or simulate another user that go to the page and edit the plugin convene and save their changes (B).

Go back to your screen (A) without reloading the page. (you don't see new input).
Edit, do changes and save.

The changes from the other user (B) are gone and they’re only shown in history.

Plugin edit should start with a kind of "auto-refresh the content" then edit on "updated" content.

13.x: Comments can't be posted in some pages of the Featured Profile "Collaborative Community 12x", such as the homepage for registered members, or newly created pages such as "Subject 1", etc. Doing all that as admin.

See screencast where the issue is reproduced.
https://www.youtube.com/watch?v=7-OI5GCY4qQ

{youtube movie="https://www.youtube.com/watch?v=7-OI5GCY4qQ"}