Category: Less than 30-minutes fix
The task should not take more than 30 minutes to be solved. Tag a bug or wish with this category in order to have them easily filtered at a TikiFest for example.
Show subcategories objects
| Name | Type |
|---|---|
| Border for he forum table in tiki.o are not displayed for forums when section are used | tracker item |
|
Border on checkbox cells in tables broken by position: relative
{syntax type="tiki" editor="plain"} Currently in master, the horizontal borders on table cells that contain check boxes aren't displaying. Removing the "position: relative" property from these cells solves the problem (the borders display, like those on the other cells in the table row). I would like to remove this property but don't know what its purpose is, or when it was added. (It's not a Bootstrap rule - it was added in themes/base_files/_tiki-tabs_and_tables.scss.) Apparently related to https://gitlab.com/tikiwiki/tiki/-/commit/ea3869d71c9ede4765d06a336ac0f5233c7d1f80 . When I disable it, I don't see a negative effect in desktop or mobile view, only the positive effect of the border displaying again. If someone knows the reason for this property, it would be great if they could switch to an alternative solution that doesn't mess up the table display. If no one knows the reason, I'll comment out the rule in the SCSS file. |
tracker item |
|
Broken icon definition in /template/layout_fullscreen_check.tpl
/templates/layout_fullscreen_check.tpl line 8: Broken icon call. {CODE(Colors="Tiki")} {self_link fullscreen="y" _ajax='n' _icon_name=expand _title="{tr}Fullscreen{/tr}"}{/self_link} {CODE} _icon_name is set to expand, without quotation marks around 'expand'. Whether _title is correct with a starting underscore I don't know. Also, there is no icon named "expand" (with quotation marks), but there is an "expanded", that is redirected to bullet_toggle_minus.png. |
tracker item |
|
Broken images in Newsletters in 12.x (images sent with relative links)
This was working quite well in 9.x: images from article topics, and tracker images were shown in the emails sent by tiki newsletters. In Tiki12, they are not shown anymore (links to the images miss the domain name in the url. Example of url from a missing image (from a tracker item image) in the email: http://img/trackers/cbc123f5818f99ffa55c3befd01d1a65 Images from rticle topics are not included in the email either, it seems. --- Images broken also even if I enable the setting "Add BASE tag in the page HEAD" (in Admin home > Look & feel > Miscellaneous". {sign user="xavi" datetime="2014-03-05T13:11:24+00:00"} --- u: admin p: 12345 To reproduce: * Add your email in the recipients of the newsletter 1 + http://xavi-9794-5162.show.tikiwiki.org/tiki-admin_newsletter_subscriptions.php?nlId=1 * Go to send newsletter 1: + http://xavi-9794-5162.show.tikiwiki.org/tiki-send_newsletters.php?nlId=1 * Add a title and select the "Newsletter template 1" in the dropdown of "Apply content template" ** You will that the homepaeg is shown in the newsletter, with some images. * Click at the button below "Send Newsletter" & "Send" * You will be missing images from article topics and tracker images (image field and file field) ** the only shown image is hte one with a manual inclusion with img src= and absolute url. (the tiki logo in red) |
tracker item |
|
BrowserTitle is empty after upgrading Tiki
I did several upgrade lately from Tiki 15.x, Tiki16.x, Trunk, 15.4 package, 16.2 package and today’s daily from 16.3. Somewhere near 15.4 release something was broken and the browsertitle pref is empty instead of showing previous data at tiki-install.php / Configure General Settings. |
tracker item |
|
Bubble help starts way off screen in wizard
One of the wizards displays one particular bubble help beginning WAY off the browser window, that is Random Header Images on /templates/wizard/profiles_useful_micro_confs.tpl. It starts a couple of hundred pixels outside the browser window, which means that all lines start with invisible (!) sentence beginnings... This is so far the only bubble help that starts off-screen, the others behave normally. |
tracker item |
|
Bug or feature in tra() ?
Is it a bug or a feature, that truncates the output of strings after a pipe symbol? Example to illustrate: /lib/prefs/feature, line 2425: {CODE(Colors="Tiki")} 'feature_wiki_argvariable' => [ 'name' => tra('Wiki argument variables'), 'description' => tra('Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}'), 'type' => 'flag', 'help' => 'Advanced+Wiki+Syntax+usage+examples', 'default' => 'n', 'keywords' => 'arg var vars', ], {CODE} The output of this descriptions stops at the pipe symbol between paramname and default, supposedly in all languages, including English. I cannot translate into German with this entry in custom.php: {CODE(Colors="Tiki")} "Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname|standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}", {CODE} but when I replace the pipe with a slash, all is well: {CODE(Colors="Tiki")} "Allow writing request variables in wiki content using {~np~{~/np~paramname}} or {~np~{~/np~paramname|default}} - special case {~np~{~/np~page}} {~np~{~/np~user}}" => "Argumentvariablen innerhalb von Wiki-Inhalten mit {~np~{~/np~paramname}} oder {~np~{~/np~paramname/standard}} erlauben - Sonderfall {~np~{~/np~page}} {~np~{~/np~user}}", {CODE} So please check whether this is a bug or a feature of tra(), and depending on this check either fix it or change in English this description, to use text without a pipe. Side remark: The pipe doesn't show here, just as the the arguments in double curly braces! Although I enclosed my code sample in CODE tags! ({sign user="Jyhem" datetime="2022-03-03T14:30:00+00:00"} Arguments are interpreted first before anything else. That's what ~np~~~/np~np~nonparsed~np~~~/np~/np~ is for) |
tracker item |
|
Bugs need permission to be viewed
Even though logged in, clicking on http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2538&trackerId=5&show=view (which came up as a result of a bug search) results in the user being told "Error - Permission denied" This should probably not be possible. |
tracker item |
|
Button plugin is asking for plugin approval on templates each time a page is open for the first time
Button plugin is asking for plugin approval on templates each time a page is open for the first time. This is a pain when you use a template to display items, customSearch, etc. It is like I have to scan all the Tiki possible pages and mass approved the plugin changes. I’m extensively using wiki page as template (list, listExecute, customSearch) and have several project built that way (not using smarty templates). It has been discussed that this was introduced in Tiki16 and so far not fixed. |
tracker item |
|
Calendar -Choice to show or hide Group and tools calendar box
I have only one calendar and my users keep asking me what that Groups and Tools box is for. How 'bout a setting to hide this box? |
tracker item |
|
Calendar module
{syntax type="tiki" editor="plain"} Unable to add calendar module Fatal error: Cannot use string offset as an array in /home/tiki/public_html/modules/mod-func-calendar_new.php on line 72 Changi. |
tracker item |
|
Calendar template tiki-calendar_nav broken
The template displays arrows to navigate to the previous and to the next period the calendar shall display, but the template pumps the raw internal values into the tooltips, and even that without translation, breaking the GUI, because "Previous" and "Next" get translated into the target language, but not the period label (e.g. "week") so giving the user a mixture of target language and English that is actual raw Tiki code. {CODE(Colors="Tiki")} {*previous*} <div class="cal-prev" style="display:inline-block; padding-right: 6px; position: relative; bottom: 20px; right: 100px"> <a class="tips" href="{query _type='relative' _ajax=$ajax _class='prev' todate=$focus_prev}" title=":{tr _0="{$viewmode|escape}"}Previous %0 {/tr}"> {icon name="previous"} </a> </div> {CODE} and {CODE(Colors="Tiki")} {*next*} <div class="cal-next" style="display:inline-block; padding-left: 6px; position: relative; bottom: 20px; left: 100px"> <a class="tips" href="{query _type='relative' _ajax=$ajax _class='next' todate=$focus_next}" title=":{tr _0="{$viewmode|escape}"}Next %0{/tr}"> {icon name="next"} </a> </div> {CODE} |
tracker item |
|
Calendar V3.0rc1 preview loses Priority, Category, Location and Participant data
Still a problem in 3.0rc1 If you have a Calendar where the Custom Priority, Category, Location and Participant options have been set, when editing an event if you Preview the edits then the refreshed screen no longer shows these options in the edit area and saving the event loses the data previously typed in. |
tracker item |
|
Calender date picker jquery unlocalized
The calendar uses, when a new event is entered, a jquery date picker tool, to be precise it calls vendor_bundled/vendor/jquery/jquery-timepicker-addon/dist/index.html. In this file I cannot find any localization tr() or tr in curly braces at all, thus all texts displayed like "Time" "Hour" and "Minute" are translated in no local language at all... |
tracker item |
|
Can't remove picture ,can't turn to next page..
{syntax type="tiki" editor="plain"} My tiki site was updated from 2.x to 3.0 . Wiki don't work when i turn to next page in blog/Forum. I found it work when i change & to ? .for example forum13&comments_offset=40 don't work forum13?comments_offset=40 ok change by manual also i find some bug in imageGallery when i want to delete a pic gallery44&remove=730 don't work gallery44?remove=730 ok change by manual hope some guys help me..thanks!! |
tracker item |
|
Cannot create new tracker
Clicking "Create" button brings up pop-up which is lower z-index and thus unclickable than the grayed overlay. Clicking anything closes it again. Unable to create new tracker manually. Seen in FF. {img fileId="955" thumb="y" rel="box[g]" width="640"} |
tracker item |
|
Cannot modify header information - headers already sent by (lang/de/language.php:10965)
lang/de/language.php causes a "Cannot modify header information" PHP error |
tracker item |
|
Cannot Reply to a Comment on Wiki page
I have a comment on a wiki page. When I click Reply to post a follow-up comment, I get an error. It looks like the Reply button is generating a bad URL: __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 |
tracker item |
|
Cannot set/change meta robots setting in Meta Tags Admin 3.0rc1 + problem with keyword options
This is still a problem in 3.0rc1 Sorry - just spotted that this bug ===has already been reported as #2141=== but hopefully the additional information provided here will help resolve this more quickly. You can no longer set/change the meta robots setting in Meta Tags Admin ie the NOROBOTS, NOFOLLOW settings When you fill in the form field and click the Change Settings button the field blanks and viewing the HTML page source code shows that nothing has happened. The "revisit after" field works fine however. Old 1.9 sites work fine and sites that have migrated through to 2.2 from 1.9 have their old values preserved but they cannot be changed. New 2.2 sites cannot have the setting established. Examining the database for a new site shows that the metatag_robots row in the tiki_preferences table is missing. Hacking the table to add the row with appropriate values allows the appropriate HTML code to be generated in the head section of each page BUT the admin form still does not work. Have also now spotted that ticking any of the Meta keywords options e.g the "Insert freetags in keyword list" and changing the settings does seem to set that option BUT the tick box is then blanked and then there is no way to 'untick' the option or you are not sure if it has been set or not. very old bug - now fixed/not relevant |
tracker item |
|
Category Transition not working
When using tiki-admin_transitions.php. If I add a Transition, then tiki will not let me modify it (by Edit) since every icon (i e: Edit) will delete the Transition. Even If I click in "Guards" data (wich appears as a "0"). Also the yellow "Key" icon doesn´t turn green as is supposed to, after setting perms. May be other anomalies. Please help Using Tiki 6.0 fresh Install. New Edit: Since I didn´t find any reference on how to use it, I´m exploring it myself. What I did before I was stopped by this error is: 1. I Set up some Categories 2. Go to the tiki-admin_transitions.php. The Subset Tab is on and it shows me two options: 1. Category 2. Group 3. Click on Category, so it show the availabre Categories 4. Choose two categories, then click Select button. It reloads the page. 5. Click on New/Edit tab 6. Write a label: "New" 7. Chosse From and To options 8. Click SAVE. It goes to the List of Transitions 9. If I click on Edit icon, it deletes de transition and goes to the New/Edit tab, but empty... nothing selected or filled. If I click the Guards (number 0) it does the same If I change to the List, the transitios has dessapeared from it. |
tracker item |
|
Changed names of custom modules will create a new custom
When changing a name of custom module, a new module is being created with all the changes. It should update the existing custom module and not create a new one. |
tracker item |
|
Checkbox in tiki-admin.php?page=login always checked.
{syntax type="tiki" editor="plain"} In tiki-admin.php?page=login, the "Use tracker to collect more group information" check box is always checked, so everytime you change something, the feature is enabled. Kind of annoying to have to pay attention to that all the time. |
tracker item |
|
Cleaning and improving console.php batch:upload command feedback
{CODE()}[root@ip-xxxxx html]# php console.php files:batchupload 5 --confirm <feedback>feedback: Image was reduced: %s x %s -> %s x %s </feedback>{CODE} *HTML feedback is returned when using the console.php: It should be returned without tag. *Un-needed or malformed feedback was returned: If no reduction it should return nothing or something like "Images where upload at original size". *Expected message is missing: Should return something like "n files were successfully uploaded" (can be improved with the files, path and galleryId ?) Is it returned only when all files are images or even if files are PDF (message is not relevant and erroneous) --- *HTML feedback is returned also for tracker:import {CODE()} <feedback>feedback: 9 tracker(s) item(s) updated </feedback> {CODE} |
tracker item |
|
Click twice on "Preview" in tiki-view_forum_thread results an error
{syntax type="tiki" editor="plain"} The error is: Notice: this variable may not be empty: $_POST["thread_sort_mode"] |
tracker item |
|
PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict
See first the box saying "Even better" below. "__PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict__" (was --"Clicking on PluginTogether on a wiki page should provide a CoEdit button next to Edit with the right url for all."--) This would be useful for taking meeting minutes collaboratively in the ((tw:TRM)) and ((tw:TAG)) meetings, both which take precious time from some active tiki community members but with little time to do things properly (wasting precious time in this note-taking task instead of being able to invest it in other areas requiring their help too). {sign user="xavi" datetime="2017-01-12T13:09:23+00:00"} I've been trying to use tiki for many semester with my students at uni but I can't get them to use it with realtime collaboration with ease, so that they move to googledocs. This minor usability change would be probably enough to convince teams to use tiki realtime collaboration feature with plugin togetherjs. Like ourselves when taking notes on a roundtable meeting, or tiki admin group meeting, etc. {BOX()} __Even better__ Even easier for the end user would be to just offer a user that sees the concurrent edition warning box, a link to carry on and convert the session into a togetherJS session in which both users continue writing together. In the backend, tiki would probably: # A new general preference should be added for this new behavior to be enabled # when user A clicks at edit a wiki pageFoo, the url that would be created by PluginTogether is stored in tiki mysql tables somewhere, with a semaphore/flag or similar so that tiki knows that this page has been started edition and the url to allows others to go into the same edition session collaboratively. # when user B clicks at the __Edit__ button of the same pageFoo, while still being edited by userA, userB sees the warning of edition conflict unless userB accepts to request to userA to enter into the collaborative session. # If userB accepts to request that coedition to userA, then UserA would see some warning about that request from userB in some popup/modal/or similar, with the option to accept and get his edition saved and restarted as online collaboration among both, or reject the request, and keep writing himself alone in that page. # therefore, save the edition in place by user A (the one that started editing the page first) # reopen that page for edition for user A with te url adapted to the togetherjs session, and # send user B to the edition session with togetherjs (or alternatively, show userB the same link to open the page for edition). # if userA accepted userB to write together, they both are working with TogetherJS on that page. And in that case, when other users such as userC clicks at edit the wiki pageFoo again, userA gets the same message requesting to confirm to accept new users getting the collaborative session, and when accepted, since the TogetherJS is already on, there wouldn't be any need to restart the edition session with togetherJs since it would be already in that mode. {BOX} --- This is currently partly working in 21.x LTS {sign user="xavi" datetime="2020-04-01T10:32:07+00:00"}: * user is sent automagically to open the session without "Warn on edit conflict" * ... __BUT the together session fails to display the other users being there editing the page concurrently__: ** therefore, a new version is saved, without noticing that the versions will not be seen by each other: -+Edit Conflict triggered+-. To reproduce the updated problem info: Come here with two different browser engines (or one in provate browsing and hte other in normal, as usual to test this feature): http://xavi-9794-6160.show2.tikiwiki.org/tiki-index.php?page=HomePage user1: u: admin p: 12345 user2: u: user p: 54321 # Click on button of the side module "Co-Write with TogetherJS" # Edit homepage as user1 (admin) in browser engine1 (e.g. firefox) # Edit homepage as user2 (user in browser engine2 (e.g. chromium) ** accept the popup asking to join session problem triggered: none can see that the other user is editing the page, saving, moving elsewhere, etc. {img fileId="1397" thumb="box"} |
tracker item |
{img type="fileId" fileId="282" noDrawIcon="n"}