Category: Closed - Completed

Goal: to add a way to represent relevant data in a timeline.

This will most probably be done by re-using an existing library and/or service.

Let's coordinate here: ((TimeLine))

Toolbar setting done on Tiki-admin_toolbar.php are not applied on wiki page.

Go to http://demo.tiki.org/11x/tiki-admin_toolbars.php
I have removed on purpose "B" (bold) button on global wysiwyg.

Create or edit a page it is still in place.

~~#F00:Note: ~~It in the db the tiki-preferences got a field "toolbar_global" and the value reflect the changes i made. Still they are not applied.

Tracker field descriptions aren't parsed when used out of PluginTracker even if field checkbox is set or that
You can reproduce applying profile "Tracker_as_calendar_12x".
When you attempt to add a new item to the trackercalendar through the fullcalendarresourceviews interface, description of location field is not parsed.
But if you attempt to add through the extra tab in that wiki page, where PluginTracker is being used, that field desc is shown parsed.

To be used with Google Maps & Tiki Maps to show locations of tracker items.

For example, the venues of phpbeer.com:
http://phpbeer.com/tiki-view_tracker.php?trackerId=1

Tracker fields of Radio buttons and multiple selection pre-select value 0 when it's one of the options even if not manually set as default

Set as options for that tracker field: 1,2,3,4, and no value is pre-selected (expected behavior)

Set as options for that tracker field: 0,1,2,3,4, and value 0 is pre-selected (wrong behavior; no value should be preselected, since no value is repeated twice)

Workaround (for radio buttons): 0,1,2,3,4, ,
(note that a space is set as option, twice, after value 4).

For multiple selections this workaround is not valid, since value 0 is also pre-selected.

Reproduced here:
http://xavi-9794-5599.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=1&cookietab=2

u: admin
p: 12345

See fields 5 (radio button) and 6 (multiple select)
---
{BOX()}
Update: {sign user="xavi" datetime="2015-03-26T09:37:35+00:00"}
Bug still alive, it seems jonny. I svn-up'ed to Thursday March 26, 2015 09:25:10 CET - REV 54744, and new items from your new tracker show a default value of "0" preseleected for the radio button, even if no value should be pre-selected according to the configuration.
See:
http://xavi-9794-5599.show.tikiwiki.org/tiki-ajax_services.php?controller=tracker&action=insert_item&trackerId=2&modal=1

