Category: 8.x

{syntax type="tiki" editor="plain"}
After clicking "create new wiki page", i typed a name for this site containing a forbidden char (in this case "&"). I prompted this entry (not knowing this char is forbidden) to add content to this page.

the "invalid character" field popped up and forced me to rename the page. looked similar to the normal "rename page" input, but without a button to "save" the change.

unfortunately, the save button was also missing in the editor field for my new page and "previewing" the new site didn't change anything in this behaviour.

so in the end - content as well as the page were lost.

please add "save" buttons to this areas.

I'm am experiencing a severe problem about my files upload path: I once must have set the path to the absolute path "/files/uploads". When I now try to
* change the path to a relative path like "files/uploads" or "./files/uploads"
* change the path to the correct abs path like "/var/htdocs/wiki/files/uploads"
* change the file storage to database

nothing else happens. It keeps trying (and failing) to upload to the path "/files/uploads". The only workaround currently was to create the path "/files/uploads" so that tiki can upload files into that directory (what really strikes me, I don't want a /files directory in my root). But even after this workaround I cannot change my path or change to database storage.

Please help. Thanks.

Blog posts marked as private are published to other sites as RSS feed from Tiki. The post content as well as the title is published.

Hi,

i am pretty new to tikiwiki (please point my to any guides if i am missing something here) and currently testing the 8.3 release.
As i do have several mediawiki installations it is a must for me to be able to import data from mediawiki to tiki.

I did export an .xml file via dumpBackup.php from one of my mediawikis which resulted in a 85mb file - which opens without errors in a random selected webbrowser.

As a next step i tried to use the Tiki Importer.
- Choosed source type (mediawiki) & pressed ok & got forwarded to next page
- used the default selections (uncheck, uncheck, 1, option 3) & selected the xml local file -> pressed the 'import' button
- warning id displayed that a script will be started and may take some time & that i should have a backup -> i do select 'OK' here

-> 3 sec later i am back at the start page of the tiki importer.


Problem:
- no error is displayed
- no import is done


question:
- is that function supposed to work?
- could it be related to the size of the xml file? even then i would consider an error.
- can i offer any additional informations?


best regards in advance
fidel


EDIT:
#####
seems to be related with the size of the .xml file.

case 1: small file - around 1 MB -> worked (i do see a progress window)
case 2: big file - around 85 MB -> failed - see above for a detailed description)

Main problem i do see here is that in case 2 the user/admin gets no feedback at all.

When attempting to send messages to other tiki users whilst working in french locale, the messu-compose.tpl script hangs.

The problem is due to the different interpretation of commas and semicolons on french and english locales. The call to the quickhint (popup help) feature hardcodes the commas and semicolons, and this frustrates the french locale.

When using the UserList plugin, the links on the user names leading to their personal information pages, are shown and hidden depending on privileges of the logged in user. Unfortunately, the logic is reverse of what it should be.

Correct logic is: show links for all users that when either A.) You have admin privileges. B.) User listed is yourself. C.) User listed has chosen to make his profile information public.

Current logic is: show links when A.) You have admin privileges. B.) User listed is NOT yourself, AND user listed has chosen NOT to make his information public.

I am referencing forum post: https://tiki.org/tiki-view_forum_thread.php?comments_parentId=43682&topics_offset=1

I would like the ability for users in child domains to access the TikiWiki site the same way users in the parent site are able to access it. According to the forum post, "Tiki is not currently capable of authenticating against multiple domains (or multiple LDAP servers)" and "The code could be modified to search, say, the global catalog for the user's DN and then authenticate against the corresponding domain, but this would be custom coding"

I would like an option to specify multiple domains, or a custom code I could use to search the global catalog for the user's DN.

Basically I want all of my users in all of my offices to access the Tiki site. Not just the home office users.

{syntax type="tiki" editor="plain"}
This is a minor issue, and not sure if it something for tiki or google to fix. However I try to push Chrome as the default browser in my school because we use Google apps and it works better for that.
I don’t want to have to tell my users they need to switch browsers to insert an image. This will not get tiki accepted very fast.

