Category: Closed - Completed
The issue is answered/fixed and it is accepted
Show subcategories objects
| Name | Type |
|---|---|
| _htaccess should know which version of Tiki it is for | tracker item |
|
"TermA TermB" searches should be "termA AND termB" not "termA OR termB."
This is the default behavior in search engines like Google Also reported here: [tiki-view_tracker_item.php?itemId=166] and: {QUOTE(replyto=BillMac)} I have found that, if I want to find something on tw.o sites, I should disregard TW's search feature and use Dogpile to look things up. The TW search capability is so weak that it is almost "a missing feature." At the very least, "TermA TermB" searches should be "termA AND termB" not "termA OR termB." The plus/minus markers are fine if you're in the know, but they don't work well either. Using the category/group filters renders a whole different set of answers; not GOOD answers, just different. Without those filters, unauthorized users see parts of pages they are not supposed to see at all. Not a missing feature, a broken feature. Gosh, I hate to be so negative. {QUOTE} Source: ((Major Features Missing in TikiWiki)) |
tracker item |
|
{poll } Does Not Work
After setting up and creating a poll with ID = 1 __Update:__ I was following the examples on the doc site for how to embed a poll. These examples typically are in the following formats. The examples throughout the docs should probably be updated to reflect the what actually works (see solution section below). I am a brand new user and am finding the documentation regarding the embedding of dynamic variables to be wrong in many cases. When inserting any of the following: {CODE()} {poll} {CODE} ''generates junk code in the rendered page'' {CODE()} {poll id=1} {CODE} ''generates junk code in the rendered page'' {CODE()} {pollId=1} {CODE} ''simply outputs pollid=1 in the rendered page'' {CODE()} {poll pollID=1} {CODE} ''ALSO generates junk code! So, it's case sensitive?'' ''Details:'' I have tried several versions (just in case case sensitivity was a problem). This has also been reproduced with and without jQuery turned on. I have insured that the Polls option is available in the Text Field as well. Currently operating as an admin user with all capabilities turned on. The "junk"is essentially html. Turning "Allow HTML" or "Try to covert HTML to wiki" has no effect. I __can__ get other dynamic content to work. |
tracker item |
|
/tiki-mobile.php produces Warning on PHP5
Warning: ini_set() [function.ini-set]: A session is active. You cannot change the session module's ini settings at this time. in /lib/hawhaw/hawhaw.inc on line 1165 |
tracker item |
|
Update Notifier: many versions are misreporting available upgrades
Also, there is a DB error on a fresh install of 10.2 I can't test in show.tiki.org to see if it's fixed in 10.4 --because 10.4 is not available on show.tiki.org-- 10.4 is now available {sign user="marclaporte" datetime="2013-08-14T23:29:31+00:00"} {img fileId="340"} --- In latest 11.x: "Version 0.0 is still supported. However, a major upgrade to 9.0 is available." {img fileId="359"} On another site: {img fileId="371"} On another site: {CODE()}A new version of Tiki, , is available. You are currently running SVN pre 8.4. Please visit tiki.org/Download.{CODE} On another sites: "A new version of Tiki, , is available. You are currently running SVN proposals pre 6.6. Please visit tiki.org/Download." Seen on http://info.tiki.org Last update from SVN (SVN proposals pre 6.6): Friday, January 13, 2012 11:52:30 GMT-5 - REV 39480 Theme: Fivealive - Akebi On another site: [http://irc.tiki.org/irclogger_log/tikiwiki?date=2013-02-26,Tue&sel=150#l146] |
tracker item |
|
11.x: issues with greenvalley theme style
Reproduced in demo: http://demo.tiki.org/11x/tiki-admin.php?page=i18n Central column displays over the right column, and some links are unclickable then. {img fileId="399" thumb="y" rel="box[g]"} In other servers (mine), the css submenus do not show when mousing over the triangle icon, but just the main menu entries are shown. I couldn't reproduce this issue in demo.t.o, but this issue dissapeared once I changed theme style for fivelive-lite, for instance, etc. |
tracker item |
|
12.0 Step 7 of tiki-install.php : "Upgrade fix" is offered even on fresh install
--Need to test latest 12.x and 13.x-- It's fixed in latest 12.x |
tracker item |
|
12.x Fatal error: getField() on a non-object in trackerlib.php on line 726
I created a profile long ago to test nested tracker demo. I applied it, and when reviewing the created tracker items, this is the error I get in a quite white screen (css broken): ^ Fatal error: Call to a member function getField() on a non-object in /var/www/12.x/lib/trackers/trackerlib.php on line 726 ^ I've reproduced it in show. u: admin p: 12345 Visit this url: http://xavi-9794-4888.show.tikiwiki.org/tiki-view_tracker.php?trackerId=2 --- The error comes from a defective profile, as I'm seing right now. However, it would be much nicer if there a more informative type of error reporting to the user that there is some syntax problem in the field definition, etc. |
tracker item |
|
14.x: Comments can't be posted nor edited when codemirror is switched on (or 'disabled but switchable')
!!- Fixed in 12.x If codemirror is switched on, comments can't be posted (12.x). It says as if no content was added in the comment body. Similarly, comments can't be edited if codemirror is switched on (12.x, 13.x). Once highlighting is disabled, comments can be posted again. To reproduce in 12.x, post a comment as admin here: http://xavi-9794-5294.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage (while codemirror is on) {img src=http://dev.tiki.org/display796} The same issue is reproduced in 12.x (still with r52504, Sept 12, 2014) in comments to tracker items, even if the codemirror mode is set to "Disabled but switchable" --- !! still present in 13.x and trunk To reproduce in 13.x, try to edit this comment with the highlighter toggled to on the homepage of: http://xavi-9794-5294.show.tikiwiki.org http://xavi-9794-5294.show.tikiwiki.org/tiki-ajax_services.php?controller=comment&action=list&type=wiki+page&objectId=HomePage#comment-container u: admin p: 12345 {img src="display963" width="600"} --- ^ Regression: In 9.x comments could be posted or edited even if codemirror was on.^ --- Update: issue still present in 13.x in r53262 and in trunk r53255 after it has been fixed by patrick-proulx and same fix applied to 13.x and trunk. Something else must be missing somewhere.... {sign user="xavi" datetime="2014-12-04T07:52:23+00:00"} --- Update 2: issue still present in 13.x with code updated as of January 10, 2015. {sign user="xavi" datetime="2015-01-10T12:43:07+00:00"} --- Update 3: Fixed in 14.x but not in 13.x. Oh well, I close this bug report, since 14.0 will be out very soon, etc. |
tracker item |
|
12.x: Multiple Delete+BanIp for spam registrations (like the feature coded already for Comments)
In a few sites we usually get spam registrations, polluting the user registration tracker, by humans (they type properly the passcode). Every now and then I connect to the site to remove the users registrations (this removes also their user tracker items), and I would like to collect those ip's at the same time to be sent to the banning feature. This type of feature already works nicely for comments: you can enable comment moderation, review many comments at once, select many through their checkboxes, and click at "ban and delete" type of option at the bottom. This collects the ip's of those comments, and sends them for you to the banning feature, allowing you to ban all those ip's with just a few clicks. We need this also for the fake registrations from human-spammers getting in. |
tracker item |
|
12.x: Ratings in articles don't show all options, just a single radio button
12.x: Ratings in articles don't show all options, just a single radio button To see it reproduced, come here: http://xavi-9794-5331.show.tikiwiki.org/tiki-read_article.php?articleId=1 and log in as u: user1 u: user1 ^{img src="display802" width="600"}^ You can also log in as admin: u: admin p: 12345 --- It was formerly working as expected, as it can be seen in the documentation pages: http://doc.tiki.org/Rating#Users_ratings_in_Articles ^{img src="http://doc.tiki.org/display973" width="600"}^ |
tracker item |
|
13.x dev.tiki.org :: print version of a wiki page :: link of wiki page source is incorrect
To reproduce, visit: https://dev.tiki.org/Tiki12 Click "Print": https://dev.tiki.org/tiki-print.php?page=Tiki12 {CODE(caption="Current link")}The original document is available at https://dev.tiki.org//tiki-index.php {CODE} The double // is wrong, and it should send to the page name, not the home page |
tracker item |
|
13.x doc.t.o: apply template to wiki page adds no new content on reload
13.x doc.t.o: apply template to wiki page adds no new content on reload See it reproduced in doc.t.o. , in this screencast: [http://tiki.org/display596|140915_bug_apply_template_wiki_page_ko.webm] ([http://tiki.org/display596]) |
tracker item |
|
13.x Horizontal scrolling on http://dev.tiki.org/tiki-pagehistory.php?page=Tiki12
See: http://dev.tiki.org/tiki-pagehistory.php?page=Tiki12 {img fileId="852"} |
tracker item |
|
13.x suite.tiki.org : The footer is missing since the upgrade from 12.x
{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) |
tracker item |
|
13.x: applying a profile from Profiles Wizard doesn't send the user to the "Step2" indicated in the url (some steps anchors gone?)
13.x: applying a profile from Profiles Wizard doesn't send the user to the "Step2" indicated in the url (some steps anchors gone?) |
tracker item |
|
codemirror not switchable for new comments (but just for comment edition) even if preference correctly set
13.x: codemirror not switchable for new comments (but just for comment edition) even if preference correctly set. In 12.x, codemirror is switchable indeed for new comments, as well as for comment edition {img fileId="798" thumb="y" rel="box[g]"} You can see it reproduced here: http://xavi-9794-5064.show.tikiwiki.org/tiki-index.php?page=HomePage&threadId=1&comzone=show#threadId1 u: admin p: 12345 |
tracker item |
|
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
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} |
tracker item |
|
13.x: Tabs from PluginTabs stopped working when using PluginTracker inside
Tabs stopped working in 13.x, as demostrated after applying the "Voting System" profile, from the Profiles Wizard. See it reproduced here: http://xavi-9794-5317.show.tikiwiki.org/tiki-index.php?page=Voting |
tracker item |
|
13.x: tracker field 'static text' shows description by mistake below the field because that is only meant to be parsed as field content
13.x: tracker field 'static text' shows description by mistake below the field because that is only meant to be parsed as field content. When using PluginTrackerList, the error is now happening, but just when using tracker interface directly. Example: {img src=https://dev.tiki.org/display799} 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 |
tracker item |
|
5 RC1 HomePage Incorrectly lists Profile Features
The RC1 HomePage says ---- __Personal Blog and Profile__ (apply profile now) Setup with many cool features to help you integrate the Social Web and establish a strong presence in the Blogosphere Blog (Full set of blog related features) Image Gallery ''__Calendar__'' RSS Integration Video Log ----- However the Calendar is not installed, so either the doc is wrong or the feature should be added to the profile. |
tracker item |
|
A SheetID is required shown when attempting to edit a sheet with jquery.sheet
Very similar to this bug that was fixed in Version 5: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=3017&trackerId=5&show=view Unfortunately, our host does not support version 5 yet, so I am dead in the water unless this same issue gets addressed in version 4.1 Basically, you can create sheets, but whenever you try to edit them, simply clicking on any of the links (Insert, Remove, etc.) causes a redirect to an error page stating: "A SheetId is required." I haven't been able to import simple spreadsheets either, but that's another issue. |
tracker item |
|
Action buttons missing in 3 themes (Coalesce, Strasa, Ohia) when translating wiki pages
!Latest status, as of 3 Nov 2013: Action Buttons present but Translate From half of side-by-side screen contains nothing. still unresolved as of r.48452 !Action Buttons missing in various themes when translating In 3 of the 22 themes (Coalesce, Ohia, and Strasa) the critical action buttons are missing when trying to translate pages. In 18 themes these button show up. In one theme (Utopias) them are partly off the screen, but present enough to click them. __All screen captures taken from demo.t.o/12.x (this site) on 12 Octover 2013, while the site was running 12.0svn rev. 47983 (of 11oct2013; 12:44 CEST).__ __This situation is reproducible by anyone logging into demo.t.o/12.x/ as admin__, then selecting any page (in the screen captures below, I selected "Page to test translation features"), then either: a. from the left menu, under "Translate Updates" -> "Outgoing" select one of the languages available (currently French and Korean) and click the leftmost button {img fileId="425" thumb="y" rel="box[g]"} (with pop-up description of "update it" in English), or b. click the Translate button, and choose to translate into a new language (one other than the ones for which translations already exist. 1. Here is the way the screen should look like, when updating a translation (theme:Fivealive): {img fileId="422" thumb="y" rel="box[g]"} 2. Here's the way it looks (without action buttons) in Coalesce (same in Ohia and Strasa): {img fileId="423" thumb="y" rel="box[g]"} 3. Here's what it looks like in Utopias (buttons partly cut off at bottom of screen: {img fileId="424" thumb="y" rel="box[g]"} As one can also see, in ALL themes, the titles of both the left and right parts of the screen overlap, i.e. the left part does not wrap in its half, but this is a relatively minor irritant. The missing buttons prevent users using the system with the themes that don't work. olaf-michael stefanov (omstefanov), 12 October 2013 |
tracker item |
|
Add a link between the menu management and the admin panel about menus
Admin -> General -> Navigation |
tracker item |
|
Add memcached support, with admin panel
Support.mozilla.com solution or http://framework.zend.com/manual/en/zend.cache.html http://framework.zend.com/manual/en/zend.cache.backends.html#zend.cache.backends.memcached |
tracker item |
Since Tiki4, in tiki-admin_include_sefurl.php, Tiki detects if .htaccess is there and if contains tiki-index.php?page=$1
But:
If Tiki is upgraded, by installing over, there may be issues because Tiki is still using the old .htaccess without informing tiki admin
Proposal:
Have Tiki version number in _htaccess (and thus updated as part of the release procedure)
Test on this, and inform users when they forgot to upgrade their .htaccess file.