Category: 13.x

wiki (wysiwyg) inline editor transforms page alias links into standard wiki page link on save (alias lost)

See it reproduced here:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

The homepage has at the bottom the standard code for an alias at teh page "HomePage" to be accessed also from "Casa" alias page name.
{CODE()}
(alias(Casa))
{CODE}

Therefore, you can access to the homepage also with:
http://xavidp-1553-5652.show.tikiwiki.org/tiki-index.php?page=Casa

However, if you open that wiki pade for edition with "Inline wiki editor", make some changes, and saved the page through the inline wiki editor (click again at that button that you used to open the inline editor), then the alias link is gone. If you edit the page with the standard wiki plain text aditor, you will see that the code at the bottom is replaced with a standard wiki link pointing to "HomePage" and using "Casa" as label.
{CODE()}
((HomePage|Casa))
{CODE}

Text boxes do not save in WYSIWYG mode. Even switching from WYSIWYG to Source and back will remove much of the formatting. I have turned this feature off for the time being because formatting is automatically removed when you go to edit a wiki.

This is mitigated by a warning in edit help:
{QUOTE()}The conversion process is not entirely transparent, meaning that you may notice differences between the look of a page in different modes.
This will improve in future updates but as the two systems have significant differences in what they can do it is unlikely to ever be totally transparent.{QUOTE}

In Wiki page, the print function should show the current information of the page, but the page was shown the unapproved details after I clicked the print icon. I have activated the Approval function so that the edited page will be shown after approval.


---
Info to reproduce it {sign user="xavi" datetime="2014-12-31T07:30:58+00:00"}:
u: admin
p: 12345
* Log in as admin to the attached show.t.o instance: http://marshallau-11729-5521.show.tikiwiki.org/
* See that the "Official Document" has no approved page:
+ http://marshallau-11729-5521.show.tikiwiki.org/tiki-index.php?page=Official+document
* click at the Wiki print button, and you will see the latest version of the document, even if unapproved:
+ http://marshallau-11729-5521.show.tikiwiki.org/tiki-print.php?page=Official+document
* log out as admin, and as anonymous, visit again the url of the print-version of the document. You can see it freely:
+ http://marshallau-11729-5521.show.tikiwiki.org/tiki-print.php?page=Official+document

According to r31226 (7/12/10, by killianebel ):
{QUOTE()}[MOD] Wiki pages can be viewed at a specific version, using the &version or &date URL parameter. Files included in pages with the FILE plugin correspond to the specified version. This feature must be enabled with 'feature_wiki_use_date'.
{QUOTE}

However, I can't get this feature to work with Tiki14 or Tiki12 or Tiki9 (with or without revision approval). It seems as if important pieces of code are missing. Did this ever worked?

menus for some time have had the option to have the menu label wiki parsed - which allows customised formatting of the label and if required the addition of images etc

for wiki parsed menus that are displayed using the 'old' suckerfish menus this still works perfectly so that for example a menu item with the label:

~np~Home {img src="img/icons/home.gif" height="12" width="12" alt="Image"}~/np~

creates the parsed output of:

~np~<li class="option217 menuSection menuSection0 menuLevel0">
<a href="HomePage">
<span class="menuText">
Home
<img class="regImage pluginImg" width="12" height="12" alt="Image" src="img/icons/home.gif">
</span>
</a>
</li>~/np~

and will correctly display: Home {img src="img/icons/home.gif" height="12" width="12" alt="Image"}

However when the same menu is displayed using a bootstrap menu format something goes wrong with the wiki parsing causing an additional / to added to the end of the img tag ie

~np~<li>
<a href="tiki-index.php?page=HomePage">Home <img src="img/icons/home.gif" height="12" width="12" alt="Image" class="regImage pluginImg" /> </a>
</li>~/np~

this is then displayed as:

Home <img src="img/icons/home.gif" height="12" width="12" alt="Image" class="regImage pluginImg" />

ie showing all the html

Wiki tables are really ugly now. Ex.: http://tiki.org/Domains
{img fileId="857"}

Fancy tables are better. Ex.: http://themes.tiki.org/Sample+page (notice there are no stripes)
{img fileId="858"}

And PluginWish, which is an alias of PluginTrackerList looks like this (notice the stripes):
{img fileId="859"}

PluginProposal looks like at http://dev.tiki.org/CSS+Frameworks+and+Preprocessors
{img fileId="861"}