I have tested this on a fresh install of 8.3, svn pre8.4, and svn pre9.0

I am on a windows 7 system with Chrome 18, Firefox 11 and IE9.
In wiki syntax mode the file galary image selector works fine.

In WYSIWYG mode the image slector works fine in Firefox and IE, in Chrome I have a new window that tries to open. The window is listed in the task bar but I cannot access it.

I have turned off pop up blockers and disabled all extensions while testing with the same result.

I have also tried from different computers.

Problem:
Some changes in Tiki code (especially the parser) between versions cause slight changes of behavior. Devs have no comprehensive way to test the result of a change on a large data set.

We have a large data set with all *.tiki.org sites.

Similar to ((tw:Pre-Dogfood servers)), we could have a script which checks the HTML output for all wiki pages for a given version, and compare this to another version.

And thus, we can check if this is a desired behavior.

The HTML entities change in Tiki9 would be a great 1st test of this. It would have been nice to have it for UTF-8 changes in Tiki5 as well...

This should be done as part of the script for ((tw:Pre-Dogfood servers)) so we have daily reports on issues. (and we know that it's the same data)

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.

Maketoc fails to parse headers which contains other tags.
See [http://dev.tiki.org/WYSIWYG+testing] for an example.

(This page also shows that the maketoc plugin has other issues, since the title is corrupted and no numbering is displayed.

Strangely enough maketoc seems to work well on my other Tiki8 sites. So, maybe this is a regression.

{syntax type="tiki" editor="plain"}
When 0 is put in the Parent Category option of the Category field, no category selection is offered in the item creation form.
Even for admin.

This makes it impossible to offer a way of selecting first-level categories in tracker items.

So, tracker items can not be categorised in the first-level categories that way.

I suppose the workaround would be to create a useless category and put all the others as children. Nobody will figure that out and it is uselessly complicated

Go to tiki-list_trackers.php → Edit one Tracker → Categories tab → Only first-level categories can be selected.

With this bug and bug 4208, it seems totally impossible to design elaborate category-based permissions with trackers.

Plugin Lastmod does not default to current page when page name is not specified.

The documentation for the [http://doc.tiki.org/PluginLastmod|Lastmod Plugin] says if you don't specify the page name, Lastmod defaults to the current page.

From forum [https://tiki.org/tiki-view_forum_thread.php?comments_parentId=40353&post_reply=1&comments_threshold=0&comments_reply_threadId=43856&comments_offset=0&thread_sort_mode=commentDate_asc&comments_per_page=20&comments_grandParentId=40353&thread_style=commentStyle_threaded#form|thread] posted by user TomJarvis:

I have now tested:
{LASTMOD()/}
and
{LASTMOD(page=HomePage)/}
in the HomePage of Tiki versions 2 through 9.

In each version of Tiki, the plugin with the pagename specified worked correctly (other than the '%0' in Tiki 2 mentioned in the documentation).

When Lastmod is coded without specifying the page name, the current date and time are returned in Tiki versions 2 through 6, and nothing at all is returned in Tiki versions 7 through 9.

There appears to be a problem with how the Lastmod plugin get the page name when it is not specified.

This is a bug that could be reported. The workaround is to specify the page name.

Have just upgraded from 4.3 to 6.7 and find Plugin Showpages is no longer producing output.

Looked at [http://doc.tiki.org/PluginShowpages] for inspiration and notice that the examples there do not seem to be functioning.

Suspect plugin Listpages now has --equivalent-- similar functionality. --but we have at least one other broken plugin (WantedPages), so want to ask if there is a wider issue here, please?--

Was using ~np~{SHOWPAGES(find=>FAQ_ display=>desc) /}~/np~ but I don't see how to simply display the page description with ListPages.

--Also is there an easy way to find all the pages within our wiki where ShowPages has been used so I can change them to Listpages??--

Thanks,

Martin

Updated 08May12. The issue with WantedPages is now felt to be a separate issue and I'll open a new ticket for that.

Have also now found new to v6 Mass Search & Replace tool within Wiki Admin which is great.

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}

{syntax type="tiki" editor="plain"}
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}

When you place more then 167 nested plugins of for example DIV (so not nested in nested in nested..., just plugins with only one nested plugin each). It will eventually not parse the plugin anymore.

Wikicode:
{CODE()}.
.
.
{DIV(id="test1")}test1{DIV(id="test2")}test2{DIV}{DIV}
{DIV(id="test1")}test1{DIV(id="test2")}test2{DIV}{DIV}
{DIV(id="test1")}test1{DIV(id="test2")}test2{DIV}{DIV}
.
.
.
{CODE}

The result will be:

{CODE()}test1
test2
.
.
.
test1
test2
test1{DIV(id="test2")}test2{DIV}
.
.
.
test1{DIV(id="test2")}test2{DIV}{CODE}

This is due to a counter (passes) within the PluginMatcher.php which is limited to 500. But I'm guessing this counter is meant to avoid 500 nested in nested in nested in nested...etc (which indeed make sense to me), but not that this keeps counting when you start a new plugin.

I think there should be some attention to the levels. It seems that level zero is the whole text and that level one is simply the detection of the plugin, level two is the detection of a nested plugin, level 3 is the detection of a nested in nested plugin etc.

I haven't figured it out completely, but I have found a workaround to make the counter count as espected. But this is again a workaround and a real solution is needed.

Edit: More info...it "goes wrong" when the performReplace function is called, which itself calls the getSubMatcher function again, which increases the level (for which I believe should not happen the first time it is called). Whithin the findMatches (which also calls the getSubMatcher) there is a test whether the $this->level is empty and if so, the passes-counter is restored to zero. This test is missing within performReplace, but should maybe also be added? The problem is then that the passes-counter should be also known by the other functions. Shouldn't be difficult to do.

When nested divs (or other nested plugins of equal name) need to be edited, the edit-plugin-window, does not detect the plugins beginning and ending correctly. Eg:
{CODE()}1. {DIV()}
2. {DIV()}want to edit the nested plugin{DIV}
3. {DIV}{CODE}

If your mouse is within the "want to edit the nested plugin" text and you select the plugin-type because you want to edit using the gui (usefull if the text is quite long), it will pop-up the gui with the text:

~np~{DIV()}want to edit the nested plugin~/np~

Thus it detected the ending of the plugin which started at line 1, to end in line 2, which is not correct. Also, when the mouse is within a nested plugin, the gui should detect the beginning of the plugin in line 2, instead of line 1.

Hope this make sense...quite an annoying behaviour.

It would be nice if it was possible to enable something like a syntax highlighting/coloring when in edit mode, such that plugins are easily detected or that layout is also colored. Wouldn't a tikiwiki syntax highligher be cool! Or is that already available? :)

When trying to save an edit on wiki pages or articles I get a blank screen.

Turning on debug I get the following error reported:

Fatal error: require_once() [function.require]: Failed opening required 'Zend/Search/Lucene/Storage/File/Filesystem.php' (include_path='/home/craigcam/public_html/lib/pear:.:/usr/local/php52/pear:/home/craigcam/public_html/lib/core:/home/craigcam/public_html/') in /home/craigcam/public_html/lib/core/Zend/Search/Lucene/Storage/Directory/Filesystem.php on line 183

I would be grateful for some help with this issue as it is holding back my implementation.

Regards and thanks in advance,

Craig

Tiki v8.3

When attempting to sort the Tiki logs by either Id or Message, the lines do not sort as expected. The actual order appears to be random, regardless of the requested sort direction (ASC or DESC.)

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).

{syntax type="tiki" editor="plain"}
Main bug.

A new user can't at all connect and get a blank screen.
This without crash.

If the user have an analyser he will find that tiki has sent this code

{CODE(caption="The page sent content")}<html><header</header><body></body></html>{CODE}

At the end of the installer when launch is run we can get a crash with an exception :

__"Session already opened"__

This has been reported since two years may be six times.

I have not made various test, so may be it depends of the context which is :

#Data upgraded from existing connection
#Run without inhibiting installer

This should not have effect. So I don't understand why others don't seem to observe the problem that I had always.

I need to run again directly index.