Category: 4.x

Tikiwiki is unable to properly parse the following syntax:

~np~((Somelink))-((Otherlink))~/np~

The expected output is two wikilinks separeted by the hyphen. Instead the output is (tested on svn branches 3.0 and 4.0):

((Somelink-Otherlink))

wiki shows no preview in translate edit mode while in normal wiki page edit it's working fine

version: 3.0beta4 SVN
theme: darkroom
browser: FF3

steps to reproduce:
# enable multilingual features
# select translate from dropdown where "English" is
# set the language and pagename for new page serving as translation
# in the editing mode click preview

It changes the syntax.

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

Please see ((WikiBlame)) and ((WikiTrust))

Currently there is no wikiplugin to place 1 or more blogposts on a wikipage (showing title and content of the blog).

The functionality should be similar to the wikiplugin_articles, so that the amount of posts and the blogId can be specified.

Using a wikiplugin instead of the module plugin or RSS gives the advantage that you can show entire blogposts and that you can include a permissions check, so that users that should not be able to see the post don't get it on the screen.

Wishing a plugin similar to wikiplugin_userlist, but able to print only members of a specific group.
For example it would be usefull to have a page where a user can find a list of current forum moderators (user which are in group ''ForumMod'') and similar cases.

When watching a wiki page, emails send on change contain iso-8859-1 charset in their header, while the body is utf-8 encoded.
The result is that special characters like umlauts are not being displayed properly (without manually setting the character encoding in the mail client).

Detailed error:
In lib/notification/notificationemail.php for function sendWikiEmailNotification(..) exists for sending those notifications. This function then calls tiki_send_admin_mail(..) in lib/mail/maillib.php which then starts a new instance of Zend_Mail. At this point, the Zend_Mail constructor would need to be given the charset or it uses iso-8859-1 as default.
Since the whole procedure of sending the notification seems to be ignoring the charset settings of the general tiki settings, the constructor would need to be given "utf-8".

I guess the error, though, is that character encoding is not set at all during the process. This might have to do with the fact, that wiki notifications are sent another way then i.e. structure notifications. Someone with a clue needs to look into this, though.

{syntax type="tiki" editor="plain"}
I the user mail for registration confirmation the german translation for "you or someone registered this email address at" is a uncompleted sentence.

Environment: Windows Server 2008 + IIS7

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

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

Notice the "\" after my website name.

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

When I login, the "\" reappears.

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

{syntax type="tiki" editor="plain"}
This seems solved in Tiki 5.

''type content'' : Problem, way to go around and may be a quick way to go to a solution

Hy,
4.0, 4.1

I test all functions including those that are not finalized.

The problems occurs with Firefox 3.5 not with IE8 (other ie not tested neither opera, google etc...)

