Category: Conflict of two features (each works well independently)

Problem noticed here:
http://www.wiki-translation.com/tiki-view_forum_thread.php?forumId=2&comments_parentId=39

{img src=images/code.png}%%% {CODE()}
I'm trying to log in with my OpenID. I don't have a wiki-translation.com account yet.

After validating my OpenID, I'm taken to a Tiki page that prompts me to create a new account on wiki-translation.com to associate with my OpenID. I enter a username and password, but then get the following error:

Wrong registration code
{CODE}


__Duplicate of {wish id=2204}__

This is a workaround for the bug described below. We just had this same problem occur in Tiki Wiki 6.3. Our Architect looked at the code and said the search wasn't recognizing the pages' language. I turned off the multilingual feature that I just turned on last week (May 31, 2011), and our search function worked normally again.

This is a cut and paste of the following open bug I found that describes this problem:

Status open
Rating (1)
Ticket ID 2188
Subject Search function does not work when tiki-searchindex.php is first invoked
Submitted by Geoff Brickell
Priority 9 high
Category Bug: Error
Tiki Version 2.x
Feature Search
Description Using the Search link in the application menu invokes tiki-searchindex.php which does not return any results no matter what you search for.

Having had a 'failed' search you are however now at tiki-searchresults.php and all subsequent searches work fine.

When you use the Search box module you fill in the form and the form 'action' is to run tiki-searchresults.php - and so this works fine.

This was previously logged as id 1696 - but this flagged the problem as a usability problem with the tiki support site rather than a possible coding bug - so have submitted this again.


Lastmod by Geoff Brickell
Created Monday 01 December, 2008 04:40:25 CST
LastModif Monday 01 December, 2008 04:46:34 CST

I defined a structure Helpdesk FAQ and a categorie Helpdesk.
Now I give a group Helpdeskadmin the permission tiki_p_edit (and a lot of others).

If a helpdeskadmin trys to add a page with the button on the top of the wikipage with over the toc, the message "You do not have permission to edit this page." appears.

The problem seems to be the following permission test in tiki-editpage.php:

// Permissions
$tikilib->get_perm_object($page, 'wiki page', $info, true);
if ($tiki_p_edit !== 'y') {
[...]
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

If I give the permission tiki_p_edit to the group, the helpdeskadmin comes to the wysiwyg-edit-page, also he gets a message like the page must have a categorie. I didn't analyzed that yet.

I created a test newsletter on a new tiki 4.x (using recent svn, similar to tiki4rc1)

* Switched editor to wysiwyg
* copied some content from this page: http://en.wikipedia.org/wiki/Paul_R._Ehrlich (from the title "Paul R. Ehrlich" until the title "other activites" (so that, it's including also a few images available on the internet, in case it matters)
* cliked on the switch editor button (to go back to a normal editor showing wiki syntax)
* a blank page is produced, after 10-15 seconds.

Hello,

Remark : The editing current page seems to crash if to many changes by cut are made (my page lost).

Object :

Change of option "check orthography" lead to system error when you save the page :

__SYSTEM ERROR

La table 'teawik-ld8-50s-new1.babl_words_fr' n'existe pas
__
The query was :
select `word` from `babl_words_fr` where `word`=? or `word`=?

Valeurs :

1. Table
2. table

The built query was likely :
select `word` from `babl_words_fr` where `word`='Table' or `word`='table'

Stacktrace :
* tiki-editpage.php : 0 -> {main}(array ( ))
*tiki-editpage.php : 853 -> spellcheckreplace(array ( ))
*lib\tikilib.php : 1659 -> spellcheckword(array ( ))
* lib\tikilib.php : 1704 -> spellcheck_word(array ( ))
* lib\bablotron.php : 44 -> word_exists(array ( ))
*lib\bablotron.php : 104 -> query(array ( ))
* lib\core\lib\TikiDb\Bridge.php : 29 -> query(array ( ))
*lib\core\lib\TikiDb\Pdo.php : 119 -> handleQueryError(array ( ))
*lib\core\lib\TikiDb.php : 150 -> handle(array ( ))

So the alias is not 100% an alias.

On: ((doc:Semantic))

There is a link to:
* ((doc:Semantic Alias))

But this ((doc:Semantic Alias)) is an alias of ((doc:Alias))

Also in action here:
http://profiles.tikiwiki.org/handler

Related:
*{wish id=2754}
*{wish id=2729}

---
Activating plugins doesn't invalidate cache and thus, the plugin help doesn't appear on next page edit.

To reproduce:
1- edit a wiki page
2- click on the help button
3- scroll down to plugins
4- click on Activate/deactivate plugins which takes you to tiki-admin.php?page=textarea ~~#FF0000:(wrong tab!)~~
5- Click on plugins
6- Activate a plugin
7- Notice that on next edit, the new plugin is not available
7a) a bug in my text, edit Help was in French, so maybe the cache of another user was appearing

On ui.tikiwiki.org, I noticed some issues about the annotation plugin stuff not appearing properly when a page is cached.

I turned off cache for now

Tiki Articles do not support the FOOTNOTEAREA plugin. In Tiki 5 and 6 I used:
{CODE()}
foo bar {FOOTNOTE()}http://www.foo.bar{FOOTNOTE}
---
{FOOTNOTEAREA() /}
{CODE}

Tiki renders the footnote (superscript) properly, but does not include a Footnote area at the bottom of the article.

Tested & confirmed on info.tw.o using Tiki 5 and 6

With autolinks on, if I do:

~np~''Taken from http://climatechange.org''~/np~

the rest of the page becomes italic (the auto conversion of link breaks the closing italic tag.

Perhaps this should be user choice?

So user can avoid this step if there is a problem.

In view mode:

PluginCODE should have horizontal scroll bar when there is too much code on one line. This used to work a while ago on some browsers, but not all.


In edit mode:
CodeMirror seems to force the page to be super large

Setting feature_tell_a_friend=n doesn't affect the "Email This Post" functionality for the blog, so visitors is always offered to mail the link for a post. Imho the admin should be able to choose if this is allowed or not.

"Delete unused images" in the Admin panels does not affect images uploaded via the WYSIWYG editor, and the user interface does not provide any other means of deleting ANY images from the FCKeditor upload directory.

When you disable display of the Description field on the top bar of the Wiki Page, the option to edit the description is removed when editing the page.

I have a comment on a wiki page. When I click Reply to post a follow-up comment, I get an error. It looks like the Reply button is generating a bad URL:

__Not Found

The requested URL /mywiki/page=IVR_Revitalization&post_reply=1&comments_threshold=0&comments_reply_threadId=5&comments_offset=0&thread_sort_mode=commentDate_asc&comments_per_page=20&comments_grandParentId=0&comments_parentId=5&thread_style=commentStyle_plain was not found on this server.__

This would be a show stopper using Tiki threaded comments is very important feature requirement for us.

Thanks,

Paul

To reproduce:

#Go to a page which someone else is editing
#Click to edit a section (ex.: &hdr=9)
#You will get a message to confirm override (conflictoverride=y)

If you accept, you will be editing full page instead of section.

Hello,

~~#0c6:HELP, I spent 120 hours on the problem, and I am completely stopped in my Work because I can't install Tikiwiki on the development tool on windows. I could not find a way to understand why 4.1 installation seam's impossible on windows. A failure, that I could not find till know, on windows is not detected by the product.~~

Sorry for the length.

I try to install on windows to make test and developments an installation of tikiwiki 4.1 that is on a unix system (OVH provider with shared servers). So I can't have xdebug and many other facilities.
This local replication is needed to begin my participation to the dev.tikiwiki.org.

For this I have :
1- Changed the way to hold .htaccess (patch) For my apache I use the définition
AccessFileName access.htaccess
My various application are accessed via virtualhosts
this since six years.
2- Enable all needed extension for php : the lonely problem is that it not exists an adodb.dll for php 5.3.0 on windows (not found)

After I tried a manual installation :
- create mysql db with data 4.1
- create local.php

This crash on (see screen xdebug copy) the instruction in tikisession-pdo.php
TikiDb::get()->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);


