Category: 9.x

The ~046~~046~~046~page~046~~046~~046~ plugin can't be escaped, neither with a CODE plugin nor with the ~np~~np~~/np~~/np~ syntax.

{img fileId="270"}

Visit these pages to see for yourself:
http://info.tikiwiki.org/Hosting (6.x)
http://profiles.tikiwiki.org/Profiles_in_installer (9.x)
http://dev.tikiwiki.org/Tiki13 (12.x)


It should be a redirect 301. And needs to work for 6.x, 9.x and 12.x

This worked when the feature was introduced so some other fix / enhancement must have broken it.

This is especially not good because in this version the ((canonical)) link is just relative and thus, we have two canonicals for same page...

If you go to front page, it redirects OK
http://info.tikiwiki.org (6.x)
http://profiles.tikiwiki.org (9.x)
http://dev.tikiwiki.org (12.x)

9.x - trunk: Can NOT export fields nor synchronize a big tracker

Smaller trackers seem to be fine with exporting tracker fields.
But with this one, no content is shown in the popup box where the exported fields should be shown.
Somehow I managed to replicate this issue in my localhost in a Tiki 11.x, and I see this error message then:
{CODE()}
Request-URI Too Large

The requested URL's length exceeds the capacity limit for this server.
--------------------------------
Apache/2.2.22 (Ubuntu) Server...
{CODE}

This seems to be related to these two apache directives, that I didn't manage to change in my localhost (or at least, the error didn't dissapear):
# http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline
# http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

Show instance created.
U: admin
P: 12345
To reproduce, try to export all or any of the 167 fields here:
http://xavi-9794-4756.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1

---

I tried also exporting the whole tracker, fields and data through the tracker synchronization feature (), but After I click at the button to "search the trackers to clone" (or similar), at teh remote tracker duplication step, then I get this fatal error page:

{CODE()}
Fatal error: Uncaught exception 'Zend_Http_Client_Adapter_Exception' with message 'Read timed out after 10 seconds' in /path/lib/core/Zend/Http/Client/Adapter/Socket.php:511 Stack trace: #0 /path/lib/core/Zend/Http/Client/Adapter/Socket.php(329): Zend_Http_Client_Adapter_Socket->_checkSocketReadTimeout() #1 /path/lib/core/Zend/Http/Client.php(1075): Zend_Http_Client_Adapter_Socket->read() #2 /path/lib/core/Services/RemoteController.php(57): Zend_Http_Client->request('POST') #3 /path/lib/core/Services/RemoteController.php(26): Services_RemoteController->getJson('list_trackers', Array) #4 /path/lib/core/Services/Tracker/SyncController.php(266): Services_RemoteController->__call('list_trackers', Array) #5 /path/lib/core/Services/Tracker/SyncController.php(266): Services_RemoteController->list_trackers() #6 /path/lib/core/Services/Tracker/SyncController.php(280): Services_Tracker_SyncController->getRemoteTrackerList('http://ueb.vhir...') #7 /path/lib/core/Services in /path/lib/core/Zend/Http/Client/Adapter/Socket.php on line 511
{CODE}

Any help to get the tracker exported, by any means, to another Tiki install?

__Update:__ Clarified some of the description below.

^Please note this field type is marked "experimental" in 12.x^