In WISIWIG text editing WIKI obtained in circumstances that I can not confirm the background color of textarea is black when you scroll to the end of long text (the text is more long than the height of textarea).
The content text exist and you can see it if you select it and change the text background color.
The problem is the scroll with the background property color (in strasa css #F3FCFE color)

''Complements''
*Problems occurs in wysiwyg mode (not in view source mode)
*If you change the background color of the text you can see it
*The problem is directly linked to scroll, when you change the textarea size (for example go to "fullscreen" edit), the black background appears at the bottom just one line after beginning to scroll down



I hope to have provided informations to go straight to the bug.

Best regards

I have a strange problem on Tiki 2.0RC2:

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

On my Linux-Server works everything.

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

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

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

{syntax type="tiki" editor="plain"}
I applied the patch from bug report 2956. Only one of the zipfile content files is added.

Add ip to syslog and/or action log, so that when anons (at least) are allowed to add content and it's spam (robots seem to be able to post with our current antibot captcha), there is way to identify the ip of the spammer.

So far, antibot captcha is added (in trunk, at least) to:
* wiki edit
* wiki page comments
* forum posts
* tracker item comments
* freetags
* calendar items
* newsletter subscription

The action of adding content on those features should be logged in syslog and/or action log and IP recorded.

Support.mozilla.com solution

or

http://framework.zend.com/manual/en/zend.cache.html
http://framework.zend.com/manual/en/zend.cache.backends.html#zend.cache.backends.memcached

Please see: ((OpenMicroBlogging))

{syntax type="tiki" editor="plain"}
This is annoying because you have to go via the admin structure instead of the simple add interface.

I know that calendars can be watched by users through links like:

tiki-calendar.php?watch_event=calendar_changed&watch_action=add

But this link doesn't work like this other one:
http://info.tikiwiki.org/tiki-user_watches.php?event=article_submitted&add=Add

I mean, Anonymous users clicking on the first link (calendar watch event, as it is right now), would not be offered any message to login or register first.
With the second link (watch article), the user will be shown the login box to login first, before the action can be executed.

This is to make more easy for new users to know that they can subscribe by email to get info from calendars if they register to that tiki site.

{syntax type="tiki" editor="plain"}
Assign Permissions with Level Configuration,
thus drop-downs in the table
tiki-assignpermission.php?group=Admins&advanced_features=y
ordering by level does not order correctly.

I had tested this successfully in version 3.3, but now with the upgrade to version 4.0 it does not seem to work. Here are the steps to recreate the issue:

1. Set up a TikiWiki so that users need to be validated by an Admin prior to actually logging in.

2. Register as a new user and get the following message:

Your account request has been stored and will be activated by the admin as soon as possible.
You'll receive email notification once your account is activated.
Please do not attempt to login until you receive the email notification.

3. Log in as 'admin' and navigate to Users page of admin tools. Push the round green checkmark graphic which has a hover display that says "Validate user: junkman". It sends me to this URL:

http://www.mywebsite.info/tiki-login_validate.php?user=junkman&pass=n

On that page the site returns a simple dialog box that says "Invalid username or password". Who's username & password? The Admin's?

At this point it wants to redirect me to the home page and I cannot get these new users validated.

the "advanced" search function (which is the default search these days BTW) does not search through anything but Dutch Roman characters (eg the English American character set)

I have 4 pages with the Alón name on them as an example, searching for Alón or Alon shows no results, BTW the non advanced search works correctly

This is on Tiki 4.2

On a multilingual project this makes the search function totally redundant as far as I am concerned

I have the following problem:

we wanted to upgrade our old tiki 2.2 to the new tiki 4.0 but there are some problems.

after using tiki-install.php to upgrade the old tiki to the new one the image galleries doesn't work anymore, even though it is activiated in the features menu.

the problem is the following:
every time i want to go to tiki-galleries.php i get the following error:
----
The following error message was returned:

__The query was:__
__select `sortorder`,`sortdirection` from `tiki_galleries` where `galleryId`=?__

__Values:__

__1. 13__
__2. o__

__The built query was likely:__
__select `sortorder`,`sortdirection` from `tiki_galleries` where `galleryId`='13'__
----

the problem is as you see there is no error message only the query is displayed.

i tried to install a vanilla 4.0 and created two galleries where each of it has one image in it and it works fine

i compared the database tables tiki_images, tiki_images_data and tiki_galleries and they seem to have the same structure

i tried to copy the tables mentioned above from the upgraded tiki into a clean install and still get the error above

possible problem seems to be with the tiki_image table as it works fine without the images in the image tables - but the error appears only after i copy the image tables into the database

it would be nice if someone could help me / fix this problem as it would take some time to reupload all the images (then probably into the file galleries)

and besides that is there a tool that moves the images from the image gallery to the file gallery for future use?

edit: all the other php files work like tiki-list_gallery.php and tiki-browse_gallery.php

This is an alternative to full WYSIWYG.

Wiki parser does some things. To get Javascript WYSIWYG, you would have to rewrite and maintain in javascript.

It re-uses existing features and has less chance of What you Saw Was Not What You Got.

Clicking Preview is a great way to see what you will get. But it's slow and it makes you loose your cursor position.

How about having a button to open a second browser window which refresh every 5 seconds (configurable) the content of the wiki edit box?

Lots of people now have large screens so they could put this side-by-side (or however they want it)

With the option HTMLdiff, you could in quasi real time not just see what you will get, but also see the colored diff. (cool!) So before you save, you know what you are about to delete.

((WYSIWYG-ish wiki))

((doc:Alert)) brings some cool new stuff, but it just works for file galleries.

There should be one feature which works everywhere which permits to inform all kinds of people/websites/computers about something. (via email, IM, etc.