Category: Consistency

{syntax type="tiki" editor="plain"}
Hello,

These is a partial solution to ticket 3029 which I can't access.
I was wrong in my search of causes of the problem.

__The installation in my configuration described in 3029 don't supports the following :__

The TikiWiki sequence with tiki-setup_base and tikisession-pdo
first creates the object
$dbTiki = new PDO(......)
just after seems to extends the class by
TikiDb::set( new TikiDb_Pdo( $dbTiki ) );

Most installations are able to hold the following (tikisession:open)
TikiDb::get()->setAttribute(PDO:....);
TikiDb::get()->getAttribute(PDO:....);

and just after execute tikisession:read with this

$sth=TikiDb::get()->prepare($sql);
$sth->execute();

This don't functions (probably php 3.3.1), the PDO methods and attributes can't be accessed by this mean.

The scope operator is not able to reach PDO (builtin by extension) class PDO in my context :
either windows version (improbable) and php 3.3.1
On my services provider OVH which run php 3.2.x everything functions

Zend uses interfaces and other objects.
In my opinion :
$sth must be set as new object with "PDO_Statement" properties (interface of zend and implementation)
When I implement the good properties and class I go much more further
in the execution.

But how to make function whole 4.1 with this scope operator problem ?

Search (index) need sometimes to "Explode" a itemList field values as an array of string so each value can be filtered

For an exemple, in a tracker you have an itemList fields using this date field with such values:
* tracker_field_date: 2021-03-24, 2021-01-14, 2020-10-22

To filter per date (we need item that contain "2021-03-24" only) we can should be able to use multivalue.

{CODE(caption="filter set in a smarty template, work the same elsewhere")}
{filter field="tracker_field_date" multivalue="{/literal}{$row.tracker_field_holidayDay}{literal}"}
{CODE}

''Note: if you use content you may filter "2021-03-24 and 2021-01-14 because they both contain "2021"''

This is working fine if you use elasticSearch but doesn’t when you use Mysql.

On dev.to, is I use the "Search" system from the right col top module "Seach wishes" or

For the string: "Wikiplugin, memberpayment; The period tooltip is not consistent with available options" I have no results.
If cut it and use only: "Wikiplugin, memberpayment" I have results.

I should be able to find the ticket in both cases.

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

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

{syntax type="tiki" editor="plain"}
section edit icons in non-editable menupage (from module) are shown when page in central column is editable.
(Ajax enabled, in case it matters)

The links in section edit icons open the central column page for editting, not the menupage one, but anyway, confusion is added to users... (plus icons non-WYSIWYCA on the menu page)

It should be easily reproducible on dev.tw.o.

Using Tiki 4.1.

sending a message from userA through the userB homepage:
tiki-user_information.php?userId=N

doesn't keep a record at "sent" from userA (messu-sent.php)
And it should, because userA sent that message indeed to userB.

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"}

{syntax type="tiki" editor="plain"}
The link to the RtM calendar event on tiki.org currently should be the SEFURL version, e.g. https://tiki.org/tiki-calendar-view_item?calitemId=337 (or maybe something even shorter?) and not https://tiki.org/tiki-ajax_services.php?controller=calendar&action=view_item&calitemId=337

Also, it should be easier to share it, imho.

The links on menu #42 to blogs and forums do not observe the -+sefurl+- setting (always "unfriendly"), however ''trackers'' works as expected.

There are probably others missing...

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]

When locally testing use of __setup.sh__ with a custom PHP binary location (i.e. using the -+-p+- option), I found two instances of hardcoded "php" invocations. All other invocations are done using the ~np~"${PHPCLI}"~/np~ variable, so I figure these are oversights.

At this writing, trunk/setup.sh is at r64051. The hardcoded references are at:

{CODE(caption="Line 553" wrap="0" colors="shell" theme="default")}curl -s https://getcomposer.org/installer | php -- --install-dir=temp{CODE}

{CODE(caption="Line 556" wrap="0" colors="shell" theme="default")}php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));" -- --install-dir=temp{CODE}

In TikiSheet: I'm trying to have 'T' or 'true' shown when two other columns have the same value. But =(H3==K3) when saved shows "true=(H2=". Note the truncation; the truncated stuff shows up in the expression field on the edit screen. Before being saved the cell shows 'true'. Adding a conditional ("?:") expression wrapper did not help.

Also, a spreadsheet could not have rows added to it until a similar expression was removed from the spreadsheet.

The Shop profile does create two new groups: Customers and Managers. Managers get some permissions in regard to payments, but none for trackers. This means Managers aren't allowed to populate the products tracker with items, only admin can do that. Also, they aren't allowed to remove tracker items. The entire permissions roster should be checked for consistency.

Also, it should be checked whether or not tiki_p_view_category should be granted to anonymous, otherwise the category won't be output in the shop. Another story is tiki_p_list_trackers. In the default shop profile, this is granted to anonymous, but still for some reason only the admin can list the products tracker?

