Category: 14.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

Currently, there are four preference filters available in the Control Panel interfaces: "Basic", "Advanced", "Experimental" and "Unavailable".

As a user new to Tiki, I have on several occasions noted features that looked interesting, but which I have not enabled as I have subsequently found it is planned to deprecate them. In some cases this was obvious (e.g. a 'warning' icon with the deprecation message on hover next to the feature checkbox), in others it wasn't (i.e. I only found out about it from doc.t.o or related places).

On the assumption that it will help with planned deprecations if new installations don't enable and start using deprecated features, I would propose that a "Deprecated" preference filter be added, that relevant controls be assigned to it, and that it be disabled by default in new installations.

I understand the criteria for such might be controversial (indeed, I hope I'm not reigniting a heated discussion by posting this!) and so would understand if this is WONTFIXED. I also recognise that it is less appropriate for a new user to suggest criteria here than for those that have had Tiki installations for some time and/or are directly involved in development, which is why I haven't listed any in this initial report.

Currently, Plugin LastMod displays the date and time a page was modified using the server's "Long Date Format" and "Long Time Format". While this is fine as a default, there are no parameters that allow this to be overridden (or at least, [https://doc.tiki.org/PluginLastMod|the documentation] doesn't show any).

I would like to suggest this be changed, and present two potential avenues to doing so:
#Provide parameters that allow to use either the 'long' format, the 'short' format, or to switch 'off' the date and time components respectively.
#Provide a parameter that allows to specify a custom date and time format string.

Add filter param to Plugin TrackerStat (to easily display graphical bars of tracker item answer counts from filtered results)

((doc:PluginTrackerStat)) is an easy way to display results from data in trackers. Trackers can be used to produce advanced custom surveys, and we could use on e single tracker to collect data from different semesters, years, projects, etc., but provide a simple interface to show a filter before showing results of bars with counts, etc., so that the use can choose in a central point which fields wants to use to filter data from a tracker.

This might be solved someway with plugin list and custom search and some tricky advanced display output or format syntax, but this in currently (as of April 2015) undocumented, and even if this might be feasible by experienced devs, it's not going to be as easy for endusers to be reproduced than just using the easy TrackerStat plugin with a new filter param, (similarly to the param filter in PluginTrackerList of TrackerFilter)

---
See some show instance with a call to TrackerStat already in place, if you want a snapshot of a working instance as a base tiki to get your development tests going.

http://xavi-9794-5261.show.tikiwiki.org/tiki-index.php?page=HomePage
u: admin
p: 12345

add history & rollback capabilities to structures (record dump somehow when struct. changes, or allow saving structure dump for backup...)
This way, when the structure gets mixed by machine or human error, the structure can be rolled back to the previous state.

This way, we could be more open for registered users to manage http://doc.tikiwiki.org/Documentation (or others) without the risk of failure when nodes get moved to the wrong place (due to some bug in the code). Or due to mistake by benevolent newbies mixing things without bad intention.

---

UPDATE: Still desired for some LTS version. {sign user="xavi" datetime="2013-11-17T09:31:50+00:00"}

Please see:
http://tiki.org/forumthread50251

It took me a while to figure out how to unsubscribe to the frequent "Make a wish" mailings. We should put this link at the bottom of those mailings:

To modify your watches, please visit:
https://dev.tiki.org/tiki-user_watches.php

Thanks,
Pete

It took me quite a while to figure out where the "unsuccessful login attempts" options were.
https://doc.tiki.org/Login+General+Preferences

I think some additional admin panel search terms might include:
"brute force"
"brute-force"
"login failure"
"login-failure"
"failed logins"

Thanks!
Pete

Right now, if you have a multitiki installation with 10 sites, and you want to rebuild the unified search index for them all, you have to run 10 times the command with the "--site=" para adapted to each case.

However, when you run setup.sh, by default setup.sh runs for all sites in a multitiki installation.

