Category: Consistency

This is a small quirk/inconsistency when using "List pages". You can set the display rows parameter but if the user has access to some pages restricted because of categorisation the actual display row limit used is the number of pages in the system and not the number of pages available to the user.

This means that the listing can be spread over several pages with perhaps only 1 or 2 pages shown per page even if the display rows parameter is set to (say) 30.

It would be much better if this could always show 'up to' the limit set no matter if some pages are restricted.

People expect to find one here

On a Tiki25 I have tracker items created yesterday and today.


If I set a plugin List and filter using "day" argument to filter a date range it is working as expected for the "modification_date" but not for the "creation_date".

IE: These are the dates outputted by tiki-pluginlist_experiment.php
modification_date => "2023-02-28 06:01:22"
creation_date => "2023-02-27 14:05:01"

If I use
{filter range="modification_date" from="-2 day" to="-1 day"} ~~#090:it will output the items~~

If I use
{filter range="creation_date" from="-2 day" to="-1 day"} ~~#F00:0 results~~
(I also tried from="-3 day" to be sure it was not a timezone issue) ;-)

Both should work the same.

# having -+ALTERNATE+- block in the PluginList it gets removed when using the ListGUI
# the ALTERNATE block selection is missing in the ListGUI toolbar too afaics
# ...

The live support system does not have a function to delete support requests, chats or messages. The one delete that is offered deletes an operator. With the operator also all support data is lost, which might be undesirable. Reinstating an operator does not reinstate the data.

{syntax type="tiki" editor="plain"}
The live_support is not working as it did before.

First, the chat window (if invoked) comes up indeed and then that is all to be said.
Secondly, when installed on the left column of the page, it refused to be uninstalled. You continue confirming the deletion, but does not actually delete it.
I have a dedicated computer (thank for that) and I discovered that the live_support was responsible for not releasing MySQL connections. When I managed to remove live_support, the problems were with the MySQL were over.

{img src=display1351 thumb=box width=400}

New user is shown a red X with the title "Random Image" as the registration code.

User can't see the letters so can't register

Appeared in 1.9.10.1 while adding extra security checks

We have actually the logo module with several preferences and parameters:
http://doc.tiki.org/Module-logo

We have also the look and feel related section (logo):
http://doc.tiki.org/General-Layout-Options#contentlook_generallayout-1

We need to merge those:
* On the look and feel section it says for years (before Tiki 12) that it will be merged.
* Some parameters seems already used by both
* Some parameters are here and not there (site icon which is needed for bootstrap layout - brand image)
* ...

I t is important as it is one of the first settings visited by new users.

While some issues have been fixed around logo image, brand icon and classic bootstrap layout, it's still necessary to go to L&F admin to turn on "site logo and title" (IIRC) before the logo module is available to be assigned on the admin modules page. That should be a separate wish.

See related ticket

On Tiki 24 on the Look and Feel control panel (tiki-admin.php?page=look) we have a parameter "Fixed topbar offset" and it allowed me in the bootstrap classic layout to control the space between the topbar and the main content (middle_outer), adding a padding-top style to the body.

It wasn't modifying the height of the topbar.

Tiki24:
{mediaplayer src="display1881"}


In Tiki 25 I understand the parameters was renamed to "Fixed-top navbar height" and is now applied not only to set the body padding-top style but also used in some calculation for the topbar (header) height. (may be by adding additional space to be filled, not necessarily changing the real height value)

{mediaplayer src="display1882"}


This is a very unexpected behaviour and change from Tiki24.
Not using CSS but only the admin interface is not possible anymore and I need to write some CSS to override the actual behaviour.



If we need a parameter for the navbar height, we should have a parameter for it.
I think we still need the previous "Fixed topbar offset" parameter to work as previously.

Else it is better not to have anything that interfere (only through css customisation)

1- Visit http://dev.tiki.org/item4677?status=op&sort_mode=f_41_desc&filterfield=26&filtervalue%5B26%5D=redact&filter=Go

and see:
{img fileId="513"}