[http://doc.tiki.org/Action+Tracker+Field|Action Tracker Field] type does not work in Tracker plugin.
I have tried it but no button appears labeled "Reset" on the action field row next to the "Reset Password" in the table.
To reproduce:
General > Name: Reset Password
Options for Action > Name: Reset, Post: get, Script: tiki-remind_password.php, Parameters: name:userName

{img fileId="941" thumb="y" rel="box[g]" width="320"}

__It should render a post or get form or just a button labeled "Reset" pointing to tiki-remind_password.php__ but renders nothing in the Tracker plugin. Maybe it should render below the tracker form in the code to avoid ''form in a form'' conflict and be placed on the row position of the field using jQuery?


It only shows up (while editing the Tracker item) in a special section called
"__Special Operations__".

But clicking the button from there is buggy too. Goes to:
tiki-remind_password.php?name%3AuserName=name%3AuserName&trck_act=Reset

Instead of:
tiki-remind_password.php?name=admin&trck_act=Reset

Trackers are great in Tiki, it provides a way to build quick and easy register solutions.
When used in any context related to monitoring, it would be nice to have a way to associate a record with one or more events in time. For instance you would like to receive an email at the time the issue related to the task should be controlled and/or be resolved.

Thinking on it as a feature, the following could be considered in the solution:
*It could exist more than one "timer" in the tracker record,
*It should be added like any other tracker field to the record definition,
*It could have different ways to alert: email, rss, ... (maybe only one choice when instance),
*It could have rules, like auto disable when the record is closed (or other condition),
*It could be (as an option) reprogrammed,

and also
*Maybe a user wants to know about all his/her pending "timers".
*Maybe timer implementation could be independent objects that are linked to (special fields in) tracker records (or other objects), so global management is possible.

I guess that a good part of above functionality is already in Tiki in some form.

If you add an event and set it to all day the event appears on the day before, and if you have fullcalendar enabled, also the day you chose.

This is likely to be to do with timezones, my tests are with the server (php), the tiki pref and the user all being in UTC. Will try to reproduce on show.

The subject says it all.

Cannot demonstrate 9.x on show.tiki.org anymore. Demonstrated 12.x where it seems to be fixed but 9.x is still LTS so should be fixed there too, right ?

If a valid wikilink is included within a comment on a wiki page, that link is reported by BACKLINKS on the page being linked to.

{CODE(caption="Test_MRB_01")}This page uses the BACKLINKS plugin to show pages with links to it -
{BACKLINKS()}{BACKLINKS}{CODE}

{CODE(caption="Test_MRB_02")}This page has three source lines, the second of which is a comment.
~tc~((Test_MRB_01|This link to Test MRB 01 is in a comment))~/tc~
This is the third line, but only two lines visible when viewed.{CODE}

We are working on some pages, their names being regularly changed, thus their links.

It might be great if it would be possible to have an easy access to pages via their page_ref_id. I can list the page_ref_id in tiki's listpages, but when I use it to build a (more permanent) link, this doesn't work.

For instance it might be, in /tiki-listpages.php, when you use the option show page ID, to have links to wikipages by clicking on their page_ref_id (currently it's the same link as for the page name).

Also, when I do it manually editing the link, like this:
[https://wikispiral.org/tiki-index.php?page_ref_id=155] (the page 155 exists), it gives me it's 404ing.

When I put the page with an alias in a structure, then appears the page ref id, and the number here is different that the one in listpages ???

Is there something I missed ?

{syntax type="tiki" editor="plain"}
We have to move our tiki to a new provider because of the PHP memory limit. No problem, but we will only have an SSL proxy, but no own SSL domain.

Now I am testing: especially admin pages do not work. They use absolute links sending me not to https://ssl-proxy.com/mydomain.tld/adminpage.php, but to https://ssl-proxy.com/adminpage.php. Obviously this does not work.

As a first workaround I did two changes:
- in /lib/smarty_tiki/block.selflink.php I changed in line 44 $default_type from 'absolute_path' to 'relative'.

- in lib/smarty_tiki/block.title.php I changed in line 40
'_type' from 'absolute_path' to 'relative', too.

But now I had another broken link when removing an item from a menu. As it seems the problem cannot be solved by just changing one or two lines.

Is there a feature I do not know to solve this problem or is it a bug?

{syntax type="tiki" editor="plain"}
Can't remove any items from a Wiki Structure directly after adding it to the structure. HTML/NULL error.

The bug was originally discovered on doc.tiki.org. I thought this could be due to the large volume of items we have in that Structure but I was able to reproduce the bug on a simple instance of Show.

Selecting a plugin alias (tiki-admin.php?page=textarea) and clicking "delete" gives a error (blank page) and nothing happen.

I've had this issue with different tiki versions:
9.4 (production website, using tiki since 2005)
9.4 (test website, fresh install)
9.6 (test website, updated from a 9.4 fresh install)

I could no reproduce it on tiki 9.4 on show.t.o, but I just tried a 9.3 instance, and I get the issue back with the following error message:
{QUOTE()}Fatal error: Call to undefined method ParserLib::set_preference() in /var/www/pianoliv-11386-4715/lib/parser/parserlib.php on line 701{QUOTE}

Categories are not assigned like they are asked to in the group settings.

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

Group chosen is not auto assigned.


Categories are also not assigned like they are asked to in the Staging and Approval settings. I will be told I am creating a staging document, it will add the prefix, etc. However, it will not move it to the chosen staging category.

I have tried this with fresh installs of 4.1 and no profile loaded during initial setup.

{sign user="pascalstjean" datetime="2013-08-18T18:40:57+00:00"}

There is no bug since you need to use blog post as the filter type. With that being said, there should be that option when using the Plugin. Currently it only shows blog



----
Using the __category__ plugin:

~np~{category id="2"}~/np~

correctly shows blog posts in the category.

But... using

~np~{category id="2" types="blog"}~/np~

does not!

See SHOW instance

I wish the wonderful multilingual features that the Wiki side of
TikiWiki has were available/applied consistently throughout the Tiki package.

So, it works really well to view wiki pages in your own languages,
translate into others and keep these in sync collaboratively.

While you stay in the Wiki side of things.

As soon as you leave to use files, forums and FAQs etc. etc. multilingual is patchy at best.

I'd like to be confident that whatever feature I enable, its possible
for all content in that feature to be truly multilingual.

I have stumbled upon a problem when a feature (especially Hotwords) is enabled it creates lot of issues incorrectly parsing the content of Wiki pages and other parts of Tiki where wiki or smarty syntax is involved resulting in links inside rendered HTML attributes or WSODs. So here is my wish:

It would be super useful to have a plugin which would prevent some enabled features auto-parsing or allow parsing of its body depending on params, something like:

__The next example would prevent (ignore) parsing of the Hotwords and CamelCase WikiWords in the plugin body.__

{CODE()}
{PARSE(ignore="feature_hotwords:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

__The next example would allow only parsing of Wiki syntax and WikiWords and nothing else in the plugin body.__

{CODE()}
{PARSE(only="wiki_syntax:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

Other candidates for the "ignore" and "only" params:
feature_wiki_allowhtml
feature_autolinks
feature_wiki_argvariable
feature_wiki_paragraph_formatting
smarty_syntax
wiki_plugins (meaning all wiki plugins)
wikiplugin_div (meaning specified wikiplugin)
etc.

I think it would be useful also for the LTS versions.

Anybody takes the challenge ?

{sign user="luci" datetime="2013-12-12T20:48:49+00:00"}

http://info.tiki.org/demo promotes the demo sites.

And a lot of people use so they are __very messy__. After a while, they become unusable. And a bad impression of Tiki.

In the past, it was important to keep the demo sites for a certain time because people would use them to demonstrate bugs. But now that we have ((tw:show.tiki.org)), it's no longer important.

Ideally, there would be a pop-up or something indicating when the next refresh will happen. Otherwise, some people may have data reset while they are working on it. But in practice, this is quite rare. As long as hour of refresh is indicated on demo.tiki.org, it's good. So a daily refresh would be OK I think, but it could also be weekly.

Once the demo site is refreshed, the script to set the password to 12345 should be run. And users should not have to go through the admin reset routine. So beyond setting the password to 12345, the script should do what it takes for Tiki not to think the admin password needs to be changed. This is a problem we have on ((show.tiki.org))

Thanks to this:
http://doc.tikiwiki.org/Forum+and+List+Synchronization

This:
http://sourceforge.net/mail/?group_id=64258

Should be mirrored here:
http://tikiwiki.org/tiki-forums.php

For 9.x and up.

Request ability to add to a wiki a spoiler.

Its very useful in a HowTo environment where the spoiler will hide code that needs to be copy/pasted so the presentation is neat.

Example:
When installing my widget, you might need to copy this code to your settings:

[spoiler]
BsetMultipleConfig
1001x1101
settings.ini
threebot4
0x32
0x64
[/spoiler]

The spoiler has a button allowing the user to click on the button so the user can copy/paste the code inside the spoiler. The user can also click on the spoiler for a second time to close it; allowing easy reading and hiding it when not needed.

When the TRACKERITEMFIELD plugin is called trying to access a tracker item which does not exist, a fatal error like the following occurs:
{CODE()}
Fatal error: Call to a member function getConfiguration() on boolean in C:\xampp\htdocs\tiki\18\lib\core\Tracker\Item.php on line 200
Call Stack
# Time Memory Function Location
1 0.2009 192464 {main}( ) ..\route.php:0
2 0.2617 4607672 include( 'C:\xampp\htdocs\tiki\18\tiki-index.php' ) ..\route.php:306
3 0.5479 18560680 Tiki_Render_Lazy->__toString( ) ..\route.php:645
4 0.5479 18560712 call_user_func:{C:\xampp\htdocs\tiki\18\lib\core\Tiki\Render\Lazy.php:22} ( object(Closure)[521] ) ..\Lazy.php:22
5 0.5479 18560752 WikiRenderer->{closure:C:\xampp\htdocs\tiki\18\lib\wiki\renderlib.php:346-356}( ) ..\Lazy.php:22
6 0.5480 18560984 WikiLib->get_parse( string(16), bool, ??? ) ..\renderlib.php:349
7 0.5484 18565728 WikiLibOutput->__construct( array(34), string(58), array(3), string(1) ) ..\wikilib.php:802
8 0.5484 18566056 ParserLib->parse_data( string(58), array(3) ) ..\wikilib.php:2155
9 0.5485 18568760 ParserLib->parse_first( string(58), array(2), array(2), ??? ) ..\parserlib.php:1667
10 0.5537 18774536 ParserLib->plugin_execute( string(16), string(0), array(3), long, bool, ??? ) ..\parserlib.php:439
11 0.5562 18785784 wikiplugin_trackeritemfield( string(0), array(3), long ) ..\parserlib.php:1031
12 0.5670 20145512 Tracker_Item->canView( ) ..\wikiplugin_trackeritemfield.php:193
13 0.5670 20145664 Tracker_Item->canSeeOwn( ) ..\Item.php:88
{CODE}

Objects which contain such calls cannot be viewed, and reindexing for search is also broken.

This happens since {commit id=37583} and persists in trunk r68584.

{syntax type="tiki" editor="plain"}
I want to use backlinks in File Gallery to show me what wiki pages reference the files. This is how I can identify orphaned files. However, this function is so broken that it is unreliable.

What I would expect from this feature is the following behaviors:
#Each file referenced in a wiki page has a single backlink to that page recorded in the File Gallery that contains the file
#Backlinks to wiki pages are uniquely indexed, so that even if there are numerous references to the same file on a page, there is only one backlink to that page shown in the File Gallery, rather than multiple backlinks to the same page
#Removing a reference to a file from a page will remove the backlink to that page from the file in the File Gallery
#Deleting a wiki page will delete all backlinks to that page in the File Gallery

The behaviors I have been able to duplicate in the demo wiki ([http://demo.tiki.org/11x/tiki-list_file_gallery.php?galleryId=6]) are as follows:
#Linking to a file in a wiki page will create a row in the ''tiki_file_backlinks'' table for that page in the File Gallery every time you save the page, even if there is already a row for that page
#If you edit the page and then save it, the backlinks to the referenced files are sometimes incremented, and sometimes not
#Removing the link to a file in a wiki page and then saving it ''does not remove the backlink'' in the File Gallery to that page
#Completely removing a page from the wiki that is referenced by backlinks in the File Gallery will not remove those backlinks, but will instead leave orphaned backlinks to non-existent pages
#There is no reindex or cleanup function built into Tiki for File Gallery backlinks, and no way to manually fix or remove bad backlinks (other than directly editing the database tables)

We should have some ready-made zones, where template designers can just

It should be possible to populate these zones with Site Identity or in the templates.


Please examples of floating boxes here:
http://www.jtricks.com/javascript/navigation/floating.html
http://www.phpletter.com/Demo/Jquery-Floating-Box-Plugin/

It could also be pull out thingies or horizontal bars

tiki-forum_rankings.php is broken since Tiki 4 due to its usage of function forums_ranking_last_topics(), which was removed:
Fatal error: Call to undefined method RankLib::forums_ranking_last_topics() in /var/www/tiki/6.x/tiki-forum_rankings.php on line 70

or

Fatal error: Call to undefined method RankLib::forums_ranking_last_topics() in /var/www/tikitrunk/tiki-forum_rankings.php on line 72

The method was removed in r20573.

At https://tiki.org/Demo
The Demo instances for 16x and 9x are no longer available.

16x shows Internal Error 500
9x shows url no longer available.