But when I made the searches (this is the opportunity to go inside the product)
__I could not find the way how the instance of the class TikiDb inherit of the setAttribute method from probably Zend_Db_Statement_Pdo__
in lib\core\lib\Zend\Db\Statement\Pdo.php:411:

If the link exists I am interested in the fact to understand the structure.
If this come from the lack of the adodb.dll extension (functions and constants) this should be detected and I could not reach this execution point.

Generally may be a detection of php extension features could in the future avoid my "exploration".

I will redact when I will have solved all the problems a document about detail of a good implementation on windows.

Thank's for an answer, because I am locked till 15 days on this problem.

Trebly :

''__Nota1: __''I try new clean installation which don't functions, it crashes, after everything seems to be ended well installed the data are empty and a loop of to forms is without issue :
# because the data base is not populated
# because at the end we go back to the screen for validation of user and pass (second time) which calls the language form ad vitam.
The analyze shows that the POST('user') and POST('pass') are not got back into tiki-install.php and the failed installer is not run again.
Finally if I populate the data base with the data's (SQL) coming from one of the to implementations I reach the same as described upon.

''__Nota2:__'' The data's are well accessed by phpmyadmin and the parameters OK.
''
__Nota3:__'' I run Mysql with mysqli extension. 256Mo of memory for php
* Version du serveur: 5.1.37-community-log
* Version du protocole: 10
* Utilisateur: root@localhost
* Jeu de caractères pour MySQL: UTF-8 Unicode (utf8)
Serveur web
* Apache/2.2.13 (Win32) DAV/2 mod_ssl/2.2.13 OpenSSL/0.9.8k SVN/1.6.6 PHP/5.3.0
* Version du client MySQL: mysqlnd 5.0.5-dev - 081106 - $Revision: 1.3.2.27 $
* Extension PHP: mysqli
phpMyAdmin
* Version: 3.2.1

May be there are other reasons that I have not found after 100hours of work...

When writing a particular wiki page, and being set this page to be watched to a group (let say Registered users).

Then if the page has plugingroup to hide particular peaces of special text that is not intended to be known by certain users. Then every time this page changes, a notification email is sent to all Registered users (this is ok), but in the content of this email all the source code is revealed to EVERY user on the Registered group, regardless if they have the right to see Source of wikis.

Don´t know how this could survive the testing and dogfood of this community. May be there is another way to let the Registered group to be acknowledged of a change in a wiki, without compromising content. Please enlight me on how to do this much of the work done on our live tiki portal uses plugingroup to restrict snippets of text to certain groups and other snippets has to shown, in the same wiki.

There should be an option to configure a watch to be sent in a way that only alerts the user that a particular page has changed without showing all source, in respect to a particular right to see or no to see the source.

I have checked on the proper user rights and object perms to avoid them to receive this notifications in the proper way, but tiki doesn´t seem to take it.


Using Tiki 6.2

dev.tw.o: Sorting items from trackerlist plugin doesn't work for anons due to some conflict with the wiki cache. Example:

http://dev.tikiwiki.org/tiki-index.php?page=Profile+Manager&tr_sort_mode1=created_asc

http://dev.tikiwiki.org/tiki-index.php?page=Profile+Manager&tr_sort_mode1=created_desc

both pages show the same sorting on date (for instance) if the user is not logged, but the sorting works if you are logged.

Hello,

When you use an existing database (UTF8 coded but charset=latin1 and collate=latin1-swedish-ci) converted by tiki-install 5.0 :

1- the titles and contents are displayed : as pure utf8 is saying the French texts (tables defined charset=latin1) :

A- Titles of any item
"L'échec et ses conséquences" is displayed :
" L'échecs et ses conséquences"

B- Texts of dictionnary (language.php UTF8 encoded) as
"créé à partir d'une structure" (comment the update or creation origin of a document) is too displayed
"créé à partir d'une structure"

C- Contents of Wiki or articles : id

D- Menu options : are well displayed
The text comes from the same file language.php (fr)

E- Tiles of column of tables etc. : well displayed

F- Warning messages ?

Everything behaves like the titles and contents even defined as charset=latin1 are dsiplyed as UTF8 while the others are threated well.
Is it a relation with the fact that "modify" action never displays anything because of the query, I will try to understand.

Everything was displayed well in 4.x versions

trebly

~np~************~/np~ can be used a seperator in an email


Typcally, if there is a large number of stars (ex.: >10) and/or there is no text after, we shouldn't convert to bullets.

If a user Alain sets a watch on a page, and there is already a group watch on that page for a group to which he belongs, then Alain gets two notifications whenever the page is changed.

This was found on terminology.tikiwiki.org which runs 4.x

If you filter on a category field in trackers, you cannot edit any viewed tracker items. The system returns a SQL error because filterfield is set, and filtervalue is null. If you filter on other fields, you can save, with no errors.

I have traced the problem to the calling of trklib->list_items (this holds the query that fails). This function is used to call and order the other tracker items for easy pagination of the filtered tracker items after a save.

However, the real problem is that $_REQUST['filtervalue'] and $tryfiltervalue get lost in tiki-view_tracker_item.php when the save submit action is done on the form. Other URL query parameters appear to be stored as hidden fields on save action in tiki-view_tracker_item.

For whatever reason, non-array filtervalue fields (e.g. plain text fields) are remembered and thus the pagination and call to list_items works just fine.

However, when there is an array filtervalue (like there is with category fields), then filtervalue gets lost on the save action, and the save fails on a malformed query.

Cannot use wysiwyg editor in blog if we want also to use excerpt feature.

If any temporary or fixed solution can be found...

Many many thanks

New fade plugin is cool.
http://doc.tikiwiki.org/PluginFade

#If body is empty, plugin should not be clickable
#However, if there are line breaks in the body, the are no longer in the fade.
#Also, should have a setting, default to y for little icons:
{img src=images/code.png}%%% {CODE()}
[-] [+]
{CODE}

This is a huge problem

Not easy to solve. Would need ((WikiParser)) work?

This happens in Tiki4 when using session_storage in the database (which was not the default) when using PDO (which is now the default in Tiki4)

feature alias (semantic links) is not SEF (search engine friendly) ready

Using 4.2.
See it here:
page:
http://gavarrespedia.org/pendent

has a few aliases such as:
{CODE()}
(alias(pendents))
{CODE}

If you have SEF feature off (btw, and htaccess rewrite rules on), when you type:
http://gavarrespedia.org/pendents

you get
http://gavarrespedia.org/pendent

However, if you enable SEF feature (to make tiki create also short urls), then:
http://gavarrespedia.org/pendents

shows error, page not found, maybe you were looking for pendent, etc.
and it should just show the page "pendent" straight away

Hello,

On my system :

__feature_sefurl don't functions normally.__

Important : Subject feature_sefurl : last version 5.1rc1 (current yesterday but may be before). The feature_sefurl don't functions normally (I have not searched why, I don't look at in details to this part).

__So if the option is activated all url(s) as

__''site/<page name> ''__

fail and any action, particularly page-object-display (magnifier icon) reaches a 404 error. __

nota : naturally, if the option is not activated the url generated for display of pages is :
__
''site/tiki-index.php?page=<page name> ''__

which functions normally.

trebly

ref-B00805-01

Not totally sure if this is feature request, bug, or lack of knowledge. Basically I need some way of supporting maketoc with WYSIWYG pages.