LTS Regression: images not shown if align=center as param (reproduced in doc.t.o)

See this thread were it's explained:
https://tiki.org/tiki-view_forum_thread.php?forumId=2&comments_parentId=60647&threadId=60648&thread_sort_mode=commentDate_asc#threadId=60648

reproduced, also, here in doc.t.o, fixed by hand with that change:
https://doc.tiki.org/tiki-pagehistory.php?page=Newsletter+Admin&history_offset=1&paginate=on&history_pagesize=50&tra_lang=sq&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=31&confirmAction=

I mass replaced
{CODE()}
{img align="center" src="img/wiki_up/
{CODE}

with
{CODE()}
{img src="img/wiki_up/
{CODE}

in doc.t.o, but other tikis might be affected by that issue too. (I thought images were gone in some migration between servers or something when I first saw that)

When entering tiki-login_scr.php, only the login box can be seen. There is no "Login box", typically located in the top right corner

1) Try a login with an invalid user
The error is shown "inline" with the login box.
The "Login box" also appears at the top, which it shouldn't

2) Try a login with an invalid password
The error is show in the error screen,which is a completely new screen.

Should be, for all errors
1) Errors are reported "inline" with the log-in dialog
2) The "Login box" should not be shown on the log-in screen.

---
r50668 fixes #1. All errors are now display "inline" with the login dialog on tiki-login.php

#2 is still pending.

make plugin pivottable look and feel (3rd party css) adapt to currently chosen theme style
See it explained in the following screencast:

{mediaplayer src="https://seeds4c.org/tiki-download_file.php?fileId=465&display=y" type="webm"}

{syntax type="tiki" editor="plain"}
Comments to tracker items can be very a useful way to gather ideas, code snippets, links, etc. from the community regarding an a problem or an idea.

It would therefore seem to be natural to include tracker comments in search - otherwise there is a risk of losing valuable community contributions in a black hole of tracker comments.

Tracker comments should of course be included in "Entire Site", and maybe even have their own search category.

Many people use the wiki without structures. It should be optional, like the rest.

See ((doc:maketoc))

In tiki-calendar_nav.tpl the display of calendar dates is formed (template), but in a IMHO rather bizarre mix of hard-coded and localizable syntax, which
a) does not make use and thus circumvents the existing user pref for date formats and
b) effectively makes correct localization impossible.

I quote from this template a code snippet:

{CODE(colors="tiki")}
{if $viewlist ne 'list' or $prefs.calendar_list_begins_focus ne 'y'}
{if $calendarViewMode eq 'month'}
{$daystart|tiki_date_format:"%B %Y"}
{elseif $calendarViewMode eq 'week'}
{* test display_field_order and use %d/%m or %m/%d *}
{if ($prefs.display_field_order eq 'DMY') || ($prefs.display_field_order eq 'DYM') || ($prefs.display_field_order eq 'YDM')}
{$daystart|tiki_date_format:"{tr}%d/%m{/tr}/%Y"} - {$dayend|tiki_date_format:"{tr}%d/%m{/tr}/%Y"}
{else}
{$daystart|tiki_date_format:"{tr}%m/%d{/tr}/%Y"} - {$dayend|tiki_date_format:"{tr}%m/%d{/tr}/%Y"}
{/if}
{else}
{$daystart|tiki_date_format:"%B %Y"} - {$dayend|tiki_date_format:"%B %Y"}
{/if}
{else}
{$daystart|tiki_date_format:"{tr}%m/%d{/tr}/%Y"} - {$dayend|tiki_date_format:"{tr}%m/%d{/tr}/%Y"}
{/if}
{CODE}

So there is some testing for localized date format, but it assumes that only the order of day and month may be swapped through translation? This only works inside the USA or partly in the UK. It does not work in Germany, and not in Japan and possibly conflicts with other countries as well.

Germany uses
{CODE(colors="tiki")}
%d.%m.%Y
{CODE}

Japan uses
{CODE(colors="tiki")}
%Y-%m-%d
{CODE}

