Category: 13.x

Updated from 9.3 to 13.1, now article modules do not display filtered by category when article assigned to the specified category.

We use module articles for listing articles. Articles are categorized in different categories. Listing is in the right column next to the article and list the titles of articles from the same category as displayed article.
{img fileId="980" thumb="y" rel="box[g]"}
In version 13.1 do not function the parametr Category in visibility settings of module.
{img fileId="981" thumb="y" rel="box[g]"}
{img fileId="982" thumb="y" rel="box[g]"}
If is the module configured as shown in figures, the module is not displayed next to the article.
In previous version this parametr works fine.

{syntax type="tiki" editor="plain"}
Background info:
http://tiki.org/tiki-view_forum_thread.php?comments_parentId=46281

So when you visit http://doc.tiki.org/Features, the actual list of features comes and goes.

You can see from the video below (I put a watch alert on that page) that it has been going on for months:
{flash type="url" movie="display251" width="1126" height="528"}

{syntax type="tiki" editor="plain"}
Draw doesn't work.
Captured an image using jCapture. Then edited.
Symbols displayed in draw are off.

{flash type="url" movie="display411" width="983" height="737"}

If you are in a site with some "documentation" activity (a bunch of images already in the default folder), it's not easy for the end user to insert the image he/she has just uploaded to Tiki thorugh the toolbar icons/actions.

With the former file gallery interface to upload a file, you see the thumbnail or icon of the image/file just uploaded, so that it's very easy to find it and click on it to get the corresponding wiki syntax inserted in the text area, so that the file is used within the text.

With elFinder, this simple task becomes difficult, annoying, and time consuming (plus irritating at some times, if you can't seem to find the image you have just uploaded and you KNOW it's there somewhere).

Usual case (can be easily reproduced in doc.t.o):
# Log in doc.t.o
# Edit a documentation page
# Click at the toolbar icon to insert a new image from your local harddisk. elFinder interface is shown.
# Click at the icon to insert the file from your harddisk. Select your file, upload it.
# Once the file has finished uploading, you have no clue where the image is, and it's way more complicated to have your image inserted for you in your wiki page or text area.
** You have to start scrolling and scrolling there in the elFinder window to look for something... I know my image was called (real example from today) "tiki13_tracker_events_00.png".
** I typed "tiki13_tracker_events" in the search box, and nothing was shown (!).
** I typed "tiki13_tracker" in the search box, and nothing was shown (!).
** I typed "tiki13" in the search box, and dozens of images where shown (!!!).

At this time, my annoyance started to increase quite a lot, as you can image...

We need to make the lifer easier for the end user (and for the *.t.o Tiki contributor)

^ Expected behavior with elFinder:
* Once the file has finished uploading, we expected to have elfinder automagically search for that file name ("tiki13_tracker_events_00.png"), and display the end user JUST the icon/thumbnail of that file just uploaded, so that this human being can easily click on it to have it inserted.
^

Thanks for improving this lovely elFinder interface! :-) {sign user="xavi" datetime="2015-01-26T10:13:55+00:00"}

Just got an error in debugging console of IE10 when posting comment here:
{CODE()}
//Synchronize textarea and codemirror before comment is posted
$(".comment-form>form").submit(function(event){
var $textarea = event.target.find("textarea.wikiedit"); //retrieve the text area from the form that is submitted
if (typeof syntaxHighlighter.sync === 'function') {
syntaxHighlighter.sync($textarea);
}
});
{CODE}
It said something like -+"find method is not available here"+- (sorry it was in Czech and not copypasted with the code snipped here).

luci

Currently I am only able to add 1 featured link. Adding a second link replaces the first. It is also not easy to find the option for adding featured links once the module has been created. I had to type in the url because I could not find the option for adding them.

Featured profiles are useful for testing common features:
http://profiles.tiki.org/Profiles_in_installer

The File Gallery Template feature is still in Tiki, and it seems nobody really knows what it was used for, if you will here is something I wrote a couple years ago on this, at https://tiki.org/forumthread59522
If this is supposed to work somewhere, it sure would be great to have it working if the intentions were to build upload templates from it.
Thanks for looking
John

Dear Sir:

This may not sound as a bug, but this could be a problem for people who use tiki to build a professional website.

In an ideal CMS, no one has to know what platform the webmaster is using. Knowing the platform from first sight is considered a huge flaw in the design of the CMS. It's not my position to defend this statement, but you're professional developers, and you understand how this should be the first piece of information any hacker is looking for. Honestly I'd be already surprised if this not clear.

With that said, let's state the problem: The problem is that every php page in tiki has the prefix "tiki-", like "tiki-index.php". Now why?

Let's look at this rationally. Does this benefit the user with anything? Absolutely not. As it looks to me, it's just a show-off of the kind "hey look, this website was made by tiki, and the webmaster couldn't get rid of those urls exposing him".

Trust me, some companies will just refuse to use the whole platform because of this! Usually organizations are paranoid about security.

