Category: 3.x

It is possible to enter tags made from more than one word by entering them between "". Since 3.0, the system seems to still recognize those tags (they are rendered correctly in the "Most popular tags" module, but clicking on such a tag comes up with "0 results found". The same applies for the Folksonomy module, which shows correctly, but comes up with 0 results for such tags. It does not matter if the tagged object is a blog post or a wiki entry.

It is possible to enter tags made from more than one word by entering them between "". Since 3.0, the system seems to still recognize those tags (they are rendered correctly in the "Most popular tags" module, but clicking on such a tag comes up with "0 results found". The same applies for the Folksonomy module, which shows correctly, but comes up with 0 results for such tags. It does not matter if the tagged object is a blog post or a wiki entry.

In 1.9, templates_c existed with some administrative files (templates_c/index.php, etc.):
http://tikiwiki.cvs.sourceforge.net/tikiwiki/tiki/?pathrev=BRANCH-1-9

Since we moved to SVN, in time for 2.0, this was "lost"
http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/branches/2.0/

This causes that people that install TikiWiki via FTP, from zip file, --need to manually create this folder (useless annoyance)-- Actually, it was created by tiki-install.php but I see no reason not bundle this folder.

People that use sh setup.sh to install are OK because this script creates this directory (and others?)

A lot of people install with FTP.

They do not have shell access and do not run setup.sh

Up to 1.9.11, templates_c was part of the .zip

However, for some reason, in 2.x and 3.x, --you need to manually create this directory.-- Oups, no, installer created. Nonetheless, the directory is back in 3.0

This should be restored to previous behavior.


1- It should have an index.php to prevent directory browsing
2- ((TRIM)) cleaner should not delete this index.php
3- clear caches in tiki-admin_system.php?do=templates_c should not delete this index.php

Suggested message if PHP5 is not detected:

^
__TikiWiki 3.0 requires PHP 5.x__

Your currently detected PHP version is: (versionnumber)

Please contact your web host to request an upgrade. If there is no way you can have PHP 5.x, please use Tiki 2.x instead. Some features in Tiki 2.x, such as profiles and TikiTests require PHP5, but all the other hundreds of features work perfectly with PHP 4.1+

For more information:
http://www.gophp5.org/
http://tikiwiki.org/
^



(9:59:42 AM) marclaporte: turning on TikiTests crashed by site :
(9:59:42 AM) marclaporte: Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /home/profiles/public_html/tiki_tests/tikitestslib.php on line 59
(9:59:53 AM) marclaporte: I suspect because I don't have php5
(10:00:01 AM) marclaporte: http://profiles.tikiwiki.org/

This would avoid this type of issue:
http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=6&comments_parentId=21274

Maybe at each release, we could add one test of the DB to see if the most recent sql additions were done.


phplist does this well. Once click and your DB is in the right format.

{syntax type="tiki" editor="plain"}
The Directory batch feature imports all documents except those with an accented character like 'à','è'.'é' or special caracter like Euro symbol (€).

Environment:

Ubuntu Server 8.04
ISPConfig 2


Note: Maybe something related with the bug_id:2821

When you run the image gallery with a lot of images in it with multiple columns, none of the images get scaled! They are displayed as it is

When you try to access a wiki page which doesn't exist, Tiki offers you a list of similarly named pages, to search for that word, to create the page, etc.

__Good.__

When you try to access other contents in Tiki (articles, blog posts, etc.) that don't exist (either have been deleted, moved, not yet published, protected, etc.), you get a Tiki error message.

__Good as well.__


But what if you try an URL which is just not possible?

Ex.: If you migrated from another system to Tiki and you are still getting hits with the previous URLs?

Of course, you could check your access logs and add nice redirects. But how can we make this easier for site admins?


The bundled _htaccess file (which you need to rename .htaccess to make active) has an example line:
{img src=images/code.png}%%% {CODE()}
ErrorDocument 404 /tiki-index.php?page=Page+not+found
{CODE}

__This is good.__

Now, how could we use this to provide the Tiki admin with a top-x error pages? And thus, it would help to detect broken links, etc.

Could .htaccess include some configuration info from Tiki? So a Tiki admin could add configuration information without using FTP, all in Tiki, possibly with a secret "system" wiki page.

Great inspiration:
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess

{syntax type="tiki" editor="plain"}
Tikiwiki 3.1 issue when replying to a forum posting, the following error occurs. This does not happen with Tikiwiki 3.0

Not Found

The requested URL /forumId=1&comments_parentId=1&thread_sort_mode=commentDate_asc&post_reply=1&comments_threshold=0&comments_reply_threadId=2&comments_offset=0&thread_sort_mode=commentDate_asc&comments_per_page=20&comments_grandParentId=1&thread_style=commentStyle_plain was not found on this server.

This is apparently a known issues that has not yet been fixed.

(http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2009-07-25,Sat&text=on)

Thank you.

Mike Petosa

{syntax type="tiki" editor="plain"}
Tiki and Pear::Auth (LDAP) authentication doesn't work together in
version 3.0. A tiki local user can't log in anymore if the Pear::Auth
method is set, except admin.

All TikiWiki pages don't load with the mentioned plugin activated. All I did was an update from 3.0 to 3.1... Afterwards, TW didn't work any longer. When I deactivate the plugin, everything's okay.

I believe this has to do with a specific TW feature, but I can't make out which one...

I'll try to find out more about this problem, and will all I can find out to this bug report.

This site dev.tikiwiki.org works fine however...

To reproduce the problem, go here: http://list.vic-fontaine.com

{syntax type="tiki" editor="plain"}
The __Redirect__ plugin takes two parameters:
* page = foo (to redirect to a wiki page)
* url = http://foo.com (to redirect to any other page)

However, Tiki sanitizes the __url__ parameter, creating url, which breaks the plugin's redirection.

Use case:
*Manage many sites/domains with one Tiki installation
*"Park" all the domains on top of each other and get Tiki to send people to the right page depending on the domain.
*Common user base & permissions
*Theme control to provide different theme per section/category/page
*Could be different domain per language

Ideas
*Maybe domains could be links to categories. Put a page in a category and it gets its theme from theme control center
*Modules per domain
*If on page for domain X, force/rewrite URL to that domain
For example
^www.musicband1.com/introband1
www.musicband2.com/introband2
www.musicband3.com/introband3

So if I go to:
www.musicband1.com/introband2
I am redirected to
www.musicband1.com/introband1^


Limitation:
*pagename collision. Ex: domain1.com/intro = domain2.com/intro
*Single shared search engine
*Meta-tags will be shared

Also need to think about the Use Case where different workgroups want different domains. (A bit like *tikiwiki.org sites)

With new Tiki4 Workspaces, we could associate the domain as a preference.

What happens if a wiki page is in many categories, and they have different domain names. How would the priority work? Random? An order? Same idea as default group?



Related:
((WikiFarm))
((TRIM))
((Workspace))

When giving a group the permission

tiki_p_admin_wiki

it is not enough to add a page to a structure. The corresponding input field on tiki-index.php just doesn't appear.

{syntax type="tiki" editor="plain"}
tiki_sessions doesn't keep track of most users/visitors since Tiki 3 (was working in Tiki 2). This impacts only modules, AFAIK: who_is_there, last_visitors, online_users and logged_users.
The modules show only the logged in users who are also looking at other users. So you'll see other users of mod-online_users, but not users which use none of these modules. This is actually a tiki-setup bug introduced in r15587. As the log message reads,
"update 'tiki_sessions' table only when one of the related functions is called, not anymore all the time"
This does improve performance, the "only" problem is that tiki_sessions then doesn't track new logins, except via a few tikilib functions which call update_session().

theme: TheNews
common problem when badly closed tags appear in the generated page source
left/right modules colums go down, cannot click to edit the category then

{syntax type="tiki" editor="plain"}
1- Turn on multilingual
2- restrict to 3 languages
3- go to compile one of the three

Notice crazy stats :-)

There are some settings to
#force a user to validate an email addresses by clikcing a link
#for admins to need to click a link in an email to approve a new account.

But what if emails aren't getting through or to go faster?

An admin should be able to validate an account manually








__Duplicate__
{wish id=1710}

I created a sheet with this data set:

|| -1 | test
1 | test2
2 | peres
5 | peres
10 | pomes ||

When I click on graph this data sheet (to select type of graph, etc.), I cannot select anything becasue I see a WSOD.

tiki-graph_sheet.php?sheetId=N


Using proposals/3.x r24782

Using a fresh checkout of r15460, and a clean database, install script reports:

Success Installation operations executed successfully: 1164 SQL queries.

Operations failed: 1 SQL queries.

SELECT patch_name FROM tiki_schema
Table 'tikiwiki3.tiki_schema' doesn't exist

tiki-lastchanges.php does not show the current edit comments for a page that was edited.

Steps to repro:
1. Edit any page, and fill out the 'Edit Comment' field.
2. Go to the tiki-lastchanges.php page, and the page edit is there, but no comments are seen.
3. Return to the edited page, edit,comment and save again.
4. Go to the tiki-lastchanges.php page, and you will see the previous comment, but not the current.

Should not show IP, source, history, etc. if the features are off.

tiki-print_pages.php should allow to set the parameter tikiversion at printing time, if Plugin Versions is being used. Example: doc.tw.o of twforsmarties: print documentation for veersion 1.9.x, 2.x or 3.x.
http://doc.tikiwiki.org/tiki-print_pages.php

http://twbasics.keycontent.org/tiki-print_pages.php

Right now, if I want to print the full structure of the documentation, I can't chose version (so that the default is shown)


marclaporte: and the same idea should apply to language. Show me doc in my language, if there is none, fall back to available language.

Trackers can have many fields.

Multilingual is a way to have multiple values.

Native multi-valued trackers would be useful in certain circumstances.

Another way is to use ((doc:Category Tracker Field)) or ((doc:Items List and Item Link Tracker Fields)) or ((doc:Drop Down - Radio Tracker Field)) with multiple choice option. Probably the best is to build upon the ((doc:Relations Tracker Field)).



We would also want multiple sets.

First Name 1 (field 46)
Last Name 1 (field 47)
Address 1 (field 49)

First Name 2
Last Name 2
Address 2

First Name 3
Last Name 3
Address 3

First Name 4
Last Name 4
Address 4

Could we imagine a new tracker field type "Set of fields":
Fields: List of fields in the set. ex.: 46,47,49
Number of repetitions: ex.: 3

This would create artificial fields (in this case 46-2, 47-2, 49-2, 46-3, 47-3, 49-3, 46-4, 47-4, 49-4)

So these fields could be used independently (ex.: 47-2), but since they are linked, we could have some smarter handling for forms, reports and exports.

We could want the input form to by default indicate only the first set of fields, and via jQuery, show additional set of fields.
We could want a report/export of this "Set of fields" which would aggregate everything in one listing.

{draw id="28"}