And the radio button field definition ([http://xavi-9794-5599.show.tikiwiki.org/tiki-ajax_services.php?trackerId=2&fieldId=9&controller=tracker&action=edit_field]) still has as options: "0,1,2,3,4", so no pre-selection is expected, but "0" is pre-selected.
{BOX}

Records are not found when using the trackerfilter plugin where the filter field is an ItemLink field where the contents are 'created' from multiple fields in the source tracker.

A 12.x 'show' has been set up to demo this bug - but it is also a problem in 13.x as well

---

Added quote below ({sign user="xavi" datetime="2014-04-30T09:30:43+00:00"}) as extra info was provided in the devel list:
{QUOTE()}
(...) definitely a regression as I have a production site where it used to work. I can't be sure when it stopped working but the site was built with 10.x so it was OK then and the site is now on a 11.x daily build from 4Sep'13 and it doesn't work anymore - only realised it when I used the site data to test the latest 12.x
{QUOTE}

There's a problem with the trackerlist plugin output sometimes not displaying due to an inline "visibility:hidden" rule, when Table Sorter isn't being used.

This is the syntax for the plugin:

{CODE()}{trackerlist trackerId="5" fields="26:27:30" showlinks="y" shownbitems="y" status="opc" max="-1" sortable="y" tsfilters="y"}{CODE}

With Table Sorter activated, no problem, when

sortable="y" tsfilters="y", ok (and table sorter gadgets showing)
sortable="n" tsfilters="n", ok (and no sorter gadgets)
sortable="y" tsfilters="n", ok (legacy sorter gadgets showing)
sortable="n" tsfilters="y", ok (and no sorter gadgets)

But with Table Sorter deactivated, when

sortable="n" tsfilters="n", ok (and no sorter gadgets)
sortable="n" tsfilters="y", ok (and no sorter gadgets)
sortable="y" tsfilters="n", no display
sortable="y" tsfilters="y", no display

So it seems with Table Sorter off and sortable set to y in the trackerplugin, there's a problem. This inline rule comes from line 64 of wikiplugin_trackerlist.tpl.

{CODE()}<div id="wptrackerlist{$listTrackerId}-{$iTRACKERLIST}-div" {if $tsOn}style="visibility:hidden"{/if} class="ts-wrapperdiv">{CODE}

If I comment out the inline CSS and its if statement, the trackerlist table appears normally in all the cases that I tested. Seems like there must be an error here unless there is some case where the trackerlist table would need to be hidden, which seems unlikely.

When creating a new Tracker, i cannot set categories. They are visible as checkboxes but not selectable.
Only checkbox "Auto-create corresponding categories" is selectable.

I put it to blocker because assigning permissions (categories) to tracker is essential.

I guess its easy to solve because it might be related to the bootstrap issue fixed in https://dev.tiki.org/item5500



__Testcase__:
user: admin
password: 12345
http://wolfganga-11730-5504.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1

__Update: Since this bug is fixed i removed the testcase instance__

Hi,

I've put on the wiki hompage an {RSS} module, a list of the site's last modified wiki pages. Tiki-Mobile correctly generates the RSS list, but the links are non-mobile.

Is it possible to force mobile mode?

Compare these 2 pages:
http://tiki.org/Community
http://next.tiki.org/Community

Go to the section "Contributors to this page" and mouseover the names one by one: Torsten Fabricius , Marc Laporte , Rick , Oliver Hertel , ...

On my user information I entered (a long time ago) my "User's Homepage" and it is displayed here : https://dev.tiki.org/user11581

But I can't find a way to change this information.

{img fileId="297"}

Tiki newsletter works well for small volumes.

But for large volumes, as with any web app, sending emails from a server can be a challenge. Risk of being flagged as spammer, high server load/difficult to throttle, limits from your web hosts (ex.: max x emails per hour), etc

A helpful alternative would be something like this:
https://addons.mozilla.org/en-US/thunderbird/addon/4883

So my Thunderbird client or desktop newsletter application (ex.: [http://gammadyne.com/mmail.htm|Gammadybe Mailer]) should be able to access the TikiWiki database to generate recipient list.



---

Another approach is to make the Tiki contacts (address book) accessible via the LDAP protocol and thus, email clients can access.

Related:
http://www.egroupware.org/egroupware/index.php?menuaction=wiki.uiwiki.view&page=AddresbookAccountsConcept

((doc:Trackers)) are powerful. But there is no built-in version history like the wiki pages and the spreadsheet. A workaround is to watch the tracker and have the history in your inbox. You can also permit users to comment the tracker item instead of editing it.

A real history, accessible via the interface would be nice to have. Please see SourceForge trackers for an example.

Adding a field "Edit Summary" would be useful for this history.

Low-hanging fruit solution is to copy the diffs (that we already send by email but should be improved: [wish1982|Trackers :: email notifications of changes :: more emphasis on changes.]) to a new "history" tab.

More work would be an interface to revert to a previous value, which could be nice-to-have but too complex.

Related:
[wish953|Tracker field type: wiki page]

The webmail currently only supports POP. IMAP support like IMP, Squirrelmail, Roundcube, etc would be much better. It could rely on PHP's imap support like IMP does. People who will want IMAP would have to have it in their PHP, which is in an acceptable requirement.

I believe this is a regression and it seams to be related to composer.

I install a brand new (nothing configured yet) tiki-11.0.beta.tar.bz2 on my debian squeeze server.

Clicking on the icon in the admin main panel, I got the following error (feature activated or not):

{CODE()}Fatal error: require_once(): Failed opening required 'nusoap/nusoap.php' (include_path='/var/www/sites/xxx/xxx.co.il/subdomains/www/html/vendor/bombayworks/zendframework1/library:/var/www/sites/xxx/xxx.co.il/subdomains/www/html/vendor/bombayworks/zendframework1/extras/library:/var/www/sites/xxx/xxx.co.il/subdomains/www/html/vendor/phpseclib/phpseclib/phpseclib:.:/usr/share/php:/usr/share/pear:/var/www/sites/xxx/xxx.co.il/subdomains/www/html/') in /var/www/sites/xxx/xxx.co.il/subdomains/www/html/lib/soap/wsdllib.php on line 14 Call Stack: 0.0015 983032 1. {main}() /var/www/sites/xxx/xxx.co.il/subdomains/www/html/tiki-admin.php:0 0.1485 21077208 2. include_once('/var/www/sites/xxx/xxx.co.il/subdomains/www/html/admin/include_webservices.php') /var/www/sites/xxx/xxx.co.il/subdomains/www/html/tiki-admin.php:605 0.1502 21413568 3. require_once('/var/www/sites/xxx/xxx.co.il/subdomains/www/html/lib/webservicelib.php') /var/www/sites/xxx/xxx.co.il/subdomains/www/html/admin/include_webservices.php:10 0.1510 21483008 4. require_once('/var/www/sites/xxx/xxx.co.il/subdomains/www/html/lib/soap/wsdllib.php') /var/www/sites/xxx/xxx.co.il/subdomains/www/html/lib/webservicelib.php:10{CODE}

I have re setup.sh several time and tried the tips from: http://dev.tiki.org/Compose
Same.

I tested on demo and there it is working.
I don't know the setting there (and it is svn) but it should work on a linux server out of the box.

The new 12x branch option is missing when selecting instance type, to report a bug on show.

The functionality to allow comments in wiki pages on a 'per page' basis that was in Tiki 6 has been moved from Wiki admin to Comments admin and is therefore less visible

It should be replicated in Wiki admin as well to make it more visible


Fixed r48529

With MediaWiki, before you save, you can review changes. It shows what you __will__ change (if you click save), in wiki diff format.

This is very nice.

Sometimes, we have done several edits, and we are not sure exactly what we changed (supposing we are multitasking or interrupted). It is nice to be able to review this and fill out the edit description accordingly

Useful for translation as well:
http://wiki-translation.com/tiki-view_tracker_item.php?itemId=51


Related:
*{wish id=2102}
*{wish id=1843}
*{wish id=1220}

When creating a link like this

((test - test))

to link to a page named 'test - test' then the created page is missing the hyphen. Additionally the pages is always shown as non-existent, meaning that the question mark behind the source link is always there, even if th e page was manually renamed. It is a real blocker.

In the Properties tab of the Wiki edit screen (either standard wiki editor or wysiwyg) there is an option to Import the content of wiki page that has previously been exported (needs some Wiki options set to see these)

The export process works fine producing a text file with a special header area then the content which is in wiki syntax for the normal editor or html when using the (full) wysiwyg editor (not tested the wiki syntax wysiwyg option)

To import the page you simply browse to the file and then save the page - which used to import the content at that point.

However now (22 Aug 2013) in 11.x and trunk nothing happens and the page remains empty. It used to work Ok at some point probably version 6 or perhaps earlier?

!!Problems

__Pretty Much Resolved by the wiki ALIAS function__ - so closed.

Redirect plugin
*is not included by default in TikiWiki because it could be used for bad things
*creates redundancy (in search results, page listings, etc) - maybe redirected pages should not appear in list?

Renamed pages
*do not automatically redirect - creates broken links.


!!Proposed solution:

!!!renamed pages
*When a page is renamed the user must choose "hard or soft redirect" perhaps better known as "redirect or refer from old page?"
**hard redirect places redirect plugin on pagename-old to pagename-new.
**soft redirect puts something at top of page like
^This page has been renamed: pagename^


!!!Add synonyms/aliases to a page

suggestion (mlp): adding aliases to a page should automatically create pages with hard or soft redirects to pagename. Note that the adding of alias pages must not destroy data if page already exists.

Ex.:
dev.tikiwiki.org/Tracker
dev.tikiwiki.org/Trackers
dev.tikiwiki.org/Bug tracker

would be aliases. It would avoid the pollution we have here: http://dev.tikiwiki.org/tiki-orphan_pages.php


doc.tikiwiki.org/Install
doc.tikiwiki.org/Installation
doc.tikiwiki.org/Installer

Each wiki page should be able to put one or many aliases. These aliases would work in search. All the aliases should have an important weight in the internal search engine.

We could use this instead of renaming pages. Also, when we do rename a page, we could have an option to have the old page name to be an alias of the new one. Thus, better for external search engines.

Theses aliases could even be used as meta tag for this page.

Putting aliases to non wiki pages (ex.: tiki-forums.php) would make ((doc:structures)) more useful. Now, using structures for site navigation only makes sense if you only have wiki pages. And who ''only'' wants to have wiki pages with all the great features offered by TikiWiki? :-)

It also help to use cleaner page links in sentences. If my Wiki page is called Install, I have to do the following now:

{img src=images/code.png}%%% {CODE()}
For more information about ((Install|Installation))
{CODE}

With aliases, I could do:
{img src=images/code.png}%%% {CODE()}
For more information about ((Installation))
{CODE}

Page aliases - and hard redirects - should permit to set status "Moved Permanently" for robots to send traffic to main page.

What would we do with page renames? (which correct links in wiki pages). Needs some thought. We don't want some unwanted changing of text in existing wiki pages.


Do we need?
Redirect to internal or external http is ok because a special permission is needed to use. -> tiki_p_wiki_alias . In security admin, warm that giving tiki_p_wiki_alias to untrusted people is a security risk.


Related:
[wish1119|Better handling of page renaming]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

Font Awesome (and maybe others?) supports rotating the icon, and some of the icon instances in Tiki are rotated (like the "sitemap" icon is used for Tiki's categories feature, rotated 270 degrees). So a PluginIcon parameter like ''rotate="270"'' would be a great addition.

Started in 3.0, needs to be used in tiki-admingroups.php and propagated to various places where permissions are set.


Also on wish list: A way to put more emphasis on more important permissions.

Either basic vs advanced or an ordinal column (top put more important stuff at the top)

So for a wiki page, view, edit and history should be at the top or in basic while tiki_p_use_as_template and tiki_p_export_wiki should be in advanced

[https://wiki.php.net/rfc/optimizerplus|Optimizer+ will be integrated into PHP 5.5.0]

So
1- We want this in the dashboard like APC and Xcache
2- We want to make sure it works with tiki-monitor.php -> http://sourceforge.net/p/tikiwiki/code/48039


OPCache:
http://php.net/manual/en/book.opcache.php

OpCache status from Rasmus Lerdorf:
https://github.com/rlerdorf/opcache-status

Related:
http://rtcamp.com/tutorials/php/zend-opcache/

Important commits:
http://sourceforge.net/p/tikiwiki/code/27831
http://sourceforge.net/p/tikiwiki/code/27829