Look at the peculiar coding in tiki-calendar_nav.php. To magnify, I have extracted one example that clearly shows the logical error in it:

{CODE(colors="tiki")}
{$dayend|tiki_date_format:"{tr}%d/%m{/tr}/%Y"}
{CODE}

The year was excluded from translation and also the slash that comes before the year (at least in the USA...). So the slash cannot be removed by custom.php, because it is outside the translation. And it would be even worse for a localization into Japanese, because of their year leading the date...

It would be far better if date format was used in the form of the user pref that exists! But for a faster "quick resolution" moving the %Y into the translation braces would do the trick, and later introduce the "proper" way... Thanks.

The feeds:

Blogs, File Galleries & Forums do not create SEF URL's, when the option is enabled.

See show instance at http://marclaporte-11197-4860.show.tikiwiki.org/

tiki PHP-code uses the mentioned constructs at several places, not just the mediawiki importer, perhaps the whole code must be reworked to work with php7

In a superfish menu, a menuSection (parent) item followed by an option (child), then a "separator", then another option, will put the menuSection and the last option on the top level, and the first option will be below the menuSection. This is the right way. But in a Bootstrap menu, both of the options will be under the menuSection, with the separator ignored.

{syntax type="tiki" editor="plain"}
Let's take, per example, [http://doc.tiki.org/tiki-index.php?page=Look+and+Feel|this page] found at:

{CODE(caption="copy/paste",wrap="1")}http://doc.tiki.org/tiki-index.php?page=Look+and+Feel{CODE}

or any pages for this matter on the http://doc.tiki.org/

and we do not see the menu and usual upper functionalities

Do you see the same?

Other Tiki.org users have reported the same.

Here is a capture screen of what is observed

{IMG(src="http://yogapartout.com/extlinks/ftp/imgs/docTikiOrgDocumentation.jpg",width="500")}{IMG}


Here are some conversations copied and pasted:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gary Cunningham says:

Maybe you caught doc.tiki.org while it was being upgraded, or else you
are seeing a cached version of the site. It looks normal to me, and I
suppose it may be normal also for you by now.

-- Gary

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Gregor says:

I can confirm this. The site looks the same to me as shown in your image.

I tried FF 3.6/4. Clearing the cache didn't help. Chrome 11.x shows the site as it should be.

cheers
Gregor

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IMOO, on IE things look fine.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Torsten says:

just to give it a try -> did you go to

admin->general->date and time?

Plz try the site after you unchecked "Detect user timezone (if browser allows). Otherwise use site default."

and check on "Use site default to show times".

We had recently a weird Timezone bug, that might not yet be fixed => our site was only visible from certain browser/OS combination

In our case we had Memory Exhaust errors, so it might not be related. But just a quick check - I lost two weeks on that issue until Jonny saved my live, finding the cause.


Cheers
Torsten

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Gregor says:

it does not seem tio be cookie-related. I deleted he local_tz cookie without any result.

As I'm not a admin on doc.tiki.org I cant test changing tz detection. Anyway, I dont think this would help.

@Daniel: does the site show correctly if you log out (using http://doc.tiki.org/tiki-logout.php)?

Cheers
Gregor

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel's answers:


a) I can't do an admin test like suggested as I don't have admin perms.

b) Firefox which version?

I'm writing from a place where I can't see which IE version they and it seems OK on IE

Would the v4 of Firefox be the problem?

Since I upgrated I have all kinds of incongruities.

c) I can't reproduce the bug from where I'm sitting. I'll be able to answer the logout question later on tomorrow May 20th 2011



Daniel.

13.x: Comments can't be posted in some pages of the Featured Profile "Collaborative Community 12x", such as the homepage for registered members, or newly created pages such as "Subject 1", etc. Doing all that as admin.

See screencast where the issue is reproduced.
https://www.youtube.com/watch?v=7-OI5GCY4qQ

{youtube movie="https://www.youtube.com/watch?v=7-OI5GCY4qQ"}