Category: Usability

See this page:
https://webgrec.ub.edu/webs/05195_ANG.html

When it is snarfed by a Tiki site (tried with up to 1.9.9), special characters are shown weird.
Example:
http://gclub.ub.es/xavi

Could it be made that snarf plugin allow selecting with character set is used in the page taken by the snarf plugin?
This way, the user would be able to siwtch, at least, between utf-8 and iso-8859-1 (or iso-8859-15, at least) so that the page is shown properly...

---
update: the source page in this example, doesn't have any character set defined, afaik (as of January 3rd, 2008).
So the request would be, If I understand the problem well enough, "make snarf plugin hadle correctly pages with no charset specified or with ones different from utf-8".

{syntax type="tiki" editor="plain"}
Wishes:

# Option to allow deleting any user that was registered more than N days ago, and who still hasn’t passed the email validation step and/or the admin approval stage. Or through multiple selection of those users and click on "action on selected" delete. (ionce they are properly filterable). Wish from Alain.
+.
# Option to resend the confirmation email to the selected users
(in one server where we had intruders from time to time, and sys admins blocked php mailing for weeks, many users probably didn't get the validation email... And nowadays, I don't know how to split myself the requests by bots from the real users willing to join. I recently discovered (after upgrading to tiki 4.1 las week), that that site accumulated more than 100+ users like this...., among 500+ users in total. Wish from Xavi.

When we enable the ((doc:Notifications)) system in a real-world tiki site, with some sort of activity, we usually end up attempting to review the notification log (tiki-monitor-stream) with plenty of duplicated entries (a wiki pages was edited many times the same day, a tracker items was editted many times in the same time frame, etc.)

Some sort of low-hanging-fruit would be to expose the PivotTable UI (like the one we use in PluginPivotTable) to display those entries from your own tiki-monitor-stream data with usual default time-based aggregations by months, weeks and days.

This is related to the other similar feature requests to allow to use action log or activity stream as data sources to the ((doc:PluginPivotTable))

My 2 cents.

Allow to reply messages to anonymous users (which provided their email) from the contact-us tracker (created through the corresponding profile in the profiles wizard) directly through some integrated tiki feature, and not necessarily through some external software.

Maybe PluginMail if it can receive the email from the PluginTrackerList with param checkbox properly configured (failed for me with current codebase), in a similar way to receiving username in meesu-compose.php for registered users.

Allow users to upload their profile photo avatar at registration time (through the user tracker)

The simplest approach, maybe, could be to allow the site admin to setup a tracker field of type "userPref" to handle the user avatar?

I know avatars are not user preferences (other things aren't but are treated as such for end users for the sake of usability simplicity, afaik)
See:
https://doc.tiki.org/User+Preference+Field

{flash type="url" movie="display639" width="1126" height="801"}

See comments as well

{syntax type="tiki" editor="plain"}
Currently in master and earlier Tiki versions there are instances of anchor links that display like a button, such as the buttons that toggle the display of the side columns. These don't use the button HTML element; they're anchor elements with text or an icon for a label. These should have an ARIA role=button parameter so that users of screen readers can understand their function.

The relevant Tiki file I believe is lib/smarty_tiki/FunctionHandler/Button.php.

Example:
{CODE()}
<a class="toggle_zone left btn btn-xs btn-secondary" title="Toggle left modules" href="#"><span class="icon icon-toggle-left fas fa-chevron-left "></span></a>

// Should be:

<a class="toggle_zone left btn btn-xs btn-secondary" title="Toggle left modules" role=button href="#"><span class="icon icon-toggle-left fas fa-chevron-left "></span></a>
{CODE}

Reference: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role

{syntax type="tiki" editor="plain"}
On the top of tiki-admin_forums.php is the button "List forums" which should send the admin to the forum list at the bottom of the page (as I guess). But with firefox 2/3 it makes just a reload of the page.

When enabled feature_search it is possible for
Anonymous user to read protected pages via
special search request

Just try "a" or any other word that is in hidden
or protected area in search box - tiki-
searchresults.php give U text from hidden
pages

from tiki-searchresults.php



http://tikiwiki.org/tiki-view_forum_thread.php?
topics_offset=0&forumId=4&comments_parentI
d=16071

It's sometimes useful to allow anonymous or other users without full perspectives-related permissions to switch perspectives. For example, I want to demonstrate themes by using a link such as -+ tiki-switch_perspective.php?perspective=21 +- , in a dropdown menu, to switch to perspective 21. This perspective has preferences including a home page with info about the theme, using the theme itself, and so on, all set by the perspectives feature. The user continues to be in that perspective after leaving the page, so can see a blog or calendar or whatever using that theme, until switching to another perspective. This works fine for admin, who has all current perspectives permissions, but doesn't work at all for anonymous users. Visiting the page shows the theme set for the page but doesn't change the perspective.

I imagine there could be other scenarios where users would select a perspective and stay in it until they switch to another one.

There are now four permissions related to perspectives:
* Can admin perspectives (tiki_p_perspective_admin)
* Can view the perspective (tiki_p_perspective_view)
* Can edit the perspective (tiki_p_perspective_edit)
* Can create a perspective (tiki_p_perspective_create)
I propose that another permission be added:
* Can switch perspectives (tiki_p_perspective_switch)

Or whatever fix would be effective here. The "Users can change theme" option on tiki-admin.php?page=look serves the same purpose but seems to be set via that admin page rather than on tiki-objectpermissions.php.

Somewhat strangely, if I give anonymous the "Can create a perspective (tiki_p_perspective_create)" permission, then switch-perspective works for anonymous, who can see the list on tiki-edit_perspective.php and can input a perspective name but it doesn't appear in the list to be edited, etc. so this could be a hacky workaround but the clean solution of a new permission would be much better.

I wonder why I haven't seen this before. But now I see a CSS problem with the already bug-ridden calendar feature:

When you click on an event, to view it, on my site the classic 3-container layout produces an obscure error: The right module zone "jumps" to below (!) the center, the content zone...

It is kind of similar to the complete breakup of the layout when I test-migrate the test instance of the site to 21.x, but with one significant difference: When the layout breaks down upon upgrade to 21.x, the right modulezone is on the left, in between the left module zone (which remains left) and the center content zone. And on upgrade, the entire layout shows this behaviour, on every page of the Tiki.

HERE this happens ONLY when viewing a specific calendar event. It does not happen anywhere else in Tiki. It also does not happen when viewing the calendar as a whole, only when viewing an event...

So this is obviously a CSS issue. This is with a customized version of Geo, written by Gary. I have to try if it also happens on non-customized, original Geo.

Thanks

The subject says it all.

Cannot demonstrate 9.x on show.tiki.org anymore. Demonstrated 12.x where it seems to be fixed but 9.x is still LTS so should be fixed there too, right ?

There seems to be an issue with the Antibot not working, It asks to type the code backwards but always says what you type doesn't match.
To reproduce, enable user registration and try to register.

I've done some debugging and haven't been able to figure out how to fix it. In Word.php in Zend/Captcha/ the getWord() function doesn't seem to be able to grab the "word" variable from the session. (Line 294)

Using mod_rewrite to direct tiki-index.php?page=.... to kb/pageName breaks template. I think other things might break too. I can't think of anyway to fix this but to scan the code for dependencies on code that reads the URL? Any ideas?

A user registered with an apostroph ' in their username (e.g. "Tes't") will not be able to use some feature of TikiWiki.

For example:
They will be able to select a forum, but after that, all that is displayed is the name of the forum, the "new topic" and "list forum" buttons (depending on permissions, of course), and the breadcrumb forum-navigation. The rest of the page (tiki-view_forum.php?forumid=X) is blank, no header/footer or any menus are displayed.

This __is__ dependant on the rights/permissions of the user in question, SubAdmins and Admins will see the full, expected forum page, regardless of apostrophes in their name (at least with my config, YMMV).

Another problem exists in regards to all JavaScript that uses the name of the user, for example the "tiki-my_tiki.php" page of the user, were JavaScript is used to expand Tabs (e.g. clicking "My Infos" will not work). This is due to JS using ' as string-delimeters, and not escaping any ' within the users name.

---

May be that the sole cause of all the problems lies within the JS-string-delimeter, but I'm no expert on the workings of TikiWiki, and the forum page breaks rather spectacularly when compared to the user profile page, which just doesn't work as expected.

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

When there is a CSS code in the profile params containing lines with ID selectors applying profile just ignores those lines resulting in wrong CSS code. For example:
{CODE()}
#foo,
.bar,
.bar-bar {
display: block
}
{CODE}
will result in:
{CODE()}
.bar,
.bar-bar {
display: block
}
{CODE}
Example of the profile YAML:
{CODE(caption=>YAML)}
objects:
-
type: module
data:
name: Custom Style
params:
nobox: y
groups:
order: 1
position: top
custom: |
{literal}
<style type="text/css">
#whitehead,
.bgwhite {
background-color: #fff
}
</style>
{/literal}
parse: n
{CODE}
Saving this as -+myprofiles/custom-style.yml+- and applying this profile using -+php console.php profile:apply custom-style myprofiles+- will result in custom module creation named "Custom Style" but there will be no line with -+#whitehead,+- in it, just the .bgwhite class declaration.

The "box" command (carat) is NOT turned off by np nor pp tags, in ARTICLE.

The np and pp work correctly in the WIKI and BLOG.

I verified it with my
Wiki Syntax Test Page, replicated below.

[[UPDATE - it would appear that the horizontal line is also not working in this theme. And box tag does not generate a box, too.]
[[UPDATE 2 - I found that PREVIEW ARTICLE does not exhibit the error. Only after it is SAVED does the fault occur.]

Wiki Syntax Test Page

Bold Text
__Is this bold?__

Italic Text
''This should lean ''

Underlined Text
=== Look underneath me===

Strike Through
--Ouch, that hurts--

Headings, 1, 2, 3, 4
! #1 On Top
!! Looking Up, #2
!!! Hey, Watch Your Feet
!!!! Harrumph, fourth place

Horizontal rule (four dashes)
----
Line above me?

Box around text (carat)
^Let me out of here!^

Centered (in a box, too)
^::Stuck in the middle, again ::^

Square brackets
[["dig it"]

Title Bar
-=Champion of the Wiki=-

Shown / Hidden Headings
!!+ Peak a boo
Hide what follows
!!- Boo!
Show what's hidden beneath
and here ?
and here, too?
!! Clears the Hidden header section
And you can't see what follows "Boo!"

!!!!Testing the non-process flag (no box)
~np~^box free?^
~/np~

!!!!Preformated sections
~pp~
pp: Displays preformated text/code; no Wiki processing is done inside
these sections (as with np), %!)~*& == &~'p == (see?)
and the ^spacing is fixed (no word wrapping is done).^ If you see
a box, something is wrong!
~/pp~

~pre~
pre: Also displays preformatted text with fixed spacing, but
wiki __processing__ still --occurs-- on the text.
~/pre~

When viewing articles in list, the number of reads is not displayed anymore (option: art_list_reads) on new articles since Tiki 13. Tiki 12 has no problem.

The bug was introduced in revision 49060. New articles now have tiki_articles.nbreads NULL rather than 0.

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

I am using Articles for Events and need to sort them into order of occurrence using the Publish Date. That is not possible with the supplied files because the sort parameter has been hard coded.

I cannot let the own image of articles 'zoomable':
*text If I configure 'Article:Header text position' as 'Next image', the loupe zoom image disappears and I cannot zoom the own image any other way.
*text Even in the case of the loupe zoom visible, it does not respond when the article is associated with a topic. The entire image is hyperlinked. But it links to a list of articles of the same topic, not to the image enlarged. Maybe that can make sense when the image is a topic image. However, if the image is an own image for the article, one expects zoom it when clicks on it.

Consequences are for usability, as one expects to be able to zoom photos, and article's own images can be (for example, news contents). Furthermore, these images are usually shown in small size in order to save space (as these images are showed on the header section of the article), but its original size is bigger.

I would expect to always have the possibility to zoom the article's own image. Preferably as an hyperlink on the image itself.

Hi!

First: Thanks for this great project!

When you try to translate an article (by clicking on the small globe that is near the edit icon), it sends you to the wiki translation page, and content is empty, ie, it doesn't get the article's content to translate, and off course, even if it did so, the interface is not correct for article translation (it should have the same article interface, with heading and stuff).

I hasn't tried latest trunk, but bug is present on 5.1.

I tried to search for a similar bug already open (because of this forum thread: http://tikiwiki.org/tiki-view_forum_thread.php?forumId=13&comments_parentId=33126), but I found none, thus: I'm opening this open.

Thanks!

When editing an article the type is reset to the first in the list. This is due to an useless? foreach loop inside tiki-edit_article.php . See the patch attached for a solution.

Quite strange, and maybe I missed somthing.

1-Create a new Article, and Topic,
2-Assign image to topic through Admin Topic
3-Select Topic..

All is ok, but it would be better to be able to scale the image, either at the Topic admin, or accept the Topic Own image scale factors.

Error part.
1-Select own image, Image uploaded.
2-Display ok.
3-Upload another Own image to replace the previous one.
4-Image name changes to the name of the new image, but the Image does not change.

The only way I can change the image is to select the Topic, but uploading a new image does not change the Own Image, what ever I do.

-I tried, Clearing all the Cache.
-Clearing and resetting local browser cache, This is not the problem, as I use Firefox and IE, and I edit with Fire fox, and then open IE to see if the image had changed, Plus I didn't run IE to see the previous image.

Work around is - I can delete the Article and create a new article of the same name, with the new image
But it would be nice if it worked as expected.

Clicking on the title of an article should be like "read more", like for the image. Seems more intuitive to me.

Please see:
http://tikiwiki.org/tiki-view_articles.php

And imagine clicking on the title to be taken to:
http://tikiwiki.org/tiki-read_article.php?articleId=166

This is an easy fix.