Category: 12.x

Updated from 9.3 to 12.3, now RSS Feeds for articles not working.
In any browser displaying blank page. Without any errors ( I have enable error reporting from admin > general).
This is RSS feed: http://e-republika.cz/tiki-articles_rss.php?ver=2
RSS feed for blogs works fine.
Version PHP: 5.5.18

{img fileId="977" thumb="y" rel="box[g]"}
{img fileId="978" thumb="y" rel="box[g]"}
{img fileId="979" thumb="y" rel="box[g]"}

branch 12.x nowadays uses codemirror 3.16 (3.x is supposed to be right-to-left language ready).

I tried with hebrew, and the editor shows an extra scrollbar on the right of the screen, which hides the firsts letters of each sentence starting on the right margin.

See show instance

Installed and Setup Tiki 12.0 with MySQL 5.6.16.
Enabled Score feature.
Then posting to forum, I got System error. Error messages is ...
{CODE(caption="Tiki logs" wrap="1")}Field 'tstamp' doesn't have a default value - INSERT INTO...{CODE}

I think it would be relate to MySQL version.
Is it not certified with 5.6?

After upgrade from version 9.1 to version 12.0 the score feature does not work anymore. After login the score is is set to 1.

This bug started in r45775 where $table->increment($score) was removed.

Displaying a star behind the username was removed in r47705. Which makes the score feature more or less useless.

It asks for password, but then, give "Error saving image: HTTP/1.1 401 Authorization Required"

{flash type="url" movie="display650" width="707" height="601"}

Will record a screencast. Hard to explain. You have to see it to believe it :-)

When using MySQL Full text Search as the index. CustomSeach plugin doesn't seem to find all items as compared to a PHP Lucene index

See show instance

Show username: admin
Show password: 12345