So what is right Bootstrap way to do tables?

Here are two related commits in trunk:
https://sourceforge.net/p/tikiwiki/code/51838
https://sourceforge.net/p/tikiwiki/code/51677

Should they be changed?
Should they be backported to 13.x?

See: http://dev.tiki.org/tiki-pagehistory.php?page=Tiki12

{img fileId="852"}

Seen here: http://next.tiki.org/tiki-admin.php?page=general

This is perhaps by design because of the move to Bootstrap.

For new sites, the UI should prevent / warn.

For upgrades, there should be some documentation on https://doc.tiki.org/Tiki13, and ideally, this be dealt with in the upgrade script.

Similarly, there could be an issue with level 2/3/4 menus...

When visiting: https://dev.tiki.org/Trackers

The list of Pending & Closed issues appears, but not Open

{CODE(caption="The code is the same for all three")}!!Open
{wishes filtervalue="28" status="o"}

!!Pending
{wishes filtervalue="28" status="p"}

!!Closed
{wishes filtervalue="28" status="c"}{CODE}

{img fileId="815"}

{img fileId="854"}

I have seen similar weirdness on other sites but have been unable to see the pattern. I suspect a specific condition of having (or not) certain modules in the footer (or something)

{img fileId="830"}

'Add an item' for tracker field 'item link' does nothing when field displayed as multi select.

See it reproduced here:
http://xavi-9794-5317.show.tikiwiki.org/tiki-ajax_services.php?controller=tracker&action=insert_item&trackerId=1&modal=1

u: admin
p: 12345

::{img src="https://dev.tiki.org/display799"}::

13.x: After a remote file is uploaded to a file gal, no file Id is shown any more since 13.x

