Category: 13.x

The apply buttons in the admin panel are pretty inconsistent. Some are Apply, others are something else. The size and type of button are also the wrong ones in terms of bootstrap classes

http://dev.tiki.org/Calendar
{img fileId="507"}

http://dev.tiki.org/BigBlueButton
{img fileId="508"}

http://dev.tiki.org/Group
{img fileId="509"}

http://dev.tiki.org/Social+Networking
{img fileId="510"}

http://dev.tiki.org/Endangered+features
{img fileId="514"}

Also:
http://dev.tiki.org/Web-based+source+code+editor
http://dev.tiki.org/Accessibility

I'm new to tiki and just installed tiki 13.1 on my server. After a fresh and what seemed to be a standard install I had a blank page displayed when trying to reach the main administration page : tiki-admin.php. No error message, just a blank page. And some other admin pages where reachable. (tiki-adminusers.php for instance)

It turned out in the Apache logs that a php function, iconv_get_encoding(), used in Zend framework was called but undefined, leading to a fatal error. And it turned out that a __php dynamic extension, iconv, was not loaded in the php.ini__

It seems to me that it should be checked during the install, or at least __be part of the Tiki server compatibility check__ and should be mentioned here : http://doc.tiki.org/Requirements

Thank you very much.

p.s : I wrote a post on the forums about it, but it seemed appropriate to send a message here too. Keep up the good work.

{img fileId="905"}

Bootstrap icons are not found with bootswatch themes that have the font icon path set in their less file to a different location than used in Tiki. For example for the bootswatch amelia theme, the {DIV(type=span class=inline_syntax)}styles/bootswatch_themes/options/amelia/less/varibles.less{DIV} file has the variable {DIV(type=span class=inline_syntax)}@icon-font-path{DIV} set to {DIV(type=span class=inline_syntax)}"../fonts"{DIV}, when it should be set to {DIV(type=span class=inline_syntax)}"../vendor/twitter/bootstrap/fonts/"{DIV}.

To avoid having to alter the bootswatch themes which could complicate upgrading them, there should be a tiki specific less file that sets this variable and overrides that in any individual theme less file. This would mean this variable would not need to be set in any theme less file (currently it is set in each tiki theme file). The same should be done for the {DIV(type=span class=inline_syntax)}@icon-font-name{DIV} and {DIV(type=span class=inline_syntax)}@icon-font-svg-id{DIV} variable names as well.

Below is a demonstration of the problem with screenshots of {DIV(type=span class=inline_syntax)}tiki_list-trackers.php{DIV}:

Missing icons with the Bootswatch Amelia theme:
{img fileId="787"}

Icons are present in the bootstrap default theme:
{img fileId="788"}

See: https://tiki.org/tiki-view_forum_thread.php?comments_parentId=49015

{img fileId="638"}

And https://tiki.org/tiki-view_forum_thread.php?comments_parentId=42893
{img fileId="677"}

Can not edit Wiki Pages in Tiki 13.0 using Chrome or Netscape. IE10 is working fine.

Details: I upgraded my Server from Tiki 7.0, PHP 5.2, MySql 5.1 to Tiki 13.0, PHP 5.6, MySql 5.5.

I needed to do the Datebase Upgrade with the console.php. Otherwise tiki-install.php stuck with an error in Perms/Context get_user_xxx:

Then I did choose Unified Search and upgraded and rebuild the index with the console.php.

After this I can edit Wiki pages using the IE10 10.0.20 x32 or x64 Browser just fine!

But Chome and Netscape Browser on Windows and Linux both x32 and x64 versions are have all the same error: They do not allow to put the cursor into the edit pane and there seems to be somthing that blocks the mouse and cursor to get to the edit textarea.

Can someone verify this behavior?

Has someone a solution for this?

Now the details of the used browsers:

Working: => Wiki page edit pane is functional and I can edit the content and save it successfull!
*Internet Exporer IE10 Version IE 10.0.9200.17088 x32 Win 8.0 x64
*Internet Exporer IE10 Version IE 10.0.9200.17088 x64 Win 8.0 x64


Failing: => Wiki page edit pane locked. Can not enter or change anything of the content.
*Google Chrome - Version 37.0.2062.124 m (64-bit) Windows 8.0 x64
*Google Chrome - Version 37.0.2062.120 (64-bit) Linux/Debian 7.6 x64
*Mozilla Firefox 32.0.3 x32 Windows 8.0 x64
*Mozilla Firefox 32.0.3 (64-bit) Linux/Debian 7.6 x64

Info: There are no difference if I try to edit a new wiki page or an existing one.

The file is here: http://dev.tiki.org/tiki-download_wiki_attachment.php?attId=52&page=Xdebug%20etc&download=y

I don't know if regression or not

I tried to edit http://dev.tiki.org/tiki-editpage.php?page=Search%20engine%20optimization and got "Can't duplicate alias link, SEFURL link already present in SEF page"

The page did save though:
http://dev.tiki.org/tiki-pagehistory.php?page=Search%20engine%20optimization&oldver=88

How can the user know what is the duplicate? Perhaps a link to that page so the user can cleanup the duplicate?

