Category: 2.x

I have another problem on TikiWiki 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 without problems.

On the Win-Server don’t work "approve+staging".

If I wont approve changes it shows me this error:

An error occured in a database query!

Context:
File tiki-approve_staging_page.php
Url tiki-approve_staging_page.php?page=Baustelle_Test
Query:
update `tiki_pages` set `description`=? `data`=? `comment`=? `lastModif`=? `version`=? `user`=? `ip`=? `page_size`=? `is_html`=? `wysiwyg`=? `wiki_authors_style`=? `flag`=? `lockedby`=? where `pageName`=?
Values:
0
1 <p>Test</p>
2 [approved by ottonormal]
3 1217330865
4 6
5 ottonormal
6 10.40.153.101
7 225
8 1
9
10 NULL
11
12
13 Test
Message:

Built query was probably:
update `tiki_pages` set `description`='' `data`='<p>Test</p>' `comment`=' [approved by ottonormal]' `lastModif`='1217330865' `version`='6' `user`='ottonormal' `ip`='10.40.153.101' `page_size`='225' `is_html`='1' `wysiwyg`='' `wiki_authors_style`=NULL `flag`='' `lockedby`='' where `pageName`='Test'

moved to ((WikiFarm))

It seems that the print and multi-print options are global. I would like to better control which wiki pages can be printed. It would be nice to have a tiki_p_print permission that could be appplied to pages and/or categories and/or structures.

If tiki_p_print = y, then the PRINT button will appear on the wiki page (if the print and/or multiprint options are enabled). Additionally, the page would appear in the list of available pages when using the multiprint option.

Many banner advertisers use a javascript for banner adverting. Currently, there is no way to add a JS-based banner.

The __last_modif_pages__ module has a __minor__ parameter which is supposed to be able to permit/omit wiki pages that were last saved with the __Minor Edit__ option from appearing in the list of last changes.
*minor=y (default) -- Show Minor Edit pages in the list
*minor=n -- Do ''not'' show Minor Edit pages

However, this option does not appear to work (in 2.x).

There is nothing in the wiki page history or action log that identifies a wiki page as having been saved as a __Minor Edit__.

The main listing of Trackers does not have so much control over its presentation as other Features, (File, Image galleries etc) so if you have a lot of Trackers it can be awkward to quickly find the one you want. ie you cannot control the number of items shown per page without changing the General preferences setting, the default sort is fixed as "Created" and whilst you can do a one-time resort you cannot change the default, and you cannot change what columns are shown. Would be good to upgrade this as Trackers are becoming increasingly useful and more used.


No longer relevant - 15th June 2013

When a file is first uploaded the 'success' screen allows a very useful set of "Additional info" to be displayed - but there doesn't seem to be any way to reshow this info once the file has been uploaded.

Would be very useful to be able to always show this in the file Properties so that the inclusion/download info can be cut and pasted.


No longer relevant - 15th June 2013

When you load the administration page for the first time of a session, you cannot see all icons. It's like if the page was truncated.
So you need to load the administration page a second time in order to see all icons.

Hi,

It just occurred to me that when upgrading to 1.10, users will need a script or something to create tiki_p_edit_categories perms for each tiki_p_view_categories perm that category objects have in the db.

This is necessary to preserve backward compatible state when upgrading, because tiki_p_edit_categories does not exist in 1.9.

Anyone good enough in SQL to write this purely in SQL, or should this be part of the PHP in the upgrade/install script for 1.10?

{syntax type="tiki" editor="plain"}
When Tiki adds the antibot code to a form or table, there is no specific class assigned to the TD or TR. Sometime this results in odd UI (because sometimes the table is NORMAL, sometimes FORM, someimtes FORMCOLOR, etc.)

These 2 settings:
Use cache for external pages:
Use cache for external images:

Should be tester, better defined, and could go on the new text area admin panel

Hello,

I've spent about 60 hours setting up and configuring a v2.4 TikiWiki (see Techiewiki.ca). For an existing bug (no preview button shows for registered users), I would like to install a patch someone has provided - but do not know where to begin.

I read NewbieDevTips and was strongly suggested to ASK before wasting hours and messing up my installation.

Since I'm more interested in configuring the software than becoming a developer - is there an easy way to do this?

Much appreciated,
Derek

Move all admin settings which affect all text areas to this new panel.

ex.:
Tables syntax:

To let Editors administer part of the site without making them full Admins (tiki_p_admin)