Reproduced in doc.t.o.
* Edit a page
* click on the icon at the toolbar: {img src=https://doc.tiki.org/img/icons/file-manager-add.png}
* place a remote url to a file. For instance: http://www.r-project.org/hpgraphic.png
+ Once uploaded, you see no fileId any more. Upto 12.x, you saw the filename with a link to the file id number on hover, etc.

I don't know when this stopped working, but for sure this worked in previous versions (6.x, probably, when I last tried years ago)

I attempted to add the new argument 'shownbitems' (set to 'y') to the plugin alias "wishes" in dev.t.o, but it doesn't get stored. When I reload the page after I hit save, the new argument is not there int the list.

To reproduce:
* Come here as admin: http://dev.tiki.org/tiki-admin.php?page=textarea
* Click on "wishes"
* Click on the plus green icon, next to "Simple Plugin Arguments". A new empty field will be shown at the bottom of that section.
* Add the argument pair (shownbitems y) to its corresponding fields of name and value, and hit at save at the bottom
* This new argument is not shown. And after clearing tiki caches, the wishes plugin doesn't show the number of items yet.

13.x: Can't display .webm videos uploaded to a tiki site

See it reproduced in a bug report textarea here:
https://dev.tiki.org/item5321

Tried with these two ways:
# Using the html5 video tag, in a similar way as indicated here: http://www.w3schools.com/html/html5_video.asp
+ {CODE()}
{HTML()}
<video width="320" height="240" controls>
<source src="http://doc.tiki.org/dl1108" type="video/webm">
Your browser does not support the video tag.
</video>
{HTML}
{CODE}
** {HTML()}
<video width="320" height="240" controls>
<source src="http://doc.tiki.org/dl1108" type="video/webm">
Your browser does not support the video tag.
</video>
{HTML}
# Using the PlginWebDocViewer in Tiki12+, that according to [http://doc.tiki.org/PluginWebDocViewer|its documentation], it can display webm videos.
+ {CODE()}
{WEBDOCVIEWER(url=>http://doc.tiki.org/dl1108, width=>425, height=>350)}{WEBDOCVIEWER}
{CODE}
** {WEBDOCVIEWER(url=>http://doc.tiki.org/dl1108, width=>425, height=>350)}{WEBDOCVIEWER}

None of them seem to work with Mozilla Firefox (30.0, for GNU/Linux).
Under Google Chrome (35.0), using the html5 video tag (within PluginHTML in Tiki) works fine, but using the PluginWebDocViewer nothing is shown.


See the video itself uploaded to file gallery in doc.t.o: http://doc.tiki.org/dl1108

__140713_dev.t.o_13.x_bug_when_attempting_to_upload_or_select_image_from_textarea.webm__ - 5.69 Mb

13.x: doc.t.o menu 43 (public info for anons) doesn't show 'section level 1' records, but only section level 0 and options
This means that almost all "New in version X" are not shown in the menu.

Instead of manually doing some workaround, I think this is a good dogfood case for fixing the root issue (whichever it is).

Contents of menu43 in doc.t.o as CSV file:
{CODE(colors="csv", ln="1")}
"optionId","type","name","url","position","section","perm","groupname","userlevel","remove"
807,"o","Home","./",1,"","","",0,"n"
767,"o","All the documentation","((All the Documentation))",2,"","","",0,"n"
553,"o","Troubleshooting","((Troubleshooting))",6,"","","",0,"n"
775,"o","Tutorials","((Tutorials))",9,"","","",0,"n"
776,"s","New in version...","",12,"","","",0,"n"
1051,"1","Tiki 13.x","((Tiki13))",20,"","","",0,"n"
1008,"1","Tiki 12.x LTS","((Tiki12))",21,"","","",0,"n"
1047,"o","Tiki 12.x from Tiki 9.x","((Tiki12from9))",22,"","","",0,"n"
1007,"1","Tiki 11.x","((Tiki11))",23,"","","",0,"n"
1004,"1","Tiki 10.x","((Tiki10))",24,"","","",0,"n"
997,"1","Tiki 9.x LTS","((Tiki9))",25,"","","",0,"n"
808,"1","Tiki 8.x","((Tiki8))",26,"","","",0,"n"
806,"1","Tiki 7.x","((Tiki7))",27,"","","",0,"n"
800,"1","Tiki 6.x LTS","((Tiki6))",28,"","","",0,"n"
785,"1","Tiki 5.x","((Tiki5))",29,"","","",0,"n"
768,"1","Tiki 4.x","((Tiki4))",30,"","","",0,"n"
766,"1","Tiki 3.x LTS","((Tiki3))",32,"","","",0,"n"
641,"1","Tiki 2.x","((Tiki2))",34,"","","",0,"n"
1044,"-","---","",36,"","","",0,"n"
1048,"-","","",37,"","","",0,"n"
1005,"o","Tiki Reference Guide","((Tiki Reference Guide))",50,"","","",0,"n"
1043,"o","Tiki Installation Guide","((Tiki Installation Guide))",1500,"","","",0,"n"
{CODE}

13.x: email param from PluginTracker too difficult to get it working as expected for end users

* Maybe some more documentation in doc.t.o missing?
** param "emailformat" (indicated by a poweruser in an email) missing in the doc. page (since long ago)?
* Maybe some easier ready-to-use tpl bundled within tiki to work for that use case, if the default tracker_changed_notification.tpl doesn't work.
* Maybe some bug? (some devs said thatyou need to set the "copy activity to email" to something for that tracker to get those emails sent for the non-registered user submitting the tracker item?
* ...

Related doc so far:
http://doc.tiki.org/PluginTracker#Parameters (see "email" param)

An instance has been created linked to this wish, so that we can all have a look at a common instance to elucidate what the problem is, and then, as a consequence, how to improve it.

Instance design details:
# Feature Log mail in the tiki logs is enabled, so that we can check which emails were sent and which ones weren't.
+ http://xavi-9794-5470.show.tikiwiki.org/tiki-syslog.php
# "Contact us" page contains PluginTracker with this code:
+ {CODE(ln="1")}
{TRACKER(trackerId=1, fields=1:2:3:4, showmandatory=y, emailformat="html", sort="y",
email="real_email_from@example.com|3,a_second_real_email@example.com|tracker_changed_notification.tpl,tracker_changed_notification.tpl")}
!!! Thanks
...{TRACKER}
{CODE}
# Field 3 is the user selector, with "plain text" as the type of link.
# tracker_changed_notification.tpl is a valid tpl in the file tree, so I guess this should be a valid-enough file for basic demostration purposes, unless someone indicates the opposite for some reason.
# "Copy activity to email" has been set to a_third_real_email@example.com, just in case that was valid, as jonnyb suggested.


To reproduce:
# Come here as anon:
+ http://xavi-9794-5470.show.tikiwiki.org/tiki-index.php?page=Contact+us
+ and fill in the contact form, which is set to (in theory) send you a copy of the tracker item added.
# go to the tiki logs ([http://xavi-9794-5470.show.tikiwiki.org/tiki-syslog.php]) and you will that the email that has been sent is the one related to "Copy activity to email" ("a_third_real_email@example.com", xavi (a) tikiwiki.org in this case), but nothing else related to the email typed in the form (field 3) nor the "a_second_real_email@example.com" indicated in the param)


Finally, some hint (in case it matters):
* I tried first this approach in my localhost (linux box), and I got same behavior.
** Looking at the apache error log I saw a message complaining that I didn't have "sendmail", which is true (in purpose, for other reasons)
++ {CODE()}
sh: 1: /usr/sbin/sendmail: not found
{CODE}
** The curious thing is that those cases of error with sendmail were not recorded in tiki syslog as "mail error" lines, but nothing was loged. Only the email related to "copy activity to email" was recorded in the tiki syslog with at least a line saying "mail error", and all the details about that email.

This code used to work in Tiki up to version 12.x, and it was used in doc.t.o pages:
{CODE()}
{DIV(class="thirdfloat clearfix")}{DIV(class="box")}{img src=http://www.r-project.org/hpgraphic.png imalign=center width=300}{DIV}{DIV(class="box")}{img src=display595 width=250}{DIV}{DIV(class="box")}{CENTER()} {youtube movie="https://www.youtube.com/watch?v=TR2bHSJ_eck" privacyEnhanced="n" width="300" height="200" quality="high" allowFullScreen="y" related="y"}{CENTER}{DIV}{DIV}
{CODE}

It was documented here:
http://themes.tiki.org/Floated+box+demo#Three_columns


Workaround, use Plugin SPLIT.

13.x: --Forum Thread Rating doesn't display icons for value 0, wrong icon for value 1-- (fixed) {sign user="xavi" datetime="2014-06-03T22:14:56+00:00"}, and no icons when labels are set beyond values (unfixed still) {sign user="xavi" datetime="2014-06-03T22:14:56+00:00"}

I have it reproduced reusing the show instance of this other bug report:
https://dev.tiki.org/item5253
(linked here in case I need to go there to "__svn up__" again)

{BOX()}
See this thread started by admin:
http://xavi-9794-5253.show.tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=1

admin:
u: admin
p: 12345

Log in as user1
u: user1
p: user1
{BOX}

And here you can see a screenshot of the issue reproduced similarly in local:

{img fileId="785" thumb="y" width="500" rel="box[g]"}


With these values in __Wiki rating options__:
{CODE()}
0=foo,1=bar,2=bar2,3=bar3,4=bar4,5=bar5
{CODE}

I tried in tiki.o to grant the permission to join group and subscribe to group for TwCommunity to "Team Documentation" , for instance, and I couldnt' grant that permission locally to just group Team Documentation, but it was changed to all groups.

I'm not sure right now whether this is a regression or not, but at least this seems a bug to me (or at least a feature request)

13.x: Slideshow skips 1 out of 2 slides and content of 1st slide is shown at the end of the slideshow

To reproduce, apply the Slideshow profile (available in the Profiles Wizard), validate the plugin call, and start the slideshow. 1st screen is empty, and the last screen shows the contents that in 12.x where shown in the first slide, where they were expected.

In addition, when you click on the screen, on press Page forward or down key, you skip one slide each time. (tested with Chrome 35 and Firefox 30 on GNU/Linux)


See it reproduced here:
This slide 32
http://xavi-9794-5342.show.tikiwiki.org/tiki-slideshow.php?page=Tiki+Wiki+CMS+Groupware#s32

should be shown in slide 0:
http://xavi-9794-5342.show.tikiwiki.org/tiki-slideshow.php?page=Tiki+Wiki+CMS+Groupware#

u: admin
p: 12345

See also: http://suite.tiki.org/show:Tiki+Suite+Slideshow

I searched "WYSIwat" in the module search in tiki.org and I got System error.

The url was:
http://tiki.org/tiki-searchresults.php?find=WYSIwat&boolean=on&boolean_last=y&search=Search

Duplicate of {wish id=5360}

{img fileId="972"}
iOS 3.1.3 iPhone Safari

2-way sync of userPreference tracker field (between user tracker and preferences) tricky to set up

I'll see if I can reproduce it in a show.t.o instance...
More info to come...