Category: Usability

When you are on a page of a wiki structure, you can click on the print icon, but you will only print that single page.

The icon and option to "__print this page and all the subpages__" (= in the the sub-structure) right from there (without going through all the clicks at "Wiki > multiprint > select structure > print") would be very welcome, since the base feature to rpint the full structure exists.

From the home of the structure, it would print the full structure (as it can be done with one click from a structure within a Workspace through ((doc:AulaWiki)) mod, or through many clicks as usual, as explained above).

If the user is on a subpage of the structure, that button would print that page and all subpages from the same structure.

Does it make sense?

Hi,

I think there is a usability bug when the option "Re-validate user by email after unsuccessful logins" is selected.
After x unsuccessful logins, the user gets an email with a link like :

http://www.mydomain.com/tiki/tiki-confirm_user_email.php?user=xxxxxxx&pass=yyyyyyyyyyyyyyyyyyyyyy

When following this link, the user gets the message: "This feature is disabled". Nothing is clear on what to do next, if one's account is still valid or not, and how to change one's password if forgotten.

Tikiwiki version used: 2.2
Options selected:
* Crypt password method: crypt-md5
* Validate users by emails: yes
* Registered Users can change password : yes
* Re-validate user by email after unsuccessful logins: 3

The option
''Send an email to the user in order to allow him to validate his account. ''
in /tiki-adminusers.php ''Add New User'' tab
is only available if in /tiki-admin.php?page=login
''Users can register'' is ticked
Then and only then the hidden option becomes visible:
''Validate new user registrations by email''

By tickinig it the option
''Send an email to the user in order to allow him to validate his account. ''
in ''Add New User'' tab bcomes availabale.
This option should be available independend if or not the option ''Users can register'' is selected.

The ticking of a hidden configuration shouldn't be relevant for any functionality.

At tiki-admin.php?page=general when "Server Fitness" is activated or clicked, the page never loads, and the rest of the tiki site stalls as well.
A browser reboot must be performed or browser clear cache in order to access the tiki site.

A show instance will be created to test if this issue persists here as well.

My own instance:
Tiki 18.2svn
innoDB
PHPv 7.0

This is a new feature arrived in BRANCH-1-9

1. add feature_print and checks
2. add tiki_p_print and checks

---
The above problem-description makes no sense... please look at tw#74 for that
---
Problem rephrased:

The "Source" button is currently dependant on tiki_p_view_history - it should have a perm of its own.

To reproduce:
* As a user with non admin rights insert a tracker item to dev.tw.o/tracker5
* edit it again, and change something (add some text to a text areas, etc.) And save
* you are not able to edit that item any more because the "Submitted by" field has lost the record.
* edit that item as a user with admin rights, adn manually provide again the username of the poster.
* the poster can edit it one more time. But after that, he loses the ability again.

...

Example:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2885
---
testing this bug
---
2nd edit

{syntax type="tiki" editor="plain"}
{syntax type="tiki" editor="plain"}
As the subject says...
You can try on this item for example: https://dev.tiki.org/item6279-Icons-Unseen-with-Fivealive-Theme

This is the default behavior in search engines like Google


Also reported here: [tiki-view_tracker_item.php?itemId=166]

and:
{QUOTE(replyto=BillMac)}
I have found that, if I want to find something on tw.o sites, I should disregard TW's search feature and use Dogpile to look things up. The TW search capability is so weak that it is almost "a missing feature." At the very least, "TermA TermB" searches should be "termA AND termB" not "termA OR termB." The plus/minus markers are fine if you're in the know, but they don't work well either. Using the category/group filters renders a whole different set of answers; not GOOD answers, just different. Without those filters, unauthorized users see parts of pages they are not supposed to see at all. Not a missing feature, a broken feature.

Gosh, I hate to be so negative.
{QUOTE}
Source: ((Major Features Missing in TikiWiki))

"tiki-edit_structure.php" Add Pages To Current Node list truncates at 50 records.

{syntax type="tiki" editor="plain"}
"Today" is highlighted for every month. If "Today" is Dec. 22, then Jan. 22, Feb. 22, etc. are also

In the Menu is an option "Dump" under "Wiki", if you enabled that feature. The link just points to the .tar - what gives a 404 from the Web-server.

I've been Argument Variables as described in http://doc.tiki.org/Tiki14#Wiki_Argument_Variables, using TikiWiki v14b and found a bug, it only shows correct information when previewing the version of the page, if you see the page itself, argument variables won't show:

Example not working of viewing the page:
{img fileId="990" thumb="y" rel="box[g]"}