It would be nice if console.php had the chance (by default or not) to be run once for all sites in that multitiki installation at once


with some param like "--site=all":
{CODE(colors="shell")}
php console.php d:u --site=all
{CODE}

{syntax type="tiki" editor="plain"}
It would be lovely to set some new user defaults at
* Admin (home) > Login > User defaults, and/or
* Admin > Groups > (Edit a single group)

The ability to Subscribe/watch/monitor new users in the site or to that specific group, to specific Tiki objects.

Which tiki objects?: I would say, in this order:
# specific forums
# specific blogs
# specific calendars
# specific newsletters (ML: we can already subscribe groups to newsletters)
# specific wiki pages
# specific structures
# specific trackers
# specific categories
# new articles

This is specially useful for new users of the site, where they don't know yet how to subscribe to specific areas, etc. Very needed for educational scenarios, but I can see many other places where new users are a bit lost for some time while they learn how to use the Tiki site.

Related:
*[wish988|Forum: Let forum admins/moderators add groups and/or users as watching the forum]
*[tiki-index.php?page=Business%20Plans|Let small business start ups access collaborative sharing where the document being shared is not visible by anyone else]


Anywhere there is a watch eye, it should be possible for an admin to have group members watch this category

When codemirror is on and its default mode is set to "Off (but switchable)", the end user expects to see a button available in tracker item textareas (like in dev.t.o/t5 bug tracker).

But it's not available still.

To see it reproduced:
Log in here:
http://xavi-9794-5064.show.tikiwiki.org/tiki-index.php?page=Contact_us&itemId=1
u: admin
p: 12345

Codemirror has been set to on (with default theme). If you edit the "Contact_us" page you'll see the content highlighted.
However, no highlighting in the tracker text area field.

Maybe the best option would be to allow the tracker admin to set an option for text areas to include the button to toggle the "highlighter" upon user request (as with text areas in wiki pages).
This way, codemirror could be set to "Disabled but switchable" (default preference in new installs), and each user could decide whether to enalbe highlighting in that text area or not (to prevent side issues in some cases with codemirror on, from happening always in all text areas, etc)

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

Allow using D(yyyymmdd hh:mm) to hardcode dates in Plugin Convene thorugh direct wiki page edition

Regarding this type of syntax to set date and times, you can see:
http://profiles.tiki.org/Date+Conversion

I tried using this code below, which is the code that I would expect to work, looking at the other syntax with unix timestamps, but it didnt' work here: [http://xavi-9794-5426.show.tikiwiki.org/tiki-index.php?page=HomePage] (u: admin, p: 12345):
{CODE()}
{CONVENE(title="Convene" calendarid="1" minvotes="3")}dates_1408118400_admin
dates_D(20140815 21:00)_admin
{CONVENE}
{CODE}


See also a related issue reported with Plugin Convene:
* "Site timezone is not respected when using Plugin Convene (time stored as 2 hours before my selection) "
+ http://dev.tiki.org/item5425
+ which might be a duplicate of:
* "Timezone and convene plugin"
+ http://dev.tiki.org/item4783

The current ElasticSearch Implementation is very nice but I noticed that it is impossible to specify wildcard search (term*).
This may not be a big deal for englisch users but in languages like german, we combine our words to form new ones. Example: Hoch (high) + Haus (house) = Hochhaus (Skyscraper).
You can imagine that a lot of searches fail because people expect to be able to search for substrings.

Alternatively allow us to manipulate the tokenization of the words by syllables or a dictionary.

http://doc.tiki.org/PluginArticles

Currently, there's no option to display the comments of article when using PluginArticles

This is just a test

Use case:
* You have content templates enabled, and revision approal system set for wiki pages.
* You create a new content template "MyTpl" based on a wiki page, under revision approval.
* MyTpl Version 2 is approved. Version 3 is the last edited version of the content template, with no approval yet.
* You create a new wiki page "MyPage", apply the template MyTpl, and you get applied v3 (non approvaed), instead of V2, which is the approved one and should be the one applied by default.

