Category: Usability

{syntax type="tiki" editor="plain"}
When I create a link to a Wiki page, the editor changes the reference of the link until the fourth time when I edit the page, but this is not a problem. The problem occurs when the link points to a wiki that has a special character, for example - cabeçalho - which means header (in Portuguese from Brazil), since the editor corrupts the link and it crashes.

Here I have an example.

The link should point to the wiki - Projeto de Pesquisa Social: Quem somos nós ? Proeja 2010 - is corrupted by the editor and points for - Projeto+Pesquisa+Social:+Quem+somos+n%C3%83%C3%83%C3%83%C3%83%C3%83%C3%82%C2%B3s?+Proeja+2010 -


Here we have a wiki page as an example:
http://www.biblioteca.ifc-camboriu.edu.br/criacitec/tiki-index.php?page=Example

{syntax type="tiki" editor="plain"}
On tiki-admin_modules.php, the "Add module" button should link to the first tab "Edit module", not "Custom modules", because in most cases an existing module will be assigned, not a new custom one created. (The Edit module tab content contains the heading "Assign new module", which reflects that process.)
* So the "Add module" button link should be tiki-admin_modules.php?edit_assign=0&cookietab=1, not tiki-admin_modules.php?edit_assign=0&cookietab=2.
* Thinking about it more, it seems like the first tab label should be "Configure new module", not "Edit module", to better reflect the content of the tab. Modules are edited after being assigned, from their actions link, not in this tab, or else are edited as custom modules, but again not here.
* The "Assign new module" heading in the first tab content can then be removed, as it would be redundant.
I believe the button link issue is a regression but I don't know when it happened offhand.

Another thing, after selecting the module to assign, the page refreshes to an "Edit module" tab and there's a heading "Edit this assigned module: login_box". This is a smaller issue, maybe, but this heading is incorrect because the module is not yet assigned, which might confuse new users. To be accurate, it should be "Edit module: login_box".

When trackeritems have permissions (i.e using a category field) and permissions are set so that only certain usergroups can see certain items (based on their category), then pagination does not work properly.

Example:
Tracker has 50 items. Only item 2 and item 28 is accessable to user "Peter" due to permissions..
If "Peter" open the trackerlist, he will see only one item on the first page, and need to go to the second page to see the other one.

Expected behaviour would be:
"Peter" sees just one page with two items.

This effects also tablesorter when being used.

Fixed in 14.x r55304 and trunk

Environment: Windows Server 2008 + IIS7

Problem: After installation, you're directed to tiki-change_password.php. The URL ist correct (in my case: "http://www.prohibition-online.com/tiki-change_password.php[...]"). I change the password and land on "http://www.prohibition-online.com/tiki-index.php".

Now I click onto logout and the URL I get to is:
"http://www.prohibition-online.com\/tiki-index.php".

Notice the "\" after my website name.

If I remove the "\", I access my index page as expected.

When I login, the "\" reappears.

same error as: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2250&trackerId=5&show=view

When I click a user, I am offered to send him a message. But then I get:

User XYZ can not receive messages
ERROR: No valid users to send the message

1: WYSIWYCA: I should not be offered to send a message if the user has disabled that. (frustrating to write such a message for nothing)

2: tiki-user_preferences.php: "Allow messages from other users" default should be yes

3: tiki-user_preferences.php: "Send me an email for messages with priority equal or greater than:" default should be "3"

tiki-admin.php?page=login
3- Users accept internal messages by default: default should be yes -> $allowmsg_by_default

4- Users can opt-out internal messages: default should be yes -> $allowmsg_is_optional


All these should be the default settings (most logical) if a Tiki site admin choose to activate inter user messages.

Related:
Easier Inter-user message management for Tiki admins:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=959

Also related:
Should sender email be disclosed when receiver gets notification via email? goals: balance privacy & facilitate communication/collaboration

If I add a poll in a module, a registered user can see it even though he can't vote.

{syntax type="tiki" editor="plain"}
As seen at http://dev.tiki.org/tracker5, users have a link to edit trackers, but they can't.

{img fileId="261"}

I have a strange problem on Tiki 2.0RC2:

I have two similar TikiWiki-installations. One just for testing on my Linux-Server and the second on a WinNT-Server. The Windows-Server is the one we want to/have to use for our Wiki :-(

On my Linux-Server works everything.

On the Win-Server don’t work wysiwyg-editor’s “Insert/Edit an internal wiki link”-button. The “window” opens but it shows only this animated waiting-bar. (See the picture)
Any other button works fine!

Right now using 1.10svn code when using wysiwyg you are not allowed to use ! (headings) and * or # (lists) as wiki markup (it gets shown as simple text, even if placed at the beggning of new lines)

According to http://doc.tikiwiki.org/Wysiwyg+Editor+Admin (April 10th, 2008) , the setting "__Content is partially parsed__" just includes:
* parsing of links
* parsing of images and generally what is included in { }
* parsing of wikiplugins

Header and butllets are vey simple and common wiki markup that would help mixing conent in wysiwyg pages from newbies on tiki 1.10 sites and more experienced users (not much skills needed for that markup)

{syntax type="tiki" editor="plain"}
When you edit text using the WYSIWYG editor, extra <br /> tags are added when the text is displayed in preview or when it is saved. These break tags do not show up when you try to edit the page again, making them impossible to remove.

For example, if the markup in the WYSIWYG editor, when you view the source, is as follows:

''<p>This is some text.<br />This is some more text, on a new line</p>''

What shows up when you view the source of the page that is generated after you save/preview is as follows:

''<p>This is some text.<br /><br />This is some more text, on a new line</p><br />''

As a result of this, the spacing on pages edited by the WYSIWYG editor is bizarre and stretched out.

When one is using the WYSIWYG editor to edit text, extra <br /> tags are added after all <p> and <br /> tags when the text is displayed after save or preview. These tags don't show up in the source code in the WYSIWYG editor at all, so you can't remove them. As a result, the spacing between the text is all wrong.

For example, if you view the source of a page in the WYSIWYG editor, it would look like this:

<p>Some text<br />And more text on a new line</p>

But when you view the source of the page after you have saved it, it looks like this:

<p>Some text<br /><br />And more text on a new line</p><br />

This tracker item could not be found

The WYSIWYG editor has a transparent background that seems to be hard-coded and unaddressable by css. It appears in an iFrame so the page's body background colour is seen in the textarea.

This makes it unusable for themes with dark backgrounds like Strasa as you have basically black-on black text.

In version 12 the Wysiwyg editor is no longer an experimental feature.
The wysiwyg help text should be updated.
The help text should cover both fullscreen and inline editing, since the toolbar icon to display it is there for both.

{img fileId="435"}

This seemed to be working correctly on my previous version of Tiki Wiki (18.x). However, some of the primary WYSIWYG buttons are now unusable.
This same behaviour can be seen on the [https://demo.tiki.org/18x/tiki-editpage.php?page=HomePage|demo Site].

In WYSIWYG mode, the link buttons show the dialog, but does not 'insert' and the table builder button show s a dialog without any rows to insert.

The browser console error I'm getting when clicking the Table Builder button in WYSIWYG mode is as follows:
{CODE(theme="default")}
tiki-toolbars.js:92 Uncaught TypeError: Cannot read property 'indexOf' of undefined
at dialogSelectElement (tiki-toolbars.js:92)
at dialogTableOpen (tiki-toolbars.js:394)
at HTMLDivElement.open (eval at <anonymous> (tiki-toolbars.js:50), <anonymous>:1:25)
at $.(/tiki/anonymous function).(anonymous function)._trigger (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:697:13)
at $.(/tiki/anonymous function).(anonymous function).open (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:12215:8)
at $.(/tiki/anonymous function).(anonymous function).open (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:144:25)
at HTMLDivElement.<anonymous> (jquery-ui.js:256)
at Function.each (jquery.js:354)
at jQuery.fn.init.each (jquery.js:189)
at jQuery.fn.init.$.fn.(/tiki/anonymous function) [as dialog] (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:236:10)
{CODE}

Most icon images are absent from the WYSIWYG toolbar when using Firefox. The below table lists experimentation results. I did disable all Firefox browser add-ons as part of the testing. This issue does not effect the Wiki toolbar.

The problem does not occur in the "Show" instance that was created. This tells me the problem is not entirely browser specific, but some combination of site settings with Firefox create the problem.

||__Computer__|__OS__|__OS_Ver__|__Browser__|__Browser_Ver__|__Result__
::Rorschach::|::Linux::|::Mint 14::|::Firefox::|::25.0.1::|::Broke::
::Rorschach::|::Linux::|::Mint 14::|::Opera::|::12.16::|::Works::
::Snowball::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Snowball::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::works::
::Darkknight::|::Linux::|::Mint 14::|::Firefox::|::24.0::|::Broke::
::Darkknight::|::Linux::|::Mint 14::|::Midori::|::0.4.3::|::Broke::
::Redwood::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Redwood::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::Birch::|::OS X::|::10.6.8::|::Firefox::|::25.0.1::|::Broke::
::Birch::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::Gem::|::OS X::|::10.6.8::|::Firefox::|::23.0.1::|::Broke::
::Gem::|::OS X::|::10.6.8::|::Safari::|::5.1.10::|::Works::
::WinXP::|::Windows::|::5.1 SP3::|::Firefox::|::25.0.1::|::Broke::
::WinXP::|::Windows::|::5.1 SP3::|::IE::|::8.0::|::Works::
::Aiuto::|::iOS::|::4.3.3::|::Safari::|::-::|::Broke::%%%(never loads)
::BCi::|::iOS::|::5.1.1::|::Safari::|::7534.48::|::Works::
::BCi::|::iOS::|::5.1.1::|::Ghostery::|::1.3.1::|::Works::
::iPS::|::iOS::|::5.1.1::|::Mercury::|::7.4.2::|::Works::
::iPS::|::iOS::|::5.1.1::|::Ghostery::|::1.3.1::|::Works::||

{syntax type="tiki" editor="plain"}
We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

This bug is across all browsers.

Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it.

I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation.

I have tried in both IE 8 and FF 3.6 with the same result.

Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499]

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not edit a section using the Edit Section button. A blank WYSIWYG screen is displayed and if you enter content and save it gets thrown to the bottom of the wiki page and not within the section.

Reproduce: Create a blank wiki page in WYSIWYG, create a bunch of headers, save, view edit icons (if not already), click on "Edit Section" button.

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not format the header (color it red) without breaking the "header" status.

Currently we have a page with a ~np~{maketoc}~/np~ at the top and a bunch of h1, h2, h3 headers. We wanted to make the text color red for one of the h1 titles so it was more visible to users. Once we did this in the WYSIWYG editor, the header is no longer listed in the maketoc AND the Edit Section button is gone next to the header text. This ''may'' be associated with another bug [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3763].

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%% the lists (numbered and unordered) have irregular spacing between lines. Edited in Wiki normal and WYSIWYG Source modes work fine.

To reproduce create the following structure in a WYSIWYG editor{CODE()}*blah zaa zaa
*This is a list
**now indenting the list
**blah
*back out
**back in
***really far in
*all the way out{CODE} %%% this example displays for us as {CODE()} blah zaa zaa

This is a list

now indenting the list
blah

back out

back in

really far in
all the way out
{CODE} %%% Sometimes there is a break, other times there is not. If I Preview while editing it looks fine. If I edit the HTML via the Source WYSIWYG view and save then it looks fine until I save it in WYSIWYG mode again.

{syntax type="tiki" editor="plain"}
Put the following in 11.x

{CODE()}# lorem ipsum
** lorem ipsum
# lorem ipsum
{CODE}

Then, preview, and compare

Sub-question: how does one do a ** in WYSIWYG? Normally, there are arrows to indent.

In IE & Chrome, it's OK

{img fileId="678"}

When you modify a wiki page and press the help (?) sign to display the plugins once you have chosen a plugin and instead of save you close, you can no longer access the plugins unless you reload the page again.
and if you press save and then you want to use another plugin without saving the changes on the wiki page, the plugin configuration page will not appear until the page is reloaded

Hello,
Problem with:
- Zotero bibliography
- Zotero Bibliography Search Module

I followed the [https://doc.tiki.org/Zotero|documentation] and setup everything as it should be, but the mentioned plugins did not work.

- Can somebody confirm the plugins actually work ?

- From my server errors log:
~np~PHP Fatal error: Call to undefined method Zend\\Http\\Response::isSuccessful() in .../tiki/htdocs/lib/zoterolib.php on line 54 ...~/np~
- The isSuccessful() method is in: /tiki/htdocs/lib/zoterolib.php
- The isSuccessful() emthod is called on lines 54, 111 and 161

- Changing isSuccessful() to isSuccess() the error seems to be fixed, but the Zotero plugin is not working.
- I think using or relaying on Zend and tags to get feedback or content from Zotero may not be very good.
- Something like [https://github.com/ddean4040/phpZoteroWebDAV|this framework](phpZoteroWebDAV) would be much better.
Thank you.

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?