The search indexing rebuilding with log option (whether triggered through tiki-admin.php?page=search or the console.php, both create a temp/Search_Indexer.log but the log file is always empty.

{sign user="pascalstjean" datetime="2013-08-18T18:15:12+00:00"}
Also noticed on nexgdoc that clicking on the log checkbox, then saving preferences does not seem to save that preference.

Will document in SHOW

{syntax type="tiki" editor="plain"}
Step1: Create a simple text file and upload to a tiki installation
Step2: Admin Home -> Search -> General Settings (tab) -> Rebuild Index
Step3: Admin Home -> File Galleries -> Search Indexing (tab) -> Rebuild all files for search

However, the contents of the file uploaded in Step 1 are either not indexed or not searchable.

The search function cannot find words within the fancytables. This is quite important function so I would like to know a solution. Is it maybe possible to use the alternative query when the search returns empty set? and check if the query can be found with this alternative. And site is using mysql search currently. Does this work on other search engines?
By using SQL i can find it by changing the search query from
{CODE(caption="Not found" colors="sql")}select * from tiki_pages where data='myQuery';

or

Select * from tiki_pages where data='%myQuery%';{CODE}

{CODE(caption="Found " colors="sql")}Select * from tiki_pages where data like '%myQuery%';{CODE}

But if you leave out the wildcards it still returns nothing

http://dev.tiki.org/tiki-searchindex.php?filter~content=html5-boilerplate&sort_mode=score_ndesc&filter~type=&filter~language=

{flash type="url" movie="display622" width="1146" height="682"}

The search engine friendly links do not appear for forum threads. You can use the SEF link to get there, and somewhere on the website the SEF form us used (based on a crawled index of links) but it is not present under the form thread list page, which is arguably the highest traffic page to access the threads from.

I have also looked at the RSS and the SEF links are not used for the forum in there as well. They use the standard tiki-view_forum_thread.php page with a URL passed argument.

Hoping someone can track down what went wrong. I have already searched through my .htaccess file to make sure I did not break it myself, but don't think the issue is there.

SEF links for the forums themselves appear to be functionally normally.

{syntax type="tiki" editor="plain"}
Right now, select all doesn't select all groups, and thus leads to errors in permission configuration

SORRY for frequent Bug Tracker infomails - something weird is going on on this server/website or tracker.

Tiki version: Last update from SVN (12.0svn): Monday 28 October, 2013 18:41:51 CET - REV 48198 (MyISAM)

Category: "Bug Regression" / Version "Tiki 12" Features: "Tracker, Category, TIM/show.t.o"

=> This time it saved Category "Bug Regression" - so I try again {sign user="Torsten" datetime="2013-10-29T23:38:58+00:00"}

---

--I keep the status "open" for a moment, as the buggy behaviour just partly disappeared magically.--

Buggy behaviour appears and disappears here on item4829 and stays on item4828 - two same tracker items and different behaviour on both??? - maybe somebody works on the server and there are no real bugs? WEIRD! I will recheck tomorrow and ask in the dev-list.

---

--When I create a bug report, categories "Category, Version and Feature" are not saved.--

Update: Now categories are saved (here in item4829, not yet in item4828), but when re-editing the tracker item, the category fields are empty
Update 2: categories stay saved in item4829, stay disappearing in item4828

---

Error Messages after saving/uploading:

Saving a tracker item leads to a colored table with a lot of error messages like: Fatal error: Call to a member function setSubject() on a non-object in /var/local/dev.tiki.org/www/lib/webmail/tikimaillib.php on line 71

--Update: saving goes well now (I did nothing different) - another magical self repair?--

Update 2: see the different error messages in the __attachment__ - I have no clue whats going on. Database errors, scripts missing or not loading, errors appearing and disappearing without means ...

---

Show Instances:

When I create a show instance, the installation via TIM fails.

Update: the installation of 12.0alpha fails - the installation of 12.x works well.

Cannot show 12.0alpha, because show fails. Sucks.

__Here the log of a failed installation of a Tiki12.0alpha show.t.o instance:__

{CODE()}
########################################################################################

== TIM Wed Oct 30 00:24:19 CET 2013 : TIM command: CREATE
########################################################################################


== TIM Wed Oct 30 00:24:19 CET 2013 : Starting instance creation

== TIM Wed Oct 30 00:24:19 CET 2013 : Unpacking tarball

== TIM Wed Oct 30 00:24:19 CET 2013 : Chown-ing everything to TIM user and group

== TIM Wed Oct 30 00:24:19 CET 2013 : Running setup.sh
sh: 0: Can't open setup.sh

== TIM Wed Oct 30 00:24:19 CET 2013 : Creating database

== TIM Wed Oct 30 00:24:19 CET 2013 : Setting GRANTs on database

== TIM Wed Oct 30 00:24:19 CET 2013 : Creating local.php
/usr/local/sbin//tim-create: line 145: /var/www/torsten-11143-4828/db/local.php: No such file or directory
chown: cannot access `/var/www/torsten-11143-4828/db/local.php': No such file or directory

== TIM Wed Oct 30 00:24:19 CET 2013 : Old Tiki - populating database via tiki.sql
/usr/local/sbin//tim-create: line 168: /var/www/torsten-11143-4828/db/tiki.sql: No such file or directory

== TIM Wed Oct 30 00:24:19 CET 2013 : Starting extra steps special to show instances. Anything done below is not part of a standard Tiki installation.
cat: /var/www/torsten-11143-4828/info.txt: No such file or directory

== TIM Wed Oct 30 00:24:19 CET 2013 : Creating file http://torsten-11143-4828.show.tikiwiki.org/info.txt with extra info for developers
/var/www/torsten-11143-4828

== TIM Wed Oct 30 00:24:19 CET 2013 : Inserting extra info for developers in a box at the beginning of homepage
ERROR 1146 (42S02) at line 1: Table 'torsten_11143_4828.tiki_pages' doesn't exist

== TIM Wed Oct 30 00:24:19 CET 2013 : FAILED INSTALL
Exiting /usr/local/sbin//tim-create with exit status: 1
{CODE}

---

{flash type="url" movie="display630" width="584" height="457"}

{syntax type="tiki" editor="plain"}
For some situations it would be extremely useful to be able to set a separate permission to allow a Group to create a new Forum.

This would then avoid having to give the Group the full tiki_p_admin_forum permission, which then also allows users in this Group to set Permissions.

Whilst the full Permission functionality is extraordinarily flexible and feature rich, it can also be quite confusing for a less experienced user and the use of Categories (ie using pre-packaged sets of permissions) is a much easier function which obviously should still be allowed from the Create New Forum screen.

This is still a valid feature request - so I've refreshed it (Aug 2013) - but its not a particularly high priority

When you set some expiry time for a group membership (through the admin groups interface), this information is stored in mysql table users_usergroups, and this is taken into account when you use ((doc:PluginMemberPayment)).

However, in other cases of letting a user join a group which has some expiry date set, that information (expiry date) is not stored at mysql table users_usergroups as expected.

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

You can also test with a few users already created:
u: foo1
p: 12345

or
u: user1
p: user1

Cases:
!!! a) Through usual Registration
if you set some group to be selected at registration time
You can register a new user to test case (a), and select either Group1 or Group2 at registration time (both have expiry date 2 days later):
http://xavi-9794-5946.show.tikiwiki.org/tiki-register.php

!!! b) Through Plugin subscribegroup
if the user clicks at ((doc:PluginSubscribeGroup)) (with perms and site config set up appropriately),
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#Plugin_subscribegroup

!!! c) Through Plugin MemberList
if the user selects to join him/herself thorugh ((doc:PluginMemberList))
(with perms and site config set up appropriately), or the admin join a user to that group
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginMemberList

However, looking at the user through tiki-assignuser.php?assign_user=foo , the right expiry information is shown.
http://xavi-9794-5946.show.tikiwiki.org/tiki-assignuser.php?assign_user=foo1

But if you use ((doc:PluginGroupExpiry)) (which looks for that date at table users_usergroups) no date is found and it reports back that the group membership never expires.
http://xavi-9794-5946.show.tikiwiki.org/tiki-index.php?page=HomePage#PluginGroupExpiry_info

In addition, it seems that someone already noticed that type of issue, and this comment can be found in lib/userslib.php > function get_extend_until_info:
{CODE()}
(...)
function get_extend_until_info($user, $group, $periods = 1)
{
//use these functions to get current expiry dates for existing members - they are calculated in some cases
//so just grabbing the "expire" field from the users_usergroups table doesn't always work
(...)
{CODE}

---
Update {sign user="xavi" datetime="2016-05-27T14:38:26+00:00"}:
* this issue seems to be fixed in Tiki 15.x (as of r58705, at least). The 3 use cases work as expected (nice!). The extra code in 15.x would need to be backported to 12.x, I guess.
* Assign user to groups has got a regression in 15.x: you cannot see (nor even edit) the group expiry date through the standard user administration UI in 15.x: when you click in "add or remove from a group" in 15.x, you are sent in a modal to this type of url:
+ __tiki-ajax_services.php?controller=user&action=manage_groups&checked=foo1&all_groups%5B0%5D=Admins&all_groups%5B1%5D=Anonymous&all_groups%5B2%5D=Group1&all_groups%5B3%5D=Group2&all_groups%5B4%5D=Registered&offset=0&sort_mode=login_asc&numrows=25&modal=1__
+
+ and no expiry information is shown.
+
+ While in Tiki12, you are sent to:
+ __tiki-assignuser.php?assign_user=foo1__
+
+ This has been added as a new bug report, since it's another issue (regression):
+ [item5953]

Setting User Tracker id login and registration fields from Profile fails

See example in this profile:
https://profiles.tiki.org/User_Trackers#Group

{CODE()}
permissions:
Members:
description: members of the association
include: [ Registered ]
user_tracker: $user_tracker #and once this work, we need to tell the system about which field ID to connect to
user_tracker_field: $login # On a clean install, the following both should be at "1"
registration_fields: $profileobject:user_name$
{CODE}

names as indicated in the documentation:
http://profiles.tiki.org/tiki-index.php?page=Permission%20Management&redirectpage=Group%20Handler

When running
sh setup.sh
on a fresh install, it shows the following message:
«Composer: If you are installing via a released Tiki package (zip, tar.gz, tar.bz2, 7z), you can and should skip using Composer. If you are installing and upgrading via SVN, you need to run Composer after 'svn checkout' and 'svn upgrade'. More info at https://dev.tiki.org/Composer»

But the first default is always [c] (Composer). This is only correct when one installs from an svn checkout.

When installing from tar, zip or other archives, the first default value should be [f] (fix permissions)

There are some issues with dropdowns and tablesorter data with trackers.
Reproduced in a show.t.o instance (just after the bug item is created):
http://xavi-9794-5607.show.tikiwiki.org/tiki-index.php?page=Wants
u: admin
p: 12345


(1) Tracker item status displayed in a PluginTrackerList as dropdown has no values (this is fixed in Tiki14.x, it seems). Fixing in 12.x LTS will be appreciated.

Response: This is not backportable to 12x unfortunately. This ability sort and filter based on the image title wasn't added until tablersorter version 2.17.5 and Tiki 12 uses 2.14.4. But I have fixed as much as possible and it is now possible to filter using o, p or c in 12x

(2) Dropdown field. An item has no value for that field. How do you select those records with empty value? Could some filter like "empty/not empty" be added to the fitlers?

Response: I don't see an easy way to do this. Would suggest using the sorting to sort empties to the top, or in some cases setting dropdowns or range properly could capture empties (e.g., if they actually have a 0 value). Will ask the tablesorter developer for a fix.

(3) when the order of the fields in the plugin trackerlist doesn't match the order of the fields in the tracker definition, the results are unexpected: it seems to overrule the order in the trackerdefinition.

Response: after further discussion this is not an issue - the sort parameter needs to be set to y for columns to follow the order of the field parameter.

Thanks in advanced!

Share a wiki page should share the body of the page only, and not all the other module zones

Using the Shopping Cart profile on a fresh 12.1 SVN installation.

The shopping cart fails to recognize decimals, e.g. $2.50, in the product price.

Using the minicart NaN values sometimes occur. This may be the same problem.

---
After some more investigation, this may be a bug in the tracker loader for numeric fields.

My local system (Windows 7) is configured to use , (comma) as the decimal separator. It seems like the data loaded through the unified search, to fill the product list, uses the local machine definition, i.e. 0.55 is loaded as 0,55
I have not been able to locate the source for this.

I don't know whether it's a regression or not.

There is a feature called "Show user's real name instead of login in autocomplete selector in trackers feature" (Admin/Config Wizard > Community General Settings). I ensured that the user field in the tracker is set to display realname also instead of username. The feature works when listing items through the tracker itself of plugin trakerlist, etc., but ....

__....it does not do the job at the autocomplete selector for the filtering of items__.

See it reproduced here:
http://xavi-9794-5892.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1&status=o&sort_mode=created_desc&filterfield=10&filtervalue[10]=user1&filtervalue[2]=&filtervalue_other=&filtervalue[3]=&filtervalue_other=&filtervalue[4]=&filtervalue_other=&filtervalue[5]=&filtervalue_other=&filtervalue[6]=&filtervalue_other=&filtervalue[7]=&filtervalue_other=&filtervalue[8]=&filtervalue_other=&filtervalue[9]=&filtervalue_other=&filtervalue[11]=&filter=Filter#

u: admin
p: 12345

This can disclose taxID's or other not-so-public information in LDAP setups.