So please, fix this. Just remove every "tiki-" from every file name. There's not a single good reason to have it done this way.

PS: Renaming the files myself is not considered a solution. Even if it works, an update will mess it up.

Best,
Samer

Forum editor (wysiwyg?) can't be loaded in mobile device (tested with chrome on android smartphone).

Example url:
https://next.tiki.org/tiki-view_forum_thread.php?comments_parentId=52179

If it can't be properly fixed, at least wysiwyg editir shoukd be disabled when in mobile devices?
---
^ __Update as of March 16th 2015 __
Bug still present in next.t.o (sorry, I can't see the revision number any more at "Settings > Control Panels > General > General Preferences").
I did clear the ./temp/public/ cache folder, reloaded the url indicated in the bug report in a browser at the computer (wysiwyg shown), and then something equivalent on Chrome on Android smartphone, and still can't see the textarea to type.

So please, don't close a bug report unless you tested the fix with the described steps to reproduce it, even if some other bugs are fixed that "should" or "might" also fix the reported bug, etc. At the most, change status to "pending" while requesting to the bug poster to "Please retest". And thanks wolfgang for all you efforts to improve Tiki: they are very welcome!
{sign user="xavi" datetime="2015-03-16T08:43:49+00:00"}

In addition, no editor shown at the show.t.o instance attached to this bug report with Chome on GNU/Linux PC, using 14x r54428, either:
http://xavi-9794-5559.show.tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=1
u: admin
p: admin
^

See show site and video:
{flash type="url" movie="display853" width="917" height="730"}

Also, it's very unclear how to change the theme of the site.

The wysiwyg editor no longer shows the defined toolbar (as set in toolbars admin) when editing a wiki page. Instead the reduced wiki syntax toolbar is shown which does not allow all the edit features possible.

When the GALLERIFFIC plugin is used in the WYSIWYG editor (full html) then the editor no longer opens - just the 'Loading' message forever. The plugin seems to run ok once it is in there ie it was there before an upgrade or put in new first time round - and you can also use the standard wiki editor ok.

Console errors shown when trying to load the editor are:

"TypeError: imageData is undefined
var index = imageData.index;

jquery....ffic.js (line 505)

which might have something to do with it


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

http://nextthemes.tiki.org is needed
* Compare trunk & 13.x code base output
* Start testing for Tiki 14

Low priority but also in need of PHP 5.5:
http://nexttv.tiki.org
http://stats.tiki.org

Please see like http://code.google.com/p/sabredav/wiki/Migrating1_6to1_7#Composer_package_name_changed

{flash type="url" movie="display515" width="614" height="376"}

New feature, so should go to trunk

This is a different behavior than in 12.x

{syntax type="tiki" editor="plain"}
This is low priority because it doesn't affect most sites. However, hopefully, there is an easy way to exclude some fields from the RSS view (this could come in handy for other field types as well)

{CODE()}Show.tiki.org snapshot creation is in progress

Show.tiki.org snapshot creation is in progress... Please monitor http:///snapshots/ for progress. Note that if you get a popup asking for a username/password, please just enter "show" and "show".{CODE}

Just compare
http://tiki.org/Map+of+all+TikiFests

To:
http://next.tiki.org/Map+of+all+TikiFests

Thanks!

1- Visit: http://next.tiki.org/messu-mailbox.php

2- Mouse-over a sender

3- You will see a "follow" button.. Try to click it.

{flash type="url" movie="display816" width="560" height="548"}

Thanks!

Looks like a tag mismatch.

{img fileId="864"}

Amette contributed a way for Tiki to report its health:
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/tiki-monitor.php
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/check_tiki.php
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/check_tiki-new.php

This could help
1- Alert quickly the right people to get the site back up
2- Provide data to understand what went wrong

Related:
* {wish id=4836}
* {wish id=4678}

When an image is uploaded to a File Gallery, you used to see a thumbnail of it when you moused over the item in the File Gallery table listing

This no longer happens.

This functionality should restored if at all possible as it is an invaluable feature when you have a gallery with lots of images and you want to be sure which one to use/download

When an image is uploaded to a File Gallery, you used to see a thumbnail of it when you moused over the item in the File Gallery table listing

This no longer happens.

This functionality should restored if at all possible as it is an invaluable feature when you have a gallery with lots of images and you want to be sure which one to use/download

closed as this is a second entry of the same bug - caused by a 'bounce' on the dev site

After activating the Article and RSS features I tried to generate articles from an RSS feed and it didn't work.

When clicking here http://regis-10191-4930.show.tikiwiki.org/tiki-view_articles.php nothing appears.

When selecting 'Quarter' in a Tiki-calendar it show the correct months (three), however when moving up or down it jumps 4 months.

Reproduction:
- http://info.tiki.org/tiki-calendar.php?viewmode=quarter
- It shows (at time of writing): January - March 2015
- Press the right arrow makes that: May - July 2015

Expected:
- This should be April - June 2015

Hint:
I noticed three arrays in tiki-calendar.php, where quarter is defined with 4 months in stead of 3.