{CODE(caption="tiki-login.php line ~308")}if ($prefs['limitedGoGroupHome'] == 'n' || $url == $prefs['site_tikiIndex'] || $url_path == $prefs['site_tikiIndex'] || basename($url_path) == $prefs['site_tikiIndex'] || ($anonymous_homepage != '' && ($url == $anonymous_homepage || $url_path == $anonymous_homepage || basename($url_path) == $anonymous_homepage)) || ($tikiIndex_full != '' && basename($url_path) == $tikiIndex_full)) {{CODE}

for $prefs['limitedGoGroupHome'] == 'y'
the sefurl will not match

In Tiki 3.x, it worked fine.

Upon upgrade, when there is an edit, some of the HTML is stripped.


{CODE()}
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_s-xclick">
<input type="hidden" name="hosted_button_id" value="10235687">
<input type="image" src="https://www.paypal.com/fr_XC/i/btn/btn_paynowCC_LG.gif" border="0" name="submit" alt="PayPal - la solution de paiement en ligne la plus simple et la plus sécurisée !">
<img alt="" border="0" src="https://www.paypal.com/fr_XC/i/scr/pixel.gif" width="1" height="1">
</form>
{CODE}

This is caused by HTML Purifier (in Admin > Security)

If you create a page or subpage for a structure with the bar above the displayed page you will asked for a language. after you select the language and enter the text into that page and submit it the page gets created but not put into the structure

as described in the topic

if you are trying to edit a page in a multilingual wiki where you have currently a language other than english selected (i only have german allowed in my tiki) you only see something like this (complete html output):
{CODE(wrap="1",ishtml="0")}<div class="floatright">
<a class="previewBtn" title="Vorschau Ihrer Änderungen." href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/magnifier.png" alt="Vorschau Ihrer Änderungen." width="16" height="16" style="border: none" class="icon" /></a></div>
<h1><a class="pagetitle" href="/test/tiki-editpage.php?page=test_de">bearbeiten: test_de</a>
</h1>

<!-- templates/tiki-preview.tpl start -->
<div class="wikipreview" style="display:none;" id="autosave_preview"><div>
<div style="float:right;">
<select name="diff_style" id="preview_diff_style">
<option value="" selected="selected">Vorschau</option>

<option value="htmldiff" >HTML diff</option>
<option value="sidediff" >Side-By-Side Vergleich</option>
</select>
<a title="Popup preview" onclick="ajax_preview( 'editwiki', autoSaveId );$('#autosave_preview').hide();return false;" href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/arrow_left.png" alt="Popup preview" width="16" height="16" style="border: none" class="icon" /></a> <a title="Close preview" onclick="$('#autosave_preview').hide();return false;" href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/close.png" alt="Close preview" width="16" height="16" style="border: none" class="icon" /></a> </div>
<h2>Vorschau : test_de</h2>
<div align="center" class="attention" style="font-weight:bold">Hinweis: Dies ist nur eine Vorschau und wurde noch nicht gespeichert!</div>
<div class="wikitext">

</div>
</div><span id="autosave_preview_grippy" class="ui-resizable-handle ui-resizable-s"> </span>
</div>
<hr style="clear:both; height:0px;"/>
<!-- templates/tiki-preview.tpl end -->

<form enctype="multipart/form-data" method="post" action="tiki-editpage.php?page=test_de" id='editpageform' name='editpageform'>

<input type="hidden" name="no_bl" value="y" />



<table class="formcolor" width="100%">
<tr>
<td colspan="2">

<input type="hidden" name="page" value="test_de" />




<div id='edit-zone'>
<div class='textarea-toolbar' id='editwiki_toolbar'>{CODE}

Please see:
http://demo.tikiwiki.org/mysql/Video_2009-08-29_IE6_png_fix_slow.wmv

So with #sitelogo a img, it takes about 2 minutes to load certain
pages, because it goes through each image.

Critical Usability Problem With WYSIWYG Editor

Version 4.3

"Insert an Image" does properly put an image in the Web page but the editor does not preserve the "Vspace" and "Hspace" attributes in the source code. It is not possible to do spacing around an image in a Wiki page.

The editor properly shows the spacing around the image after inserting from file gallery and before preview. Looking at the source inside the editor before a preview or save shows only this example:

"{img src=/tiki-download_file.php?fileId=1&display height=211 width=200 imalign=left}"

While the editor properly shows the spacing (inside the editor), the source code is not set to save the spacing.

It is not possible to manually enter the "Vspace" and "Hspace" into the source and save or preview successfully; the "Vspace" and "Hspace" are deleted.

It looks like the source code is simply using the original Tiki text approach. This would be a deal-breaker for my users.

Hello,

i've upgrade my site at 8 version.

now when i upload an image and i try to use with img placeholder appear the error "file is not an image"

i read that is couse by Ajax uploader, indeed i've activated this feature recently.
so i 've unactiveted this feature but the uploader is still in Ajax.

can anybody help me?

I TRIED TO SUBMIT THIS BUG BUT I CAN'T FIND IT AFTER SUBMIT. SO I AM TRYING TO RESUBMIT IT AGAIN. SORRY IF IT CAUSES A DUPLICATE.

I upload an image to the File Gallery, which gets assigned id=19.

Then I go to a page and insert the following Tiki markup:

~np~[tiki-download_file.php?fileId=19]~/np~

~np~{img fileId="19"}~/np~


To (a) provide a link to download the image, and (b) insert the image inside the page.

Works up to here.

But then, I do:
* File Galleries > List Galleries > Browse Images
* I locate the image I just uploaded, and click on the the wrench icon, and then on "Upload New Version".
* I upload a new version of the image
* If I go back to File Galleries > List Galleries > Browse Images, I see that indeed, the old image has disappeared, and it has been replaced by the new version

The problem however, is that the new image has id=20, not the old id=19. But the id has not been changed on the link and IMG plugin that I inserted on the page. So they still point to the old image with id=19.

The weird thing is that I can still download image id=19 (even after clearing my cache), eventhough I can't see that image in the gallery anymore. In other words, the image is still in the DB and can still be accessed.

This is definitely not how things should work. If I upload a new version of an image, then all references to that image should be updated accordingly, and I should not be able to access the old version, except in a "view history" kind of context. No?

The wiki "edit plugin" feature fails when the CODE plugin is used to quote a plugin that is used further down the page. "edit plugin" is not properly ignoring the contents of the CODE plugin.

For example, if I have the following in a wiki page:

{CODE()} {EQUATION()}A{EQUATION}{CODE}

{EQUATION()}B{EQUATION}

{EQUATION()}C{EQUATION}

If I click the "edit plugin" button to change {EQUATION()}B{EQUATION} -> {EQUATION()}D{EQUATION}, instead the edit is applied to the EQUATION plugin in the CODE block, resulting in:

{CODE()} {EQUATION()}D{EQUATION}{CODE}

{EQUATION()}B{EQUATION}

{EQUATION()}C{EQUATION}

The "edit plugin" function is apparently counting the number of EQUATION() plugins when it edits and is not properly skipping the ones embedded in the CODE plugin.
(This happens for any plugin, not just EQUATION)

__unified_incremental_update doesn't check for feature_search__

Unified Search with Lucene is awesome and is "the future of Tiki".

Now, on certain server configurations, it doesn't work well. An easy workaround is to simply revert to the legacy MySQL Full Text Search.

However, even when using MySQL Full Text Search, unified_incremental_update is defaulted to yes, and tried to update Lucene index, and generates an error message

Workaround is to deactivate unified_incremental_update, or even better, upgrade to 12.x and use Unified Index, with MySQL as storage.
---
Update: this issue has been reproduced in 12.x svn (and untested in 14.x so far, afaik) also with Mysql Full Text Search as unified search engine (on a multitiki install). See: [item5673] . {sign user="xavi" datetime="2015-05-19T09:10:57+00:00"}

How to reproduce:

Using WYSIWYG, edit a page which has a link to a wiki page which has an accented character and the link will change from accentué to accentu�


Workaround:

* Avoid non-English characters (éàç) in page names

!!!After upgrade the admin can't login anymore

!!!The failure sequence :
#Create a new directory or repository for the new version
#Update with your files (particularly images or icons)
#Site enable (example a sub-domain) on Apache
#Copy the database on new name
#Install manually .htaccess (compare and insert your valid options )
#Update "local.php"
#run <your new domain>/tiki-install.php. Goto the end (note an error occurs if your say at the end "run tiki" without locking or not because tiki-setup tries to re-open a session already automatically opened by installer). You just launch again (default tiki-index)
#~~#F00:__Try to login as admin : You will be rejected as wrong password __~~

!!Analysis - many possible reasons :
There are a lot of reasons to be in this situations. So to be successful a lot of conditions must be satisfied :

#If your new version uses the same current domain (after upgrade for my own I defines the same "servername" as current one and then keep the other when a particular name containng the version :
- The Cookies of session will try to reconnect an older version and a trace shows that the password is not the one you have given (generally empty). So the cookies of the site name must be cleared on your navigator

#The temp files or session table contain too wrong data : they must be cleared on server for your current copy (SVN update case)

#Your admin record in user_user record contains sessions data : they create a conflict which makes crash your login

#Be careful of the fact that you can have an open session in your navigator with the same site (sometimes we uses a lot of tab management which can create this : on firefox use showcase and search to clear your old sessions

#Generally avoid these problem is sufficient but at the end you will be prompt to update your password (as for the first login as admin with password admin). This can fail for the following reason : if the .htaccess is not set or modrewrite not well operational the <site name> will include the "port" used by your server. If your NAT translates the port address (i.e. 80-> 4397) you will get the following url <site>:4397/.... which fails

It is sure that if you use only one site close everything and upgrade you will get the minimum of problems but you will get someone anywhere.


!!~~#099:This situation is common and complex for whom have to manage product and data migration from one version (or several) of tiki to a new one.~~
It is not seen generally by developers, because it is not at all their common upgrade process nor test.

Wiki plugins, like ((doc:PluginBigBlueButton)), you can have the situation where the cached version of the page reports "Last time we checked, the room you requested did not exist.", but since, it has been created, and this prevent people from joining the conference.

So in the plugin code, you should be able to override the wiki page cache setting.

as the topic says

if you youse the redirect plugin in an article you cannot edit the article as it redirect the page even in edit mode

Android browser on Tiki8: It just says "Loading..." forever


[http://cksource.com/blog/CKEditor_3.6.2_released|Recent iPads and iPhones should be OK]

If browser is not supported, should Tiki revert to entering text (or manual HTML?)

If HTTPS login is disabled and "protect all sessions" is activated, no one can login anymore.

Others to watch:

* Users can choose to stay in SSL mode after an HTTPS login
* Users can switch between secured or standard mode at login

If you create a tracker with one field which is a text area set to WYSIWYG, plus another field which is an Item Link that has the "Add Items" options set, the WYSIWYG editor will not load using the TRACKER module. It must be a conflict in the two scripts. Disabling the "Add Items" option allows the WYSIWYG editor to load fine.

When Gzip output is enabled under Admin | Spped & Performance, it is not possible to send out newsletters greater than 100 in number, if at all. When attempting to send newsletters, it shows a 'Cannot load page' message in the frame where the log of email addresses normally appears.

Any other Plugin used within PluginTabs doesn't show the edit button. It is not possible to edit them itself like it was before.
For Example, Tab1 with CODE and Tab2 with FANCYTABLE:

{TABS(tabs="code|fancytable|box" toggle="y")}
{CODE()}{CODE}
/////
{FANCYTABLE()}{FANCYTABLE}
/////
{BOX()}{BOX}
/////{TABS}

several problems in Fancytable:
1. Field separator '|' (pipe) is not working with plugins. (must use '~|~' to get it work)
2. any plugin which is used in fancytable is looking fine when only one line is in. When you add a second line, you will get a lot of html viewed.

here is an example i used to figure out these problems:
{FANCYTABLE(head="code|box" colwidths="50%|50%")}{CODE(caption="code with 1 line" colors="sql")}select sysdate from dual;{CODE}~|~{BOX(title="box with 1 line")}1st line in a box{BOX}
{CODE(caption="code with 2 lines" colors="sql")}select sysdate from dual;
select sysdate from dual;{CODE}~|~{BOX(title="box with 2 lines")}1st line in a box
2nd line in a box{BOX}{FANCYTABLE}

Typing a page into Quick Edit, either in the Quick Edit module (I know it is depreciated but was testing this as well) or from the Create a Wiki Page tab on the List Wiki Pages seems to bypass category permissions and allows editing of pages which should be locked for the user. This happens if the page which is entered does not EXACTLY match the case of the existing page.
For example, in Global Permissions, Registered Users have Edit permissions; a category Alpha has Edit permissions assigned only to group Alpha, Registered Users have no edit permissions on this category. A page called Alpha exists in category Alpha. If a Registered User who is not part of group Alpha tries to create/edit page "Alpha", they receive the proper error about not having permissions to edit the page. Should that same user try to create/edit page "ALPHA", "alpha" or any variation which does not match exactly "Alpha", they will be allowed to edit the existing page "Alpha". This will also work if they enter the URL to edit the page directly with a different case (i.e. "tiki-editpage.php?page=Alpha" will prevent editing whereas "tiki-editpage.php?page=ALPHA" will allow editing).

Calling plugins in headings in pages where maketoc is used can cause breakage. For example, this happens when calling the ANAME or FOOTNOTE plugins.

! Effect on ANAME
Although Tiki generates anchors for all headings automatically, I find using ANAME is a great way of creating manageable and easily memorable Anchors for otherwise unwieldy headings
If a heading within a tiki page is coded as follows
{CODE(caption="1. Tiki Source Code snippet" wrap=1)}
!! Fourth and Even More Forgetful Heading{ANAME()}Quick4{ANAME}
{CODE}then Tiki generates the following HTML code
{CODE(caption="2. Generated HTML snippet" wrap=1)}
<h3 class="showhide_heading" id="Fourth_and_Even_More_Forgetful_Heading"> Fourth and Even More Forgetful Heading<a id="Quick4"></a></h3>
{CODE}which can be exploited by
{CODE(caption="3. Tiki Source Code snippet" wrap=1)}
{ALINK(aname=Quick4)}Link to Fourth Heading by its Quick4 Anchor{ALINK}
{CODE}All the above works flawlessly.

However, add MAKETOC to the page above the source line where ANAME is last used and it breaks the ANAME anchor(s). For this example, the maketoc is restricted to level 2 headings only as ~np~{maketoc levels="2"}~/np~ which makes the generated HTML a little more compact.
Tiki generates the following HTML in response to the inclusion of maketoc
{CODE(caption="Generated HTML for maketoc snippet 3" wrap=1)}
<ul><li><a href='#First_Level_Two_Heading' class='link'> First Level Two Heading</a>
</li><li><a href='#Second_Long_and_Equally_Unmemorable_Heading' class='link'> Second Long and Equally Unmemorable Heading</a>
</li><li><a href='#Third_Painfully_Difficult_Heading' class='link'> Third Painfully Difficult Heading</a>
</li><li><a href='#Fourth_and_Even_More_Forgetful_Heading' class='link'> Fourth and Even More Forgetful Heading<a id="Quick4"></a></a>
</li><li><a href='#Fifth_Long_and_Not_Very_Memorable_Heading' class='link'> Fifth Long and Not Very Memorable Heading</a>
</li></ul></li></ul><!--toc--></div><br />
{CODE}Note how the entry for the Fourth Paragraph has the anchor "Quick4" associated with it. The HTML code generated for the Fourth Paragraph heading remains identical.

The effect of this is that the tiki anchor Quick4 is now incorrectly linked to the TOC entry, being the first instance of HTML ANCHOR within the HTML file.

If the MAKETOC plugin is included below the ANAME, then the ANAME works as intended, since that is the first occurrence of the generated HTML ANCHOR statement.

I have a couple of test pages which illustrate this issue, if they are of any use in your testing.

! Effect on FOOTNOTE
Calling FOOTNOTE returns an HTML A element with an id, so using that same identifier twice causes invalid HTML. Additionally, since browsers favor the first element using the identifier in such cases, the TOC's instance wins if ~np~{maketoc}~/np~ precedes headings, which is not what we want.

! Cause
Plugin calls are executed in parse_first(). (Calls to plugins in "html" format are replaced by alphanumeric fingerprints.) After, parse_data_process_maketoc() is called and expands "~np~{maketoc}~/np~" to headings, so that each plugin call in a heading in the TOC has its result (or fingerprint) twice in the source. (After, replace_preparse() replaces fingerprints with the result of plugin functions (stored during parse_first's execution).)

This issue happens because maketoc therefore causes a plugin call's result to be repeated in the TOC (instead of possibly executed again specifically for TOC-s), which has 2 problems:
* plugins don't expect their output included twice in the page, so some (such as ANAME) may use HTML's id attribute in a manner incompatible with maketoc, causing invalid HTML
* plugins don't expect their output to be included in an HTML A element, so some (such as FOOTNOTE) for example generate links themselves, again causing invalid HTML

Using my version is 8.4 (MyISAM), installed via softaculous, when WYSIWYG is enabled the editor does not show up on the Admin>ContentTemplate page. I looked at the generated source code where the editor should appear and what it shows is this :
~lt~tr>
~lt~td/>

instead it should show:
~lt~tr>
~lt~td>
(code for WYSIWYG editor goes here)
~lt~/td>

Both features work fine independently, just not simultaneously.

! GROUP Plugin breaks CODE Plugin

Affects both v6.7 and this site. Worked OK on v4.3

{CODE(caption="1. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}

Now add a ~np~{GROUP(groups=>Registered)}~/np~ include the same code snippet and close out the ~np~{GROUP}~/np~. Start of CODE within GROUP

{GROUP(groups=>Registered)}
{CODE(caption="2. Code inside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}
{GROUP}

End of CODE within GROUP. On v6.7 the code box is displayed and the code snippet is truncated at the start of the Else statement fro a registered user. On this site, the code box is not displayed and the code is truncated at the same point for a registered user.

For an anonymous user, on both versions, there is no code box and the user see ~np~"other content{GROUP}{CODE} "~/np~

Repeating the code snippet again outside of the restricting Group statement works
{CODE(caption="3. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}.

The code example is lifted from [http://doc.tiki.org/PluginGroup] with a caption statement added.

Happy to help test any patch,

Martin.

To reproduce

# Install a fresh Tiki
# Create some usernames as usual
# Set "Use email as username" feature to yes
# Create more users (this time, username will be the email)
# Create a newsletter
# Subscribe the Registered group to the newsletter
# Send a newsletter

The system will crash and be unable to send the newsletter because some users don't have valid emails. If you error reporting is activated, you will get a message like this:

{CODE()}
System error.

The following error message was returned:

Duplicate entry '3-mcradmin-g' for key 'PRIMARY'
The query was:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES (?,?,?,?,?,?,?)
Values:

3
mcradmin
6b78cc21c16e768dd8fbb6b538c6bf78
y
1339700591
g
n
The built query was likely:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES ('3','mcradmin','6b78cc21c16e768dd8fbb6b538c6bf78','y','1339700591','g','n')
Things to check:

Is your database up and running?
Is your database corrupt? Please see how to repair your database
Are your database credentials accurate? (username, database name, etc in db/local.php)
Did you complete the Tiki Installer?
Please see the documentation for more information.
{CODE}

It is not possible to delete a calendar as long it contains a recurring event. The User does not get proper feedback as why he can not delete the calendar.

Conflict detection when page is saved would be nice too. Often happens when people are translating pages.


It should offer disambiguation page...

For example http://dev.tiki.org/Download gives an error but it does contain
{CODE()} (alias(Download)) {CODE}
As you can see here:
http://dev.tiki.org/tiki-pagehistory.php?page=Get+code&source=0

So the page is not found, but when you try to create, you get:
{img fileId="562"}

So clearly it exists...

Tiki version 9.1
Executing the search index maintenance (e.g. php lib/search/shell.php rebuild with cron) on the command line produces the following error if "Protect all sessions with HTTPS" is set on tiki-admin.php?page=security:

PHP Notice: Undefined index: HTTP_HOST in /path/to/install/tiki-setup_base.php on line 74
PHP Notice: Undefined index: REQUEST_URI in /path/to/install/tiki-setup_base.php on line 74

{CODE(caption="How Piwik handles http/https" colors="htmlmixed")}<!-- Piwik -->
<script type="text/javascript">
var pkBaseURL = (("https:" == document.location.protocol) ? "https://piwik.tiki.org/" : "http://piwik.tiki.org/");
document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
</script><script type="text/javascript">
try {
var piwikTracker = Piwik.getTracker(pkBaseURL + "piwik.php", 2);
piwikTracker.trackPageView();
piwikTracker.enableLinkTracking();
} catch( err ) {}
</script><noscript><p><img src="http://piwik.tiki.org/piwik.php?idsite=2" style="border:0" alt="" /></p></noscript>
<!-- End Piwik Tag -->
{CODE}


For all the included JavaScript in Tiki, it should switch to HTTPS version when available.

((doc:MathJax)) is an example of a different HTTP/HTTPS URL so ((doc:PluginJS)) should have a param for alternate location of HTTPS version. Tiki could try https by default...

Using wiki page cache, it happens that page cache is generated by a user who set his language to Italian. And then, the page is visited by someone who has language to something else, but sees Italian.


Workaround: turn off wiki page cache if you have a multilingual site

On doc.tiki.org/Installation, there is a link to doc.tiki.org/tiki-index.php/page=Installation

{img fileId=54}

And then, this page is broken, and it has many new links to index, most of which are invalid.

{img fileId=55}


Another example:
{img fileId=63}

I created a file gallery in my tiki installation and set all php *upload_size* etc. parameters in my .htaccess correctly. According to these parameters I can upload files up to a size of 8 MByte, which works without any problem, if I do this directly from the file gallery.

Now I try to use this file gal in a tracker via the tracker field "file". Everything seems to work well, uploads are shown with a progress indicator from 0 - 100%. But uploading quietly fails for files larger than 600 kByte.

The files are shown in the gallery, but on the server they have a size of 0 (zero) Bytes, files smaller than approx. 600 kByte work well.

To point it out, the problem is only existent from within a tracker using the new drag and drop (html5??) interface. With an older Internet Explorer, which does not show the progress indicator, uploading works well from within a tracker, too.

I cannot find a reason or a solution...thanks in advance...

Using a pretty tracker as registration form doesn't allow to de-activate the captcha.
Since one of the point of using a tracker for registration is to allow special questions which robots can't answer, what is the point of forcing the use of the captcha (through which robots can easily pass)?
Maybe a duplicate of bug #1818, I'm unsure.

SHOW admin password: 01234

Essentially as the title says, I am unable to use the {maketoc} tag to work correctly on a page in a structure using the WYSIWYG editor. If I switch to the wiki markup, it works, but then I lose my WYSIWYG formatting (eg for tables and the like).

I've tried {toc} but it won't show headings in the page.

If I try {maketoc} on a wiki created page, the headings will be created in the WYSIWYG editor.

r45953

SVN (11.0svn): May 15 2013 - REV 45953

In a multitiki install of mine, I tested an upgrade from tiki9 to tiki11, and then, switching tabs in admin panels, stopped working.

Once I disabled the js minification setting, tabs worked again.

Tried in demo.t.o/Tiki11, and it works well with or without js minification. So I was that's where the issue must come from.
---

the issue is still present in : Monday 10 June, 2013 23:33:08 CEST- REV 46275, and seems related to the Catalan interface.
Once the interface is set to Catalan, and page reloaded twice, js features stop working.

Reproduced also here in dev.t.o

To reproduce the issue:

1- Apply profile http://profiles.tikiwiki.org/Jailroot_Demonstration on trunk

2- Pick perspective "B"

3- Search for "contentA1". You find

A1 and B1 (OK)
A1 A2 A3 (Not OK)

tiki-listpages.php exhibits the proper behavior.

In a bilingual English/French site built on Tiki 5.x, i18n was used to create direct article-to-article links between translation versions of the same article.

When viewing a paginated article with an associated translation, selecting the "switch language" link properly loads the appropriate language version of the article ONLY from the first page of the article.

If an article is broken into multiple pages, attempting to switch language fails when "switch language" is selected while viewing a subpage of the article.

Looks to me as if the pagination (&page=x) variable has not been accounted for when dealing with translations of articles.

Please contact me at dkennedy@pondstone.ca if more information is needed.

Thank you!

When including a maketoc into a page, the titles in the page are still parsed for WikiWords and Hotwords. This breaks HTML, links, and may decrease the readability of page TOC-s.

Forbidden 303 error when trying to save a blog, caused by mod-security

My wiki (http://wiki.alphasoftware.com/, on version 4.2) intermittently fails to respond to mouse clicks for module box and menu expand/contract toggles, tab buttons for administration interfaces, the button to toggle between WYSIWYG and Normal editing, and other buttons that invoke JavaScript Ajax actions.

Changing random administrative settings or themes sometimes changes this behavior, but it still seems to come back.

I think it might be a bug, but I might also have some inconsistent settings.

I am willing to upgrade to the trunk build if these are bugs that have already been fixed.

I have set feature_comment_moderation=y, so new comments are invisible until approval, but they are shown as new comments on the since_last_visit_new module. So if user clicks on this link they come to the page where the comment was made (currently only tested with blog comment, but should be the same with other comments), and don't see this new comment.
I've no idea if this also affects coming version 4, only working with v3.2

If you change the language via the switch language module it also changes the language of a multilingual structure to the same language, even though the option 'Changing the page language also changes the site language' is NOT set.

If you want to translate the page into another language it would be helpful to have those two seperate and don't have to switch language for the menu, and then you have to switch the language of the structure again - thats one step too many if 'Changing the page language also changes the site language' is NOT set.

Issue was described here:
[http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=31233&topics_sort_mode=lastPost_desc&forumId=4]

When you insert text like:

"You should call ~np~-+intValue()+-~/np~ in ...." then that comes out as:
"You should callintValue() in ...." with "intValue()" monospaced. Note the missing space.

This is caused by the regular expression used to replace the Wiki Syntax with HTML.

The bug is in tikilib.php, line 6467.
It reads:

// Replace monospaced text
$line = preg_replace("/(^|\s)-\+(.*?)\+-/", "< code >$2< /code >", $line);

The first group captures the whitespace. But only the second capturing group is saved.

When adding a Multimedia field to a wiki page through the Plugin Tracker, the value attribute is unclosed, resulting in malformed HTML until the next quote.

E.g.:
Page is well formed with tracker added.
Click the Edit Plugin:Tracker link.
Add multimedia field to the Fields list.
Click submit.
The multimedia field drops to the end of the form (no matter where you placed it within the list of Fields).
The input tag is then:
{CODE(caption="Invalid value attribute",ishtml="0")}<input type="file" name="track[15]" value=" />{CODE}
Note the invalid value attribute; there's only one double quote.

When a structure is printed using multiple print, then the page aliases are ignored.
The TOC shows numbering and aliases correctly.
But the page within the print output shows numbering and page name instead of alias.

This is not only inconsistent, but a major problem:

All pages in TikiWiki must have a unique name. So, in case you need to create similar structures multiple times, you'd need to define some prefix for the page names to keep them unique.
This results in rather ugly page names.

Example:
A section "Client Overview" is mandatory in the structure.

The structure is created for some module "Module A" and some module "Module B".
You'd now prefix the pages, resulting in page names "ModA_client_overview" and "ModB_client_overview". That works okay, no problem, you can simple create aliases "Client Overview" for the pages.

The TOC then prints "1.1 Client Overview". That's correct.

But why does "1.1 ModA_client_overview" appear in the printout of the page instead?!

Say I am on dev.tw.o and I want to follow-up with a user, I end up on his tiki-user_information.php?userId=xxx __here__.

I should have a link to his page on the master.

Or else, users will end up with user-messages on various *.tikiwiki.org sites.

it seems there is a bug in 4.1 not allowing to assign perms per file in file galleries. i can only download the file as anonymous if i assign tiki_p_download_files to the whole file gallery where the file is saved in but not when the file is categorized in category with that permission assigned (which should work)

I installed Mysql 5 alpha to with 1.9 from the head of the branch and found this error when I tried to enter the tiki...

Warning: mysql error: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '-1' at line 1 in query:
select `permName`,`type`,`level`,`permDesc` from `users_permissions` order by `permName` desc
in C:\isense\icms\lib\tikidblib.php on line 133

Fatal error: Call to a member function on a non-object in C:\isense\icms\lib\tikidblib.php on line 151

We were trying to have the new antibot captcha working in a Tiki site based on Tiki trunk (during TikiFestBarcelona2 - mid July 2010), were a user tracker was set to collect more information from users at registration time.

when we enabled zend new antibot-captcha , no antibot code was shown at registration time, because there seems to be some conflict with the user tracker.
Once the user tracker was disabled, the antibot-captcha was shown properly, etc.

----
Update: disaled the new zend antibot catpcha, in order to use the former simple captchaimage, but that one is not working either, if user tracker is on.

If you have a clean tiki 6.1 install, the default preview is made with some kind of ajax include above the edit area.
but this preview has no linebreaks in it.
if you disable this and have the "standard" (like in tiki 3.x) preview you have linebreaks in the preview

In WYSIWYG, I introduce a table (4 rows, 2cols, 1st row is header). This is html. There is no Allow HTML checkbox in this editor, but the page is saved correctly with emphasis on the first row.
I edit the page with the normal editor. There is only one cell left in the first row (text of the two original cells concatenated). I cut the cell again in two with "|". Emphasis is lost. Now there is an Allow html checkbox, I check it and save.
Going back to the WYSIWYG editor, I restore the emphasis on the first row (again html seen in the source) and I save.
Back in normal editor, Allow HTML is lost again and the table gets the same defects.

When using OpenID + Registration CAPTCHA...
With Tiki 2.2...

I attempted to register using my OpenID:

#On the Login page, I entered my OpenID.
#My OpenID was validated and Tiki shows the page where I can either associate my OpenID with an existing Tiki account, or register as a new user.
#I completed the registration form (including the correct CAPTCHA), but Tiki keeps saying that the Anti-bot code was incorrect.

Additionally, the registration form presented with the OpenID __does not__:
*Display the password minimum requirements (such as number of characters).
*Allow for the selection of groups.


__Duplicate of {wish id=1505}__

As discovered here:


http://doc.tikiwiki.org/tiki-pagehistory.php?page=PluginInclude&diff_style=sidediff&compare=Compare&newver=0&oldver=26&tra_lang=ar

If I have a wiki page SomePage that has a link ((Page With Space)) in it, when I dump the wiki, the generated HTML in SomePage.html doesn't have a correct hyperlink in it to get to Page With Space.html.

The hyperlink contains plus signs instead of spaces (or %20) like Page+With+Space.html, but the target page on disk is called Page With Space.html. Clicking on the link in SomePage.html generates a file not found error.

The mouseover plugin works well on its own, similarly, the tabs plugin works well too. But when a TAB includes a MOUSEOVER, the offset of the mouseover box shifts to the end of the page.

I tried to correct this by setting the offsety to a negative value, but apparently, a negative value is not accepted by the mouseover offset command. In fact, even if it did, it wouldn't matter, because the offset shifts as the page gets longer.


For example, this syntax:
{TABS(tabs=Tab1|Tab2)}
*{MOUSEOVER(label="Some label 1")} asdasdasdasd {MOUSEOVER} blah blah blah.....
/////
*{MOUSEOVER(label="Some label 2")} qwertqewrtqwe {MOUSEOVER} blah blah blah.....
{TABS}

results in the mouseover box appear down under the page end.

You can see here: ((WantedPages))

Some wanted pages have links to the alias.

Hi

When Search engine friendly url feature is enabled. The registered users cannot delete their own post. Please note the registered user can delete the post when search engine friendly url is turned off.

The url on the browser appear as follow
[http://localhost/tikiwiki3/blog9&remove=25|http://localhost/tikiwiki3/blog9&remove=25]

When i print out the $_REQUEST array. The result was as follow

blogId is 9

There was no "remove" in $_REQUEST array.

Please suggest the workaround for this issue.

The IRC bot does not add a forumID, adds the parameter to the link though.
Just adding some ID you can read the post, and interestingly even reply.
The reply however will be in another forum.
You won't be able to acces the thread, as it will not display in the forum (as it was posted in another) but if you access it with the right/wrong forumID you will be able to see it.

tiki-view_forum_thread.php?forumId=2&comments_parentId=34103#threadId34105

As pointed out on IRC someone fixed needing a forumID in trunk.
No idea if that will fix this problem as well though.

If you rollback a page to a previous version, the links to that page are show with a question make instead of a proper link.

If you save a page in WYSIWYG, Edit Section buttons disappear. (However, if just before saving, you Switch Editor to wiki, the Edit Section buttons will (re-)appear (:wink:))

Note also separate bug #3764, i.e. the Switch Editor button does not appear if your edit is invoked by a Edit Section button. This makes the first bug very discouraging for new contributors.

This bug is a big issue for sites wishing to encourage collaborative editing, especially with longer pages:
*Having Edit Section buttons at each heading cries out 'Edit me! Edit me!'. If they disappear, it is much scarier for a beginner to edit a page.
*If someone bravely uses an Edit Section button only to find that it has disappeared as a result of their work, they may think they no longer have edit rights. They will think the site is stupid, and be greatly discouraged re further editing.

Regarding:
[http://doc.tiki.org/Clean+URLs]

The documentation linked above states (my emphasis added):

"Search engine friendly url Postfilter - ~~#090:__To generate SEFURLs for all Tiki links, also check the second checkbox__~~ which creates short URLs by filtering the output. The SEFURL Postfilter consumes more processor (CPU) time than the non-filter version (it deals with all the text and it deals also with cached text like modules while the 'on the fly' filter does not do it. ~~#00F:__In future versions the SEFURL Postfilter will not be used__~~ - it is only necessary until the template SEFURL work is finished. ~~#906:__Either one or both features (SEFURL and SEFURL Postfilter) may be used.__~~

I had both checked. This worked when I was on 4.x, and started failing when I moved to 5.0. This is why I marked it as a regression. The problem still exists in 5.3.

Each now works OK separately, but the they no longer work together. I've disabled the postfilter.

Is the postfilter no longer necessary, or am I no longer generating sefurls for all links? Priority of 3 based on the assumption that the postfilter is still necessary, otherwise I would have set it to 1.

When searching for terms which appear in areas for which a user has no permission, the search results show the full number of pages on which the term appears but the detailed results are limited to pages for which the user has permissions. This makes a certain amount of sense but may be confusing for users who are not aware that they are restricted from some content.
I'm not sure at this point whether this applies to only FT Search, Tiki search or both. (I've pretty much stopped using Tiki)

If you activate both the SEFURLs and the very useful "Show category objects", the urls generated by the category browser are not correct for trackers and file galleries.

In both cases it only gives the numeric identifier, without the "tracker" or "file" part.

Here is what it produces:
http://site-name.com/2

Here is what it should produce:
http://site-name.com/tracker2

Seen on tikiwiki.org

It gives error 404


Possible solutions:
*Users could be prevented to create pages with characters that conflict with
*Rewrite rules are not activated when page name contains such characters

Hello,

This is a new formulation of 3029 problem after near 200 hours of test and debug.

!The problem is now precise and near solution :
I can't affirm that I wrote debug because the execution stop on another problem.
The time spend is not only on TikiWiki, a had to solved installation problems and find a bug into easyphp and addresses resolution on the server.
The problem began with 4.1 and php 5.3.0 and I upgrade to 4.2 and 5.3.2 to be sure of the problem and the available solution.

!Span of the problem :
# Definition of main classes TikiDb and TikiDb_Pdo and PDO->function execution
# Progs : tiki-db-pdo.php, tikisession-pdo.php and naturally pdo.php, tikiDb.php
# PDO extension and behavior of objects and classes

!Description
note : Because I found the nature of the problem, I don't start from the nature of the crash but the analysis, but I produce a selected track made with xdebug var_dump)

# In tiki-db-pdo.php:40 we create the Pdo object
<$dbTiki = new PDO("$db_tiki:$db_hoststring;dbname=$dbs_tiki", $user_tiki, $pass_tiki); >

# just later In tiki-db-pdo.php:49 we set the singleton of TikiDb_Pdo into TikiDb abstract class with scope operator
<TikiDb::set( new TikiDb_Pdo( $dbTiki ) ); >

# further we call In tikisession-pdo.php:28 we can find the session read
< $sth = TikiDb::get()->prepare($qry); >
This instruction generates the fatal error :
__ Fatal error: Call to undefined method TikiDb_Pdo::prepare() in D:\Trebly\Teawik-ld8-422a\lib\tikisession-pdo.php on line 28__

!Explanation and solution implemented
The reason is simple and explained by the error comment :
we try to run the prepare function which is a PDO function on a TikiDb_Pdo object which has no reason to inherit of these Pdo function even <TikiDb::get()->db->prepare> could have a meaning.

Then the solution is in what is made in ZEND lib (not yet used), create an interface to PDO into Class TikiDb_Pdo.
This functions and it is written.

! A major question
One important question is why and how the same instructions seems to be available and functions well on Linux (I have a site which runs normally with 4.1, not yet upgraded to 4.2, a to-do)

I believe that the actual solution that I have developed for 4.2 on Windows with PDO (compiled) extension, should be extended to the normal version.

As I have said before I can't confirm completely that the solution is correctly tested and free of bug because, the program have a FATAL ERROR PDOException: SQLSTATE[HY093] later on the prefs restoration I create another report for this.

Note :
the execute statement written execute() without parameter generates each time a warning message when xdebug is activated with STRICT option (default in 5.3.2) for errors handling in php, and necessarily makes the code lightly slower. I developed an enhanced error template according to the error handler which displays much more informations about the context and, into these, the parameter (title) of execute statement. This make an enhancement to find much more quickly the errors.

{img src=images/code.png}%%% {CODE(caption=current strikethrough syntax)}
{TAG(tag=>strike)}texte{TAG}
{CODE}

Suggested one for us:
--strike--

As suggested in wikicreole:
http://www.wikicreole.org/wiki/Strike

All wiki engines:
http://www.wikimatrix.org/syntax.php?i=27

This is very useful when using wiki pages for ((project management))

When the system is set up to use staging & approval and the Structures are turned on, pages/topics created using the Add Page feature included with Structures get created with a staging name. The structure fails/disappears when the page is approved (fails in that the structure loses the staging name and does NOT substitute in the page without the staging name).

If you turn on SEF all your links will be converted to SEF-links so far with the exception of the links the bradcrumb bar of the structure.

Tested on tiki 3.5

When using "Theme control" together with a Category, the *.tpl files in templates/styles/{mytheme}/ are not considered for the pages attached to the category.

To see this, create a testcategory and a testpage. Then use "Theme control" and configure a theme having some *.tpl files in templates/styles/{mytheme}/ to be used for the testcategory.

Go to the testpage and it will show in the style. Now try to change one of the *.tpl files. The changes do not take effect.

Note that this is not about emptying the cache.

You can try and use mytheme as main theme and the one you used previously as main theme as "Theme controlled" one. You will now be able to edit the templates/sytles/{mystyle}/ files with the edits being picked up, but now changes to files in the former maintemplate cease to be considered.

Hello,

I have yet redacted quite the same text three month ago, about 4.1, 4.2... Because i could never start these versions, try to find bugs... submit but no answers.

My original text has been lost because of the bugs of the bugs reports management (author not stored - corrected, no capability to sort the items by date, no capability to sort anyway and search) nevertheless, too much to do elsewhere...

__Lest's go to the problem, which is a major one :__

!!The fact :
If any fields which is stored into sessions->data contains an " ' ", it is impossible to restart TIKI (always automatically and by evidence crashes if TIKI tries to restore these session.

!!The reason :
The text is stored with is " ' " and included "simply" into the query which resets the prefs.
By evidence this simple quote " ' " creates a query error and a crash of tiki (often APACHE).
this " ' " is interpreted as the end of the query, and the remaining a non-sense.

!!!Example :
With 5.0 if you are just installing with an upgrade of database, into the session query you will find the third data_text-block
$plugstring = <<<PLUGINTEXT
...
alt:
required: false
name: Alternate text
description: Alternate text that displays image doesn't load.
...

the " ' " of "doesn't" crashes the first run.

!!!The same happens when you have a header page with a title containing a simple quote " ' "

!!Solution :

!!!technical point of view
I have just found a lonely solution :

* the first, simple : any sessions->data content must be pre-translated with doubled simple quotes (which is the SQL syntax).
* any read of sessions->data doubled simple quotes must be set back to a unique one.

This possible solution offers too the capability to find fields with quotes by any query, if the data sent into queries are pre-translated (if not it is a crash).

A back translation after reading is not need only in some cases (the prefs restoration for example), for a search query the results will come back with their simple quotes...

!!!Who acts ?
It is very simple.
There are not many place where the problem occurs;
But I I have lost so much time because of the bug of 4.x and now 5.0RC and 5.0 Stable that I could not make the work I had programmed to do.
In my opinion it should be better that people who have written the SQL requests, make the change.

If they are not ready, I can submit patches (tikisession particularly)

Bye

trebly

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.

There should be a note, only visible to tiki_p_admin that the anti-bot code is not currently here because the GD lib is not there.

Just see ((All Patches)): content that is to be mouse-overed is breaking the page.

And on ((DogFood)), there is no mouse-over

Seen problem on ! and ^

Ex.:
http://dev.tikiwiki.org/tiki-index.php?page=WYSIWYG

{img src=show_image.php?id=10 }

{img fileId="396"}

Hotword processing needs to be turned off for the text expansion of the built-in macro __toc__: {CODE()}{toc}{CODE}

If a page name in a structure has spaces, and a defined __hotword__ appears as a name in the page, then the __toc__ expansion is corrupted by the __hotword__ processing. For example, if the page name in a structure is __xxx yyy zzz ddd__ and __zzz__ is a defined __hotword__, then the resulting link out of the __toc__ expansion is the equivalent of: {CODE()}((xxx yyy zzz ddd|xxx yyy)) ((zzz)) ddd{CODE}
Note how the trailing portion of the page name is not linked at all now.

This may apply to expanding the built-in macro __maketoc__, especially when aliases are shown, as well.

Verified on the opensourcecms.org installation as requested.

When typing an email address in a wiki page, Tiki can automatically protect the address.

For example: foo@bar.com

But, if you enclose the email address with punctuation, the anti-spam protection is lost.

For example: (foo@bar.com)

I defined a category Helpdesk and assigned it to a structure Helpdesk FAQ.
Also i defined a group Helpdeskadmin, which useres should be able to add new pages to the structure.
Now if a helpdeskadmin try to Add a page to the structure (with the button on the top of the wikipage with the toc), he must have global permission tiki_p_edit, not only for that categorie.



My analysis:

In tiki-editpage.php there are to permission tests:

First:

// Permissions
$tikilib->get_perm_object($page, 'wiki page', $info, true);
if ($tiki_p_edit !== 'y') {
[...]
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

Second:

//Is new page to be inserted into structure?
if (isset($_REQUEST["current_page_id"])) {
[...]
$structure_info = $structlib->s_get_structure_info($_REQUEST['current_page_id']);
if ( ($tiki_p_edit != 'y' && !$tikilib->user_has_perm_on_object($user,$structure_info["pageName"],'wiki page','tiki_p_edit')) || (($tiki_p_edit_structures != 'y' && !$tikilib->user_has_perm_on_object($user,$structure_info["pageName"],'wiki page','tiki_p_edit_structures')) ) ) {
$smarty->assign('errortype', 401);
$smarty->assign('msg', tra("You do not have permission to edit this page."));
$smarty->display("error.tpl");
die;
}

The first one is the problem becaus it asks only for globel permission, i think.

WYSIWYG editor is displaying theme background inside of edit box using darkshine. This results in the red and red stripe background behind your editing, but this background does not appear behind the wiki page when viewed (displayed on white, as is desired)

With Web Auth there are some issues with conflicting features and the User Administration Process.

1) FEATURE REQUEST: Should be able to point to the relevant file that contains the .htpasswd information. It would be outstanding if TikiWiki could parse/edit this file so it can also act as a front end for user password control and distribution. TWiki does this.

2) BUG/CONFLICT When adding users to TikIWiki, the username naturally has to match the username already set for the .htpasswd file. However, one is not allowed to set a 0-length password for that user. This appears to force the admin to enter _something_ but it also appears that this something has no effect<?>
The user who logs in to the htpasswd protected realm will naturally be logged into the TikiWiki account with the same name (as described) but the different password is irrelevant.

See screeshot

There's a problem with wiki_watch_minor. It conflicts with notification
wiki_page_changes_incl_minor ("Any wiki page is changed, even minor
changes"). If wiki_watch_minor is disabled, a wiki_page_changes_incl_minor watch will not be triggered by a minor change.

The difference between minor and non-minor edits is done in
notificationemaillib->sendWikiEmailNotification(). This is where the
preference could be taken into account.

This is a regression from r10949. It was discussed on http://article.gmane.org/gmane.comp.cms.tiki.cvs/57346

# enable Slideshows feature on Wiki Admin panel
# log out
# click on the Slides button under HomePage content; tiki-slideshow.php?page=HomePage&slide=1 displays fragments of plugins as ~np~{DIV}~/np~, ~np~{ELSE}~/np~ and ~np~{GROUP}~/np~ (in other words it doesn't parse the plugins properly)

It changes the syntax.

It would be time to rewrite the ((Wiki Parser))

See live example here:
http://moviments.net/cursos/IMDIG-I-Apunts

Wysiwyg editor is enabled, and those are the general wysiwyg settings on the site:
|| Wysiwyg Editor is optional: | X
... and is displayed by default: |
Reopen with the same editor: | X
Content is parsed like wiki page: | X
Content is partially parsed: | X ||

The wiki page http://moviments.net/cursos/IMDIG-I-Apunts was last edited using normal editor, keeping "allow html" checkbox as enabled on that page. When you write
{CODE()}
{maketoc}
{CODE}

The string ~np~{maketoc}~/np~ is displayed, but the table of contents fort that page.

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.