Sometimes, I want to restrict who uses Tiki's internal search engine. Maybe I have some non-linked pages, that people can discover via the search engine.

In 1.10, the page position is shown on the structure nav for page. It works perfectly for new pages, because of the fix applied in http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=889

However, structure pages created in 1.9 may have pos in db that remains non-contiguous. It will be better to have a way to clean this up.

Topic says it:

- newly created user
- send message -> doesn't work, error message
- go to MyPreferences
- don't change anything
- just hit "Change Preferences"
- go send a message -> works

I don't know how anyone can use the Beta version - the links in ALL Wiki pages are wrong.

The correct link to a Wiki page "Cars" should be ..../tiki-index.php?Page=Cars

Instead ALL Wiki pages are wrong with the link ..../cars

Obviously no one is using Beta or this would have been fixed in 1 minute

When you first define a Newsletter if you set the "Validate email addresses" parameter this, first of all, works fine and in the Subscription screen the "Don't send confirmation mail" is shown and a validation e-mail is sent when a new user is added.

BUT if you go back and Edit the Newsletter - first of all the "Validate email addresses" is NOT ticked when the existing Newsletter details are populated - but reticking it and reSaving the Newsletter does not set the parameter. Looking at the raw database shows that whilst the validateAddr field is set to "y" when the Newsletter is first set up - it is set to NULL once the Newsletter is edited and no matter how many times the Newsletter is edited and resaved the field stays at a NULL value - and obviously the validation process for new users is no longer available.

Editing the raw database with phpMyAdmin is the only way to reset the field to "y"

since_last_visit_new is an amazing module

Now, it would be nice to be sent a weekly summary (and URLS) of everything that has changed on the site, since my last login.

This is similar to the idea of RSS to newsletter that phplist offers. However, in our case, it would respect the permissions (WYSIWYCA)

Ideally, it would only be sent if you don't login after x days or weeks.

Feature request inspired by Yannick Boily

Imagine a simple group setup in which we have an Employee group and a Manager group. Every manager is an employee and so has all of the permissions of an employee, so we make the Manager group inherit from the Employee group. We put the basic permissions on Employee, and the special permissions of managers on the Manager group. Good so far. Now we'd like to have a newsletter BossNews for managers, so naturally we subscribe the Manager group to the BossNews newsletter. But by the current group subscription rule, this automatically sends BossNews to the Employee group as well. Presumably not what we want, as the BossNews is intended to have the inside scoop that only Managers should see.

Since the inheritor group generally corresponds to a ''subset'' of the inherited group, it is very unlikely that the current rule will be useful -- subscribing the subset to the newsletter should not automatically pull in the larger set.

Even reversing the newsletter subscription inheritance -- so that subscribing Employee to a group automatically subscribes Manager -- may be problematic. The subgroup may not want to see the "chatter" of the larger group. Think BoardOfDirectors as a subgroup of Managers -- they probably do not want to see all of the Employee updates.

So I would recommend no inheritance at all for group subscriptions to newsletters, since you can always subscribe both Employee and Manager to a newsletter if that's who should receive the messages.

When creating a newsletter item, both HTML and plain text versions are requested. The plain text information is empty if the newsletter is edited.

When an HTML Newsletter is created and 'Previewed', what is shown uses the linked CSS styles for the site's theme that are available to the browser - but these will not be available when the Newsletter is received as an e-mail and viewed in an e-mail client like Outlook. Generally speaking e-mail clients need to have in-line styling/'old fashioned' HTML tags.

It would be more sensible if (somehow?) the Preview function in Newsletters only used the formats/styling that was in-line/directly embedded in the content since this would generally provide a more realistic idea of how the Newsletter would look when it arrived as an e-mail - although depending upon the e-mail client even embedded styling may sometimes be stripped out.

So perhaps, at least, the Preview screen should warn users of this problem??

FIXED with newsletter.css custom css now in use

Sometimes, it is useful to attach files to a newsletter.

Alternatively, it could be a newsletter with a link to a file (a unique, very long URL, which provides access to the file without entering a password)

This is best explained with an example:

~pp~
Paragraphs are parsed

just fine here

{TAG(tag=ul)}foo{TAG}

but now

paragraphs and

line breaks aren't working!
~/pp~

This only happens for tag=ul, not even for tag=ol.

This happens regardless whether wiki paragraph formatting is enabled and regardless of whatever is inside the ~np~{TAG(tag=ul)}~/np~, even ~np~{TAG(tag=li)}~/np~'s.