Thanks
hman

Shopping Cart Module disappears just after clicking on "add to cart" on a product (but page Refresh displays updated cart normally)

Reproduced easily after applying the "Shopping Cart" profile.

Come here:
http://xavi-9794-5978.show.tikiwiki.org/tiki-index.php?page=cart+products
u: admin
p: 12345

And click at "Add to cart" from any of the products. Cart dissapears.
Refresh the browser, and the new item is your cart, which displays as expected, until you click on another "Add to cart".

Site timezone is not respected when using Plugin Convene

E.g.: site default is UTC-2. You choose your time in the convene plugin, as UTC (even if you have no indication of the timezone, it seems), for instance, and the stored time is shown 2 hours before the time you selected in your choice.

Reproduced using Tiki 13.x here:
https://tiki.org/Admins+Team+Meetings

However, I can't reproduce it in an associated show instance in trunk. Maybe it has something to do with the timezone set in php settings, and not just the setting in Tiki?
I kept the tiki set as "Admin home > General > Date and time > Displayed Time zone: Use site default".

Demo here:
http://dev.tiki.org/show:Slideshow+Test#s6

{flash type="url" movie="display593" width="967" height="732"}

{syntax type="tiki" editor="plain"}
Verified also on Tiki25, login as Admin, go to settings, Control Panels, go to /tiki-admin.php?page=search, click on the rebuilt index button it open a modal.
All this is the control panel area.

If you validate the action and rebuild the index you will be thrown outside the Control Panels area (/tiki-search-rebuild).

{img fileId="1664" thumb="box"}
{img fileId="1663" thumb="box"}

This is related to the action page itself. If you use the top admin bar rebuild-index you will be also exited from the Tiki administration pages.


List of pages/actions with the issue:
* Control panel, go to /tiki-admin.php?page=search, click on the rebuilt index button it open a modal, validate the action (/tiki-search-rebuild)
* Control panel, go to /tiki-admin.php?page=general, tab navigation, Sitemap protocol click on the play button => tiki-admin_sitemap.php
* Control panel, go to tiki-admin.php?page=textarea#contentadmin_textarea-2, click on the link tiki-plugins.php
* Control panel, go to tiki-admin.php?page=metatags, translate metatag throw you out of the admin to tiki-preference_translate.php

May be all top menu action links throw out of the admin area...
* Control panel, top menu tools, Server check
* Control panel, top menu Access, Permissions
* Control panel, top menu Access, Groups
* Control panel, Editing, Plugin approval (tiki-plugins.php)
* ...

The following have been lost for the calendar module:
* "Checkerboard" pattern of changing the background on alternating days
* Font size of the day numbers
* Header styling
* Highlighting of today (today always has a class of calhighlight)

Also the highlighting of today has been lost for the full calendar as well (in all views - monthly, weekly, etc.)

In a wiki page I set the plugin img (image) to use an image from "anywhere on the internet".
Several options are not working:
* Thumbnail (no matter what I choose I see the image full-size)
* Image size (no change or image not displayed, Setting width to 50% won’t change anything)
* ...

If I change to use an image from the file gallery it work just fine.

Please check the instance: http://bsfez-11581-6081.show.tikiwiki.org/

We are lacking some languages spoken by millions. I'm not asking for translations, but we don't even have them as languages to correctly flag user texts for i18n, they are missing in /lang/langmapping.php.

* Dari (Afghanistan)
* Pashto (Afghanistan) https://en.wikipedia.org/wiki/Afghanistan#Languages
* Persian (Iran). We do have Farsi, but to my understanding the official wording is Persian, an Farsi is rather the name used outside Iran (endonym). https://en.wikipedia.org/wiki/Iran#Languages and https://en.wikipedia.org/wiki/Persian_language

There is an ISO transliteration of Persian into latin alphabet ISO 233-3.

When using:
{CODE(theme="default")}{listpages max="10" for_list_pages="y"}{CODE}
And while sorting columns by clicking on headers columns title to sort, the action takes the user to the top of the web page.
Please see show instance, and click on a column to sort.
See home page of show instance and scroll down to page list.

What I expected was for the wiki page to stay in one place, as the header column is clicked to sort.

password: 12345

When sorting by category tracker field, the sort is on the category ID as text. Example:
11
110
12
13
14
141
15
The sorting should be just as it is on the ‘browse categories’ page – as a tree. The listing is alphabetical at each level, and all child items are listed before the next item at the current level.

When you click on the header, it suppose (I assume this) that it will sort on that column/field.

It does not, obviously.

As seen here: http://themes.tiki.org/tiki-pagehistory.php?page=Sample+page&source=0
This happens only when jQuery UI is set to "None".

As discussed at the TikiFest (?), we need more granularity here, for people that want AJAX for some features, but not for others.