To reproduce, log in as admin:
u: admin
p: 12345
Wiki page:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-index.php?page=MyPage
Template:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-index.php?page=MyTpl
History of versions of the wiki page template:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-pagehistory.php?page=MyTpl

See that last approved version is v2, but there is a v3 which has more content.

Edit the wiki page and try to apply the template:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-editpage.php?page=MyPage

V3 is applied instead of v2 (the last approved version)

This is flagged as a regression but it is in both 12.x and 13.x so may be an old bug ....

... but when a newsletter previously created with the wysiwyg editor (ie it has had the various HTML flags set), it shows the raw html when it is retrieved from the archive for simple viewing - but it is OK if retrieved for immediate resending

.. just to confirm that this is still a bug in Aug '15 at r 55993

When viewing articles in list, the number of reads is not displayed anymore (option: art_list_reads) on new articles since Tiki 13. Tiki 12 has no problem.

The bug was introduced in revision 49060. New articles now have tiki_articles.nbreads NULL rather than 0.

{img fileId="1049" thumb="box"}

When using an article topic image (png/jpg) it shows (tiki-view_articles.php) in recent Firefox (40.x) and Internet Explorer (11.x), but not in recent Google Chrome (45.x). This is tested on windows7/8.x. The fault is also experienced on Android 5.1/Chrome (updated Sony Xperia Z3). The fault is experienced with tiki 14.1svn rev 56180 and demo.tiki.org/14.x

The biggest consequence is that article topic images may not be shown on recent Android/Chrome. This might be a severe fault if topic images is used to communicate article importance.

I expected the article topic image to show ;-)

The obvious workaround is to use a different browser, but that is maybe not the first an Android user will try.

It's probably easy to fix since it is related to how Google Chrome (fails to) interpret the image, while FF and IE does.

{img fileId="1002" thumb="y" rel="box[g]"}
{img fileId="1003" thumb="y" rel="box[g]"}

Using tw.o forums and 2.0 (afaik):

You add a screenshot attachment to a reply in a forum post, and if you click on "preview" first, (as you would do on wiki pages), the image is lost (no tag is inserted on the forum post to help you link the attachment).

However, if you do the same attachment on a post, and click to post it (without previewing it first), the attachment link is shown.

Example at tw.o forums where it recently happened:
[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=29608&thread_sort_mode=commentDate_desc&was_queued=n]

---
according to comment added to this bug report, this issue is still present in branch Tiki5 still (so probably also in trunk)
---
Unbelievable, bug still present in forum posts in 12.x since 1.x! (with forum replies, there is warning, at least, but not yet with brand new posts in the forum and attachment is lost indeed) {sign user="xavi" datetime="2013-11-22T09:45:52+00:00"}

Reproduced here:
http://xavi-9794-1986.show.tikiwiki.org/tiki-view_forum.php?forumId=1
u: admin
p: 12345

Content templates very usefully allow complex/rich formats to be pre-established for Wiki pages etc - but if there are a number of users with full 'editor' permissions it would be very useful to be able to put individual Content templates under a 'change control' process where only one individual (and the admin) can change/update it, ===and=== to be able to segment the access to a large number of content templates by an individual Category.

Being able to 'lock' a template in the same way as a Wiki page etc is assumed to be a simple way of achieving the 'lock' request but there may be better ways of achieving the effect.

Adding a Category function may have some more 'interesting' consequences since some thought should be given as to whether the categorisation is inherited by the wiki page/newsletter or whether the template, whilst only being available to a user with the right category permissions, should then just be pasted into the edit screen and the resultant page categorised as required.

update June 2013 - still a very useful Feature Request !

When I use "Translate this page to a new language", I get a blank page after clicking "complete translation" or "partial translation".

This is a Bootstrap Sandbox instance using the Default Tiki Theme.

Issues can be reported here:
http://themes.tiki.org/tracker2