Category: All / Undefined

{syntax type="tiki" editor="plain"}
When there is an error, such as trying to go to a non-existent page, e.g. tiki-index.php?page=sadjklfjadklfjlkds

the error page has the header appearing below the error.

You need search to be turned on (problem does not occur in mysql search though).

With feature_search enabled errors produced from error.tpl etc end up with the header, modules etc being repeated inside the page under the error message.

This can be seen here: [http://demo.tiki.org/12x/made+up+page] {sign user="jonnybradley" datetime="2013-10-13T16:13:38+00:00"}

This is a side-effect of the change to using Smarty Inheritance in the tempting system and due to tiki-searchindex.tpl now using "{extends 'layout_view.tpl'}".


Should also happen with feature_search_fulltext but the logic's borked currently... will fix that once this is fixed.

IE9, Firefox, Chrome all display this as soon I try to access doc.tiki.org.

Fatal error: Allowed memory size of 201326592 bytes exhausted (tried to allocate 71 bytes) in /home/two/doc/lib/init/initlib.php on line 167

Workspaces (from ((doc:Mod AulaWiki)) are half broken on 1.10 since months ago.
Any action which is related to workspce calendar module gives fatal error (blank screen). Adding resources to workspaces also fails:

^
Fatal error: Call to undefined method WorkspaceResourcesLib::get_url_admin_file() in /var/www/tiki110/lib/workspaces/resourceslib.php on line 117
^

On this url (on an updated site to 1.10svn from May 2nd):
[http://moviments.net/cursos/tiki-workspaces_view_module.php?module=workspaces_resources&workspaceId=110]


http://edu.tikiwiki.org is also having the same kind of problem, on a less updated 1.10 site.

{syntax type="tiki" editor="plain"}
Although enabling the "mindmap" feature in Tiki 4, when entering the mind map menu item, it says that the feature is disabled.<br />
<br />
I really hope I writing this in the right place and that there's no open ticket on this. I'm a "2 days old" user .. trying to do my best to help.<br />
<br />
NR.

The File Gallery Template feature is still in Tiki, and it seems nobody really knows what it was used for, if you will here is something I wrote a couple years ago on this, at https://tiki.org/forumthread59522
If this is supposed to work somewhere, it sure would be great to have it working if the intentions were to build upload templates from it.
Thanks for looking
John

http://doc.tikiwiki.org/tiki-index.php?page=Features

Using the default fivealive theme on tiki.org and on a fresh install has the unwanted effect of the right hand column being far off to the right, and below the content (have to scroll down & across to see it).
Using Firefox 3.0, Linux.

Trying to create a show instance with Tiki 18.x

floatval() gets used in tiki-register.php and is not available in PHP < 4.2

I have a TikliWIki as startup in one of two frames. The other frame has a number of links that are supposed to open in the Tikiframe. But if tiki-index.php has been opened in that frame, subsequent documents opens i new windows (in IE) (as if target=_blank had been used) och new tabs (in FF).
If index.php is the only document that has been opened (when the mysql-connection is broken) everything works, but as soon as I try tiki-index.php, the problem comes back.

I would suggest the creation of two simple tikilib functions: have_permission() and feature_enabled(). These functions need to take the name of a Tiki permission or feature respectively, and should return a boolean if the permission is set, or feature enabled.

These two functions are obviously pretty simple to implement. After their introduction, all Tiki applications should be migrated to use them (a job I would suggest may take until 1.11 or later!).

The benefits of doing this include:

* Less programatic reliance on global variables
* No need to read entire permissions or feature database tables to return each page
* Lower in-memory information required to run the application
* Allows for finer grained permissions and feature control without affecting scalability
* Permissions and features can subsequently be replaced by more sophisticated, scalable, usable or effective solutions later without futher disruption to applications.

The last point is the key here: Whilst there are currently hundreds of permissions and features, there are lacking in places where they should exist. Clearly adding yet more permissions and features isn't really viable.

Also, having a replaceable solution means it would be possible to move to an "entitlements" based solution without breaking the entire system. Entitlements may offer a way to provide extreme customisation abilities, with scalable and flexible permissioning, control of features etc.

The subject of permissions and feature control is obviously broad. This RFE only aims to facilitate the future discussion and adoption of a more generic model for control of the application.

We have been using group homepage redirection at login time for months on 1.10cvs with no problems. But in the latest couple of months, I would say, some bug might have been introduced since it stopped working recently ago, just after a cvs update.

We've noticed that if we uncheck: "Go to group homepage only if login from default homepage:" (at Admin -> General), then redirection works again (but we loose the right direction when somebody gopes to the tiki site after clicking to a forum post url from their email program on local.

The following patch adds negated group support to TikiWiki. Using this patch, you can choose to hide modules from users that ''are'' in a given group, by simply specifying the group name as !Group.

The patch is in production use on the [http://www.asperger.asn.au|Asperger Services Australia] website. I'll see if I can come up with some screenshots shortly.

http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/branches/4.x/changelog.txt (got link to that from -german- http://doc.tikiwiki.org/Tiki4) contains link to http://tikiwiki.org/ReleaseNotes42 which does not exist

Please ignore. This is not actually a bug or feature request.

Icons available for assignment to QuickTags are not displayed in the Tiki editor, nor is the path to them. This is a major usability bug for Tiki admins and end users who have no access to the server's file system, particularly because Tiki does not permit assignment of QuickTags without an icon.

I would like to see an option to assign QuickTags without an icon (text title only) plus an interface to display and select icons. (Personal preference: text title only; I am not an icon lover.) Icons already in use should either not be displayed for selection or the fact of already being in use should be clearly indicated.

In HTML source, line 3 character 1 produces a syntax error in Microsoft Internet Explorer - but only when setting the site language to German.

This character is a tab stop. However, I haven't found out the difference between this one and the tab stop used in English.

Site: http://list.vic-fontaine.com/
Test user/pw: smarty

This effect can be reproduced with clean installations as well.

When a file (image) is selected for insert in a page, and when the "Mouseover - enlarges in popup when moused over" Thumbnail parameter is set, the mouse over does not function correctly.

Please see how the file(image) mouse over is supposed to function at http://tpwtestuser.com/tiki12/tiki-index.php?page=Image+Mouseover+Test and hover over the image at this tiki12 test site.

Please see how the file(image) mouse over does not function at a tiki14.2 and a tiki15 beta site. When the cursor is hovered over the image, the image does not appear or display. But if you click on the image, the image does have a mouse over behaviour, but it is the incorrect behaviour, as the image should enlarge by simply hovering over the image.
---
(Tiki14.2) http://tpwtestuser.com/tiki/Image+Mouseover+Test
(Tiki15) http://tpwtestuser.com/tiki15/tiki-index.php?page=Image+Mouseover+Test
UPDATE 4-12-16: The above links now show mouse-over functional using geeza's fix as suggested at the comments page of this bug report. Though the action still needs some work as far as size of pop-out and image placement.
---
Here is the link to the tiki.show instance at http://jmorris-11758-5895.show.tikiwiki.org/tiki-index.php?page=Image+Mouseover+Test

Thank you for considering this in your line up of bug fixes!
John

I've been thinking about this quite a lot lately.

When I create a ticket and I type the first letter of my ticket, I'm suggested previous and existing ticket based on a filtering of my typing. But this is not useable at all and likely no-one look at it. As proof, we have a lot of duplication. See my screenshot below this is not useable.

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

If you include RSS feeds in modules or Wiki pages (in fact, anywhere that $tikilib->parse_data is used) then links always open in new windows.

This should (in my view) default to open in the same window, with a config option to change. It might be possible to do it in the {rss id=} pseudo tag? That might be the least hassle option?

Either way, all the fun is in tikilib.php, and affects all versions from 1.8 to 1.9 (I think 1.6 onwards, but don't quote me!)

Wiki 6 is incorrectly parsing text in wikilinks, in 4 and 5 this ~np~((Easy and Play|Easy & Play)) ~/np~ produced a wikilink like: Easy & Play

In 6 it produces : Easy & amp; Play

It is not possible to circumvent this by using an np command or by using ~038~ as per the documentation, that produces #038 rather than &

Why is the text that follows | in a wikilink not parsed as any other text ?

This bug is tied to [http://example.com|http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1964&trackerId=5&show=view]

I have had various issues navigating my wiki seemingly because $base_url is not getting built correctly, or at all. The first of these issues happens at login where the user puts in a bad username or password. The redirect to the error page fails on Firefox and has a URL with doubled forward slashes after the domain because the $base_url is not getting passed. URLs get built as follows (where 'example.com' is my domain):

Firefox:
{img src=images/code.png}%%% {CODE()} http://example.com\/tiki-error.php?error=Invalid+username {CODE}

IE:
{img src=images/code.png}%%% {CODE()} http://example.com//tiki-error.php?error=Invalid+username {CODE}

This happens with relative URLs all over tikiwiki in my installation, which is a WAMP with virtualHost entries in the httpd.conf to resolve 2 distict domains on the same server.

Have a look at this older post on dto:

https://dev.tiki.org/item7913-Migrating-18-8-to-21-4-fails-utterly-breaks-layout?highlight=update+cycle

It is currently being rendered to the screenshot (cf attachment), completely illegible. Without starting a new discussion on Tiki breaking existing layouts: What went wrong? dto was to my recollection not built on acient versions, but fairly up-to-date ones. My browser today is a current MS Edge on W10.

If something like the screenshot can still happen, how can an admin protect his/her website against that? How can it be remedied? Large sites like dto cannot be checked page by page for layout breaks...

Thanks
hman

Printing pages is sometimes a real mess.
So, http://www.printwhatyoulike.com brings the opportunity to select parts of the page to print etc.