If you try and change some settings in the Preferences area of My Tiki e.g making your email public or the checkboxes for what type of content you want to 'track' - then the "Save changes" button does not do anything and the changes are not saved.

Don't know if this is a problem in other screens but I've checked it in FF, Chrome and Safari (for PC) and my own Tiki13 test site as well as the the Tiki Community web site

When typing a text in a rather regular mode, the CKEditor loses some keystrokes, so that the text has to be reviewed.
Whereas in V12 it would happen randomically, in V13 it happens at regular intervals, as if the editor would make an auto-save, and would stop being responsive for that time lapse.

Do a view source of the show instance and you will see:

{CODE()}<script type="text/javascript" src="vendor/codemirror/codemirror/lib/codemirror.js"></script>{CODE}

Perhaps it's kept separate to be lazy-loaded when needed, but supplying a minified version of the file would be better.

Creation of tracker items with __relative dates__ from profiles shows the right date in view item but empty when editing item

By __relative dates__ I mean something like:
{CODE()}
+1 day 2 hours
{CODE}

(See more: http://www.php.net/manual/en/function.strtotime.php )

See it reproduced in the show instance of this other bug report ([item5254]):

http://xavi-9794-5254.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=4
u: admin
p: 12345

This item was created through applying the profile "Tracker_as_Calendar_12"

Defined as:
{CODE(ln="1")}
type: tracker_item
ref: event_004
data:
tracker: $Tracker_as_Calendar_12:trac_as_cal
status: open
values:
- [ $Tracker_as_Calendar_12:trac_as_cal_summary, A big conference ]
- [ $Tracker_as_Calendar_12:trac_as_cal_location, room 2.3 (15 seats) ]
- [ $Tracker_as_Calendar_12:trac_as_cal_start_date, +1 day ]
- [ $Tracker_as_Calendar_12:trac_as_cal_end_date, +1 day 2 hours]
- [ $Tracker_as_Calendar_12:trac_as_cal_priority, 5 ]
- [ $Tracker_as_Calendar_12:trac_as_cal_description, "I'm really looking forward to attending at this event." ]
{CODE}

Which produced, once applied, something like:

|| Summary | A big conference
Location | room 2.3 (15 seats)
Priority | 5
Description | I'm really looking forward to attending at this event.
Start date | 2014-05-28 12:58
End date | 2014-05-28 14:58
Created | Tuesday 27 of May, 2014 12:46:16 CEST
LastModif | Tuesday 27 of May, 2014 12:46:16 CEST
||

When clicking at edit, no start or end date are shown in the form, and the icon to open the popup helper to fix the dates is not shown either.

And then, in the wiki page to display items as calendar events ( http://xavi-9794-5254.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_12 ), this event is not displayed either.

{flash type="url" movie="display782" width="857" height="741"}

Customized Homepage with profile "Personal Blog and Profile" cannot be reverted back to wiki homepage

To reproduce, apply this profile and attempt to revert back the custom homepage to use wiki homepage.

It didn't work either by means of setting a new homepage for registered users.
---
Reproduced here:
http://xavi-9794-5348.show.tikiwiki.org/tiki-view_blog.php?blogId=1

Custom homepage disabled, but anonymous visitors still get the blog homepage:
http://xavi-9794-5348.show.tikiwiki.org/tiki-view_blog.php?blogId=1

To logi:
u: admin
p: 12345

---
Reproduced in Tiki13 also.

{syntax type="tiki" editor="plain"}
If you have an existing tracker with a large number of items then it does not delete 'in one go'.

What I mean by that is at the admin/list tracker screen using the delete 'action' does not appear to do anything ie the screen does not refresh or do anything.

But if you refresh the page then the number of records has decreased. For my test site a 6000 record tracker only decreased by about 1200 items (I've no idea why this number and of course it might be record size /field type dependent).

It therefore takes 5 goes to actually delete the tracker and even when it is down the large few items you have to refresh the page to see that the tracker has indeed gone from the listing

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))

dev.t.o 14.x: only the last item in the multiple selection combo box is stored for this tracker item

See it reproduced here:
https://dev.tiki.org/item5464?from=Structure

Edited this item as user "xavi" (without admin rights, in case it matters), Selecting some other categories in the combo box for the field "Category" or the field "Version": => only the last category (or at least, only one from all the ones selected) is stored

dev.tiki.org has two menus at the top. They become a click to open icon.

Clicking on one or the other always open both

Some white on white action is happening...
{img fileId="824"}

As can be seen in the screenshot below, calling the REMARKSBOX plugin adds the call's title to the page navigation.
{img fileId="849"}

This can be seen on [http://erikqvam-11905-6586.show.tikiwiki.org/tiki-index.php|a related issue's show instance].

{img fileId="841"}

Click here: http://doc.tiki.org/tiki-print.php?page=Forum+and+Mailing+List+Synchronization

This is a mathematical field with (mul importance ease).

When field is edited, value gets calculated, but not on first save. For example, in this bug report, I will put importance & ease values.

This causes an issue on sorting on this page: http://dev.tiki.org/Tiki13#Open

With Android browser.

See "User contribution" tab of: http://dev.tiki.org/user11625

lkordix reported: http://dev.tiki.org/item4816

{img fileId="840"}

Maybe it's by design, but it looks a little weird...