Category: Conflict of two features (each works well independently)
Show subcategories objects| Name | Type |
|---|---|
| Cannot Reply to a Comment on Wiki page | tracker item |
|
Category listed as "Array" in itemlink Edit Interface
Steps to reproduce: * Assign a "category" field type to a tracker. * Populate some fake data for testing. * Create an itemlink tracker type and point it to the tracker that has the category type. * In the "multiple fields" section of the itemlink, specify the category field created earlier. Now fill out the tracker data. You will see that where the category is listed in the edit page, there is an "Array" where it should say the category name. Now select the item and save. You will see that the category correctly shows outside of the edit interface. I can create a show instance if this is not clear enough. I'm attaching some screenshots as well. They should be relatively self-explanatory as well. |
tracker item |
|
Change focus of date in Calendars lost with FullCalendar UI
To see the changes in a tiki site you can use module since_last_visit_new When you entered already one day, logout, login again days later, the focus is to show changes since the last date you did login, afaik. Using the standard (former) calendar UI (i.e., NOT using FullCalendar UI), you can click on a date in the calendar to "change focus" to that date, so that since_last_visit_new module show changes since that new focus date. This is not possible any more with FullCalendar UI (or I didn't know how to do it) |
tracker item |
|
chosen lib prevents changing the sorted order display of fields from an items-list tracker field with the translation smarty system
chosen lib prevents changing the sorted order display of fields from an items-list tracker field with the translation smarty system Workaround: disable chosen lib temporarily, make your changes to the selection of fields to be displayed, and/or the sort order, save (and reindex if necessary), and you can enable chosen lib again later on. At least this worked for me so far. |
tracker item |
|
Chrome offers to sign you in again when converse.js is on the page
If you enable "Offer to save passwords" and save your Tiki login and password on [https://wikisuite.chat], each time you reload a page with converse.js in a popup e.g. on [https://wikisuite.chat/About] or [https://wikisuite.chat/P%C3%A0d%C3%A9] Chrome pops up a blocking dialog saying "Sign in as (your username)" and then scrolls you to the bottom of the page, which is really quite annoying. It seems fine on the home page where converse.js is embedded in the page. It also doesn't seem to happen on [https://conversejs.org] after the first page load, so seems to be specific to the Tiki implementation. |
tracker item |
|
clicking on marker of geolocated wiki page on a map produces no popup box anymore (loading...)
Cliking on marker of any geolocated wiki page on a map produces no popup box anymore (it shows "loading...") Other geolocated items work as expected regarding this feature, afaik Reproduced with "GeoCMS Maps_18" profile o 18.x, 20.x, 21.x and trunk. as of today {sign user="xavi" datetime="2020-02-22T13:18:46+00:00"} See it reproduced here: http://xavi-9794-7275.show2.tikiwiki.org/tiki-index.php?page=Map-of-Wiki-pages u: admin p: 12345 (using trunk) |
tracker item |
|
CodeMirror doesn't minify like everything else does
Do a view source of the show instance and you will see: {CODE()}<script type="text/javascript" src="vendor/codemirror/codemirror/lib/codemirror.js"></script>{CODE} Perhaps it's kept separate to be lazy-loaded when needed, but supplying a minified version of the file would be better. |
tracker item |
|
Configuration Wizard does not save changed prefs since Tiki22
((doc:Admin Wizard|Configuration wizard)) doesn't seem to save changed prefs. I've been recently warned about a new tiki admin unable to enable structures, that he needed for a knowledge base with tiki. He was using the configuration wizard, going to wiki, tick "Structures", click at "Save and Continue", but when going back through the button "Back", or going to the control panel Wiki and review structures there, they where not enabled indeed. I was able to reproduce this bug in recents (git based) Tiki 22, Tiki 23 and Tiki master. However, the feature seems to work as expected in Tiki 21 LTS. It has been reproduced in branch master in a show instance: Log in as admin here: http://xavi-9794-7941.show2.tikiwiki.org/ u: admin p: 12345 Visit: http://xavi-9794-7941.show2.tikiwiki.org/tiki-wizard_admin.php?&stepNr=8&url=tiki-index.php Click at "Structures" to (attempt to) enable teh feature. Click as "Save and continue" Click at "Back", you will that the structures feature is not enabled indeed yet. You can confirm so visiting the Wiki control panel, at the section about Structures, here: http://xavi-9794-7941.show2.tikiwiki.org/tiki-admin.php?page=wiki#contentadmin_wiki-2 |
tracker item |
|
Namespace-generated wiki-links not recognized by Backlinks
There is an example available. However this is how to reproduce the problem: Let's say I have a page NamespaceA:_:Home Then I edit that same page throught WYSIWYG editor creating a wiki-link to the not-yet-existing page "Target". In source code this corresponds to ((Target)). Once the page is saved I click on ((Target)) link. This way Tiki automatically creates NamespaceA:_:Target page. I'd like to underline this is an extremely useful feature since it allows even not-developer users to create new pages with the correct namespace without having to mess with the source code, which is a desirable feature. However once NamespaceA:_:Target page has been created, no backlinks are present in there. However if now I edit page NamespaceA:_:Home by adding a wiki-link to "NamespaceA:_:Target" (in source code this would correspond e.g. to ((NamespaceA:_:Target|Target)) ), the link works just fine and moreover a backlink from NamespaceA:_:Target to NamespaceA:_:Home is generated. Option "Force all non-namespace page links to the same namespace" does not seem to solve the problem. --------------------------------------------------------------- In short: ((Target)) and ((NamespaceA:_:Target|Target)) are both valid links towards page NamespaceA:_:Target (starting from page NamespaceA:_:Home), but one is recognized as a backlink by Backlinks plugin while the other one is not. ---------------------------------------------------------------- The problem lies in the fact that if a not-developer user were to use Tiki, the above-mentioned feature of automatic page creation with correct namespace would be extremely useful but it introduces the above-mentioned problem. ---------------------------------------------------------------- I think one possibility would be to edit Backlinks plugin to recognize ((Target)) as a valid link to NamespaceA:_:Target as well (in this context, taking into account the namespace of the page on which the link resides). Another possible solution would be to have WYSIWYG plugin work (optionally?) in a little different way: if I am in page NamespaceA:_:Home and I write a link towards page Target it should automatically translate the link in ((NamespaceA:_:Target|Target)) instead of just ((Target)). Maybe this second solution is cleaner? I don't know. Thank you very much for your attenction |
tracker item |
|
Conflict override conflicts with section edit
{syntax type="tiki" editor="plain"} To reproduce: #Go to a page which someone else is editing #Click to edit a section (ex.: &hdr=9) #You will get a message to confirm override (conflictoverride=y) If you accept, you will be editing full page instead of section. |
tracker item |
|
Console commands no longer respect multitiki --site param
Since recent console.php refactoring the --site parameter is no longer respected in (for instance) the database:update command. When running -+php console.php --site=example.com database:update+- the code in -+\Installer::buildPatchList+- builds the patch list from the default db/local.php database, not the db/example.com/local.php. --- I think related to this, even once i've done the database:update in the browser, i cannot rebuild the index, when i do: -+php console.php --site=example.com index:rebuild+- i get {sign user="jonnybradley" datetime="2020-03-05T11:11:59+00:00"} {QUOTE()}Command not available at this stage. The database needs to be updated. Solved by: php console.php database:update{QUOTE} --- I think this commit was the source of the regression and i'm afraid i can't fix it {gitlab id="2ee93280"} {sign user="jonnybradley" datetime="2020-03-05T11:29:44+00:00"} |
tracker item |
|
Content is displayed outside the remarksbox if I have a carriage return in a list
If the content of a remarksbox __which is part of a list wiki syntax__ contains a line (carriage return) the part below it is displayed outside the remarksbox. {img type="fileId" fileId="1257" thumb="box" desc="Plugin content"} {img fileId="1258" thumb="box" desc="Plugin display"} |
tracker item |
|
Crash on a replication of site from Unix to Windows - and windows installation
Hello, ~~#0c6:HELP, I spent 120 hours on the problem, and I am completely stopped in my Work because I can't install Tikiwiki on the development tool on windows. I could not find a way to understand why 4.1 installation seam's impossible on windows. A failure, that I could not find till know, on windows is not detected by the product.~~ Sorry for the length. I try to install on windows to make test and developments an installation of tikiwiki 4.1 that is on a unix system (OVH provider with shared servers). So I can't have xdebug and many other facilities. This local replication is needed to begin my participation to the dev.tikiwiki.org. For this I have : 1- Changed the way to hold .htaccess (patch) For my apache I use the définition AccessFileName access.htaccess My various application are accessed via virtualhosts this since six years. 2- Enable all needed extension for php : the lonely problem is that it not exists an adodb.dll for php 5.3.0 on windows (not found) After I tried a manual installation : - create mysql db with data 4.1 - create local.php This crash on (see screen xdebug copy) the instruction in tikisession-pdo.php TikiDb::get()->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION); But when I made the searches (this is the opportunity to go inside the product) __I could not find the way how the instance of the class TikiDb inherit of the setAttribute method from probably Zend_Db_Statement_Pdo__ in lib\core\lib\Zend\Db\Statement\Pdo.php:411: If the link exists I am interested in the fact to understand the structure. If this come from the lack of the adodb.dll extension (functions and constants) this should be detected and I could not reach this execution point. Generally may be a detection of php extension features could in the future avoid my "exploration". I will redact when I will have solved all the problems a document about detail of a good implementation on windows. Thank's for an answer, because I am locked till 15 days on this problem. Trebly : ''__Nota1: __''I try new clean installation which don't functions, it crashes, after everything seems to be ended well installed the data are empty and a loop of to forms is without issue : # because the data base is not populated # because at the end we go back to the screen for validation of user and pass (second time) which calls the language form ad vitam. The analyze shows that the POST('user') and POST('pass') are not got back into tiki-install.php and the failed installer is not run again. Finally if I populate the data base with the data's (SQL) coming from one of the to implementations I reach the same as described upon. ''__Nota2:__'' The data's are well accessed by phpmyadmin and the parameters OK. '' __Nota3:__'' I run Mysql with mysqli extension. 256Mo of memory for php * Version du serveur: 5.1.37-community-log * Version du protocole: 10 * Utilisateur: root@localhost * Jeu de caractères pour MySQL: UTF-8 Unicode (utf8) Serveur web * Apache/2.2.13 (Win32) DAV/2 mod_ssl/2.2.13 OpenSSL/0.9.8k SVN/1.6.6 PHP/5.3.0 * Version du client MySQL: mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27 $ * Extension PHP: mysqli phpMyAdmin * Version: 3.2.1 May be there are other reasons that I have not found after 100hours of work... |
tracker item |
|
Creating captions breaks flow of text around images
When I use the image plugin in TikiWiki 18.3 and set the text to flow around the image (imalign=right|left) then the text flows around as it should. When I set a caption to the image (desc="") then the flow is immediately disrupted. Captions, when no text flow is set, work perfectly, so these two features disturb each other. I posted this as a question in the forum, and got a workaround and the advice to report this as a bug. Thanks for your help hman |
tracker item |
|
Creating new article for tiki.org/news while being switched in the "info" perspective does not get saved but switches to default perspective instead
Steps to reproduce: #Go to https://tiki.org/News #Go to https://tiki.org/article452-Tiki-18-1-has-been-released-fixes-and-security-update #Click "New Article" #Enter a TEST title, Classification > Topic Releases and Patches, Publication > __uncheck the "Published" checkbox!__ #Click the "Save" button You get switched back to default perspective. When you switch back to the first tab "Content" you see the form content is gone and the rest of the tabs got reset to the defaults as when you start editing new article... :( |
tracker item |
|
Danger with Watches and PluginGroup
When writing a particular wiki page, and being set this page to be watched to a group (let say Registered users). Then if the page has plugingroup to hide particular peaces of special text that is not intended to be known by certain users. Then every time this page changes, a notification email is sent to all Registered users (this is ok), but in the content of this email all the source code is revealed to EVERY user on the Registered group, regardless if they have the right to see Source of wikis. Don´t know how this could survive the testing and dogfood of this community. May be there is another way to let the Registered group to be acknowledged of a change in a wiki, without compromising content. Please enlight me on how to do this much of the work done on our live tiki portal uses plugingroup to restrict snippets of text to certain groups and other snippets has to shown, in the same wiki. There should be an option to configure a watch to be sent in a way that only alerts the user that a particular page has changed without showing all source, in respect to a particular right to see or no to see the source. I have checked on the proper user rights and object perms to avoid them to receive this notifications in the proper way, but tiki doesn´t seem to take it. Using Tiki 6.2 |
tracker item |
|
Datachannel / Tracker Functionality
The datachannel does not accept data when passed as a country selector tracker field. ( Without a JQ event ). Jyhem has a well explained document at http://doc.tiki.org/Data+Channels?highlight=datachannels . This example works only when there is a JQ event i.e. when the user makes a change to the fields explained. Though my use case is simliar, I am using the tracker plugin to pull from a user registration tracker to pre-fill fields for the user to verify, there are typically no changes to the fields and consequently the JQ doesn't trigger. Therefore I used the standard datachannel method of passing static fields "fieldName,external=fieldId" to pass the values to the datachannel. No worries there...the problem occurs when I try to pass a country selector field value to the datachannel. I am using the "hidden" method i.e. "fieldName,hidden=" and the JQ script $("inputname='Country'").val($('#page-data').find(":selected").text()); to pass this value. Inspection of the HTML output using a console indicates the form data are properly outputted i.e. input type="hidden" name="Country" value="United States" (end tags removed) but this is not passed or it is parsed out upon form submission. The importance of this functionality is obvious and I think it would greatly improve the use of the datachannel plugin. Thanks in advance for your consideration. Robert A Rasgorshek showtiki info admin 12345 |
tracker item |
|
dev.t.o 13.x: add some scrollbar at the top of wide tables in Bootstrapped themes, since they look as with less content for new users or unexperienced visitors
dev.t.o 13.x: add some scrollbar at the top of wide tables in Bootstrapped themes, since they look as with less content for new users or unexperienced visitors Example: see for instance http://dev.tiki.org/tiki-tracker_view_history.php?itemId=5162 {img fileId="940" thumb="y" width="600" rel="box[g]"} Column related to new content is not shown, and there is no clear indication that some more content is hidden in the right-hand side of that table. New: A library has been found to solve this problem: [https://www.jqueryscript.net/other/Double-Scrollbar-For-Scrollable-Container-jQuery-DoubleScroll.html] . License is MIT. |
tracker item |
|
dev.t.o: plugin popup helper failed twice for pivottable
I attempted to use ((doc:PluginPivotTable)) in a new page in dev.t.o: ((Bug report evolution)) # I first wrote ~np~{pivottable}~/np~ in the wiki page and saved (to check whether there was going to be some helper to find the right compulsory params that where missing (tracker:5 assigned to some param name, which I didn't remember) # then I edited again the wiki page, and clicked at the plugin toolbar icon to get the popup helper for pivottable. ** this requested me to indicate the first compusolry field, which offered to me to select some wiki page name, but not the right param content for the data source (tracker:n o activityStream). __First error/regression__ (it used to allow typing any text there, afair, but it currently deletes what the user types since it doesn't match any option from the list of wiki page names shown). ** I selected some page name, so that I could get the param name correctly written in plugin call in the textarea of the wiki page, to fix the value assigned to that param name manually, while also writing to text in the body of the plugin textarea while still in the popup helper. But when I attempted to accept to get the syntax inserted in the wiki page, I got this error message: -+Plugin edit failed+- Oups, bad user experience. Looks like as if it was some experimental feature, while it has been there for years across many versions. |
tracker item |
|
dev.tiki.org :: 13.x trackers in new edit interface :: selecting a status hides the text
Some white on white action is happening... {img fileId="824"} |
tracker item |
|
dev.tiki.org 13.x regression: Since your last visit module: tab 2 & 3 not accessible in mobile mode
With Android browser. |
tracker item |
|
dev.tw.o: Sorting items from trackerlist plugin doesn't work for anons due to cache issue
dev.tw.o: Sorting items from trackerlist plugin doesn't work for anons due to some conflict with the wiki cache. Example: http://dev.tikiwiki.org/tiki-index.php?page=Profile+Manager&tr_sort_mode1=created_asc http://dev.tikiwiki.org/tiki-index.php?page=Profile+Manager&tr_sort_mode1=created_desc both pages show the same sorting on date (for instance) if the user is not logged, but the sorting works if you are logged. |
tracker item |
|
Diagram, Multilingual; A Tiki diagram will be look broken if displayed on an RTL wiki page
{syntax type="tiki" editor="plain"} On Tiki25 a well displayed diagram on a LTR page will look broken on a RTL page. {img fileId="1944" thumb="box"} {img fileId="1945" thumb="box"} Note: If displaying the same in a Tiki Slideshow using the slideshow plugin it is properly displayed. |
tracker item |
|
Diagrams cannot be saved inline in wiki pages anymore
I was testing other things, and I realized that diagrams cannot be saved inline anymore. Reproduced in a show2.t.o instance from another bug report (since setting up diagram generation requires some manual steps to get the composer package installed server side) http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=Tiki-Wiki-CMS-Groupware u: admin p: 12345 I selected to save each new diagram inside the wiki page (inline), but that choice was not respected and diagrams were saved in a file in the file gallery. Current code used in the show instance: SVN (24.0vcs): Tuesday August 3, 2021 17:34:21 CEST - REV 78798 (InnoDB) --- Upgraded today (server side) to latest 24.x branch: r79594 (Last Changed Date: 2022-01-22 14:46:09 +0100 - Sat, 22 Jan 2022) . Issue solved. |
tracker item |
|
Diagrams have poor usability still in 21.x LTS due CSRF and ticket expiration
We have been experiencing in our team at work several issues while attempting to use Tiki Diagrams in production in Tiki 21.x LTS There might be 2 related (for the end user) issues. It seems as if some ticket expires too soon and some error related to CSRF is shown. Maybe after editing the diagram for more than 20 minutes or so (even if Tiki is set to remember the login for days or weeks, which seems to work when we are not using the diagram feature). Diagrams are created to store their contents in a wiki page (because in file gallery we face some other issue still, as reported in [item7192|another bug report]) 2 error messages are shown in similar conditions (unclear yet the exact difference; these reports were sent by work colleagues of mine, so far) Error message 1: {QUOTE()} "An error occurred, please try again. Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help." {QUOTE} {img fileId="1450" thumb="box"} Error message 2: {QUOTE()} "An error occurred, please try again. Potential cross-site request forgery (CSRF) detected. Operation blocked. Ticket has expired. Reload the page" {QUOTE} {img fileId="1451" thumb="box"} In case it matters: the https certificate seems to be not recognized (by the browser used to reproduce the issue) as valid. |
tracker item |
__Not Found
The requested URL /mywiki/page=IVR_Revitalization&post_reply=1&comments_threshold=0&comments_reply_threadId=5&comments_offset=0&thread_sort_mode=commentDate_asc&comments_per_page=20&comments_grandParentId=0&comments_parentId=5&thread_style=commentStyle_plain was not found on this server.__
This would be a show stopper using Tiki threaded comments is very important feature requirement for us.
Thanks,
Paul