Example working previewing the page:
{img fileId="991" thumb="y" rel="box[g]"}

Hi there,
I've been starting to use [https://doc.tiki.org/Search+and+replace|Search and replace] tool. Great piece of tool!

I've spotted a bug there when trying to change:
* from ~np~{IMG(src="img/flags/United_Kingdom.gif",title="en anglais")}{IMG}~/np~
* to ~np~{en}~/np~

This bug makes that I end up with a ''half-process done'' since the replacement job is finishing with:
* ~np~{en}"img/flags/United_Kingdom.gif",title="en anglais")}{IMG}~/np~

It does look that the function ''replace'' doesn't handle having a __"__ in the ''what to replace''.

After setting up and creating a poll with ID = 1

__Update:__ I was following the examples on the doc site for how to embed a poll. These examples typically are in the following formats. The examples throughout the docs should probably be updated to reflect the what actually works (see solution section below). I am a brand new user and am finding the documentation regarding the embedding of dynamic variables to be wrong in many cases.

When inserting any of the following:
{CODE()} {poll} {CODE}
''generates junk code in the rendered page''
{CODE()} {poll id=1} {CODE}
''generates junk code in the rendered page''
{CODE()} {pollId=1} {CODE}
''simply outputs pollid=1 in the rendered page''
{CODE()} {poll pollID=1} {CODE}
''ALSO generates junk code! So, it's case sensitive?''



''Details:''
I have tried several versions (just in case case sensitivity was a problem). This has also been reproduced with and without jQuery turned on. I have insured that the Polls option is available in the Text Field as well. Currently operating as an admin user with all capabilities turned on.

The "junk"is essentially html. Turning "Allow HTML" or "Try to covert HTML to wiki" has no effect. I __can__ get other dynamic content to work.

I only activated the feature and clicked on "Maps" in the menu - that gave me the mentioned 500 Error.

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

The annoying sanitizer strikes again, breaking our layout! See the link with "url" in it on the https://dev.tiki.org/item5731 for example! It becomes url as seen on many places :(
Cannot we have something more clever? what is wrong with "url" in common text or links?

luci

{syntax type="tiki" editor="plain"}
This is related to the Custom Site Header section of Look & Feel on our Web site. We put a top navigation bar which is expected to be showin in different languages depending on the visitor's language (look at http://www.daav.cn/cms/tiki-list_file_gallery.php ). The code in Custom Site Header is like this:

<div style=...>
<ul>
{if $prefs.language eq "cn"}
<li>link1 in Chinese</li>
...
<li>linkN in Chinese</li>
{elseif $prefs.language eq "fr"}
<li>link1 in French</li>
...
<li>linkN in French</li>
{elseif $prefs.language eq "de"}
<li>link1 in German</li>
...
<li>linkN in German</li>
{else}
<li>link1 in English</li>
...
<li>linkN in English</li>
{/if}
</ul>
</div>

however, it seems the top navigation bar is always shown in Chinese even when I set the default browser language to English only. At that time, our php-based language detector works correctly to identify the user/browser language as English (example: our homepage at http://www.daav.cn/ ) but tikiwiki remains in Chinese unchanged.

Is there anything wrong with the code or it's just because my Windows XP is in Chinese? Then how to get around this in Tikiwiki? What language do you get on the linked page that I included above?

Thanks for any hints.

{syntax type="tiki" editor="plain"}
See reasoning and details in 3139.

File attachments to a forum post results in 0 (zero) byte size.
* Results are the same using either database or file system for storage.
* File attachment description shows correct file size.
* Downloading the attachment results in 0 byte size.
* Files stored in database shows (using phpmyadmin) correct file size.
* Files stored in file system shows 0 byte size.

Configuration:
* "Can attach to forum posts (tiki_p_forum_attach)" set to allow.


You can log into the show.tikiwiki.org instance using "tester" and "tester". Attachments created as "admin" and "tester" are 0 byte size when downloaded.

---
Updated from Xavi:
Confirmed in trunk, and this used to work as expected at least in 12.x {sign user="xavi" datetime="2016-01-20T10:04:07+00:00"}
I fetched a snapshot of the b dump (since there was no admin password indicated in the bug report, and to make it easy to see any apache error message logged in the server), but I don't get any error shown in the local apache logs (using trunk).

---
Apologies... "admin" and "tikiwiki"

Using 1.10 cvs from mid september 2007. Using hec.css theme

At admin > login > Users Defaults, I've set
^
-=My Tiki=-
My pages V
My galleries
My messages V
My items V
^

Example of user page viewed by another user or anonymous:
http://intercanvis.net/tiki-user_information.php?userId=20

Issues:
# Wiki pages ("Pàgines del wiki") are wrong: they are not from that user (confirmed, even if you cannot see history on pages on that site)
# "My items" shoud show, at least, some items added by that user:
+ [http://intercanvis.net/tiki-view_tracker.php?trackerId=3&status=op&sort_mode=lastModif_desc&filtervalue%5B25%5D=&filtervalue%5B43%5D%5B%5D=6&filtervalue%5B43%5D%5B%5D=45&filtervalue%5B43%5D%5B%5D=7&filtervalue%5B43%5D%5B%5D=44&filtervalue%5B43%5D%5B%5D=8&filtervalue%5B43%5D%5B%5D=5&filtervalue%5B43%5D%5B%5D=55&filtervalue%5B26%5D=&filtervalue%5B28%5D=Anna&filtervalue%5B44%5D=y&filterfield=28&filter=Filtra|2 on one tracker]
+ [http://intercanvis.net/tiki-view_tracker_item.php?itemId=38&trackerId=2|and one on another tracker]

Forum messages are shown ok.

Using 1.10cvs from mid June 2007.

This problem is on at: http://moviments.net/intercanvis

User tracker is on, it's created and working (at registration time everything is ok and working, user sets new data for the user tracker info before ending registration, etc.). Well, at least for Registered users.

This morning I went (as a user with admin privileges) to User Preferences screen > Personal information > Your personal tracker information: "View extra information" (link to [http://www.moviments.net/intercanvis/tiki-view_tracker_item.php?view=+user] ),

but at that link I get this message:

^
-=ERROR=-
No tracker indicated
Go back
...
^
This user belongs to Admins, Editors and Registered groups, but has no one defined as default.
When defined a default group (Registered, the only one with user tracker defined), the link worked.

If using tabs, after creating a tracker, the user should be directed to the form of listing trackers ("Trackers" tab), and not remaining at the "Create trackers" tab, as it does right now, since the normal procedure after creating a tracker is either granting it with local perms of just creating fields for that tracker (so that you need to see the "action columnn" in the table at "Trackers" tab.

Using 1.10 cvs from mid june 2007

To reproduce:
# Create a new tracker with Google map field, plus other fields, on a tiki site created with basic profile for easy use.
# Log in as registered user (not admin)
# Insert an item (as registered).
# Edit the item, to click to "Google map locator" to geolocate the tracker item
# After cliking on the map (so that having coordinates and zoom for this item), you click on "Save clicked point" button
+ After that, you see on top: "OKOK", and the Google Map locator again.
"The OKOK" message should be removed, and I suggest that the user is automatically taken back to the tracker item after clicking on the "Save clicked point" button

Using recent 1.10 (end of november'07):
today December 8th 2007 I've set a new event at a calendar:
http://intercanvis.net/tiki-calendar.php?todate=1197068400

If you view this calendar as anonymous you see the correct date in both places:
# Focus: Dissabte 08/Desembre/2007 (08/12/07, Saturday)
# Cel (current and focus) date: 12/08

However, if you login as plain registered user, this same url:
http://intercanvis.net/tiki-calendar.php?todate=1197068400

...it takes you to: "Focus: Friday 07/December/2007" (user abel, for instance), which is wrong: it should be 08/Desembre/2007

And if you login as user with admin rights (user Xavi) , the same url shows:
# Focus: Dissabte 08/Desembre/2007 (08/12/07, Saturday)
# __BUT Cel (current and focus) date shows__: 12/07,
+ which is wrong: it should be 08/Desembre/2007
+ (if you click at teh event view, the date is set right: 08/12/07)
-----
Further Update:
This is kind of weird: I had prefference for new users as "site default", and site language was either English or Catalan, amnong the few allowed languages for users.
I checked language of user "abel", and it had "Arabic" (which was not among the pre-selected as available for users).

I changed default language for all users as Catalan, and ensure the only Catalan, Spanish, English and French were allowed. Then, again, tried viewing this date:
http://intercanvis.net/tiki-calendar.php?todate=1197068400

with user "usuari", which has language selected to English: date in calendar is shown fine.
# Focus: Dissabte 08/Desembre/2007 (08/12/07, Saturday)
# Cel (current and focus) date: 12/08

However, if I login as user "abel" (with Catalan interface), weird change in date shown is produced:
# Focus: Dissabte 08/Desembre/2007 (08/12/07, Saturday)
# Cel (current and focus) date: 12/07 __1 day less than it should__

I can enable an account there for any admin who want to track/hunt this bug, if needed.