Category: 4.x

Importing tracker items through CSV only sets the created and lastModif value properly if the dates from the CSV file are in the numerical php date format.

When you import a csv file where the created and lastModif dates are written as proper dates, the imported tracker items have a created and lastModif date/timestamp of the date & time of the import action.

example csv :

"itemId","status","created","lastModif","VRID -- 265"
"849","o","07/12/2009 13:24","07/12/2009 13:24","4"

Whenever I export a csv file, it contains the dates as shown above, so you can't just export data and import data on the fly without modifying all the values...

c.f. [https://dev.tiki.org/item3500|bug 3500]

Apologies, I've some how managed to enter this twice.

Please see [http://dev.tiki.org/item4247]

{syntax type="tiki" editor="plain"}
Forum replies are difficult to read because there is no indentation when using theme TheNews on v6.7 (also affected version 4.3)

Using Firebug with Firefox v12.x established that the style value "padding-left" is set as follows ...
~pp~
#tiki-centre div 2px from thenews.css line 382 which reads #tiki-centre div { padding: 3px 2px; }
Over rides
.sub_comment 20px from layout.css line 1539 which reads .sub-comment { padding-left: 20px; }
~/pp~

We also notice that the vertical alignment could be improved upon.

Following patch has been applied via Admin -> Look & Feel - - Custom CSS and is being successfully used on our v6.7 system.

Regards,

Martin

Tiki perms are very fined-grained: great

But when you need to create a lot of items with individual perms, it can be time consuming and human-error prone.

So copying perms from another page (which we know is OK) will be very helpful.

It will also save tons of time since permissions are not inherited.


__Related__
{WISH(id="2133")}{WISH}
{WISH(id="1820")}{WISH}
{WISH(id="2586")}{WISH}

Unless I'm missing some new admin change, Japanese wikitext support in trunk is broken. At both a 3.1 site upgraded to trunk, and a fresh install of trunk, Japanese text shows as either garbarge characters or question marks. (I know it's a long way until Tiki 4, but trunk is supposed to stay close to releasable.)

{syntax type="tiki" editor="plain"}
When clicking on the Show Help button in tiki-article_types.tpl. The text appears then disappears right away. This makes the Help Button unusable. (Please keep in mind this bug is with the Show Help BUTTON not the help icon)

{syntax type="tiki" editor="plain"}
JavaScript pop-up calendars get hidden behind CSS "layers" in Trackers, especially when using the tabbed view. I've noticed this problem with more than one theme (Strasa and Tikipedia). It's a shame, since the popup calendar (or date picker) is such a useful tool, and works well in the 4.0 Add Calendar Item interface.

Workaround - Turn "tabs" off when inserting a new item, or else use the date selector control (not as nice) also provided with trackers.

The hidden date picker / popup calendar occurs in the latest versions of Explorer and Firefox, so it doesn't seem to be a browser problem, but rather a stylesheet problem (?).

~~#f00:__UPDATE - DEC 16, 2009__~~

This bug has been seen before...
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1585&show=view&trackerId=5

The "fix" can be made locally - see workaround below

Uploading jpeg images with Internet Explorer (6,7,8) provokes a tiny small white image when trying to display it with colorbox.

It seems to be the Internet Explorer Bug which marks JPEG-Images at download time with mime-type "image/pjpeg" instead of "image/jpeg".

{syntax type="tiki" editor="plain"}
I wonder how many times over the last years I've had to select my user profile to be public in my preferences at http://tikiwiki.org/tiki-user_preferences.php

I always change __User information:__ from private to "__public__".
But after some months (and tiki upgrades, maybe?), I find that that settings is at "__private__"

Thus, When I go to send a message to a user, I can't either send the message:

^You have to be able to receive messages in order to send them. Goto your user preferences and enable 'Allow messages from other users'^

Or I can't because that user has that setting as private (I realized that chibaguy now has that same setting, but I wonder whether he chose that or not, like me)
---

same on other settings that have changed without my content:
Messages per page: 2 (I had 10, at least)
Allow messages from other users: no (I had yes)
Note author when reading his mail: no (I had yes)

{syntax type="tiki" editor="plain"}
__Intro & Environment:__
*Italian language selected
*Tikiwiki 3.1

__Issue:__
Many words in our Tikiwiki appears with strange characters instead of accented characters or special ones.

__Analysis:__
I looked for the /lang/it/language.php and:
*I opened it with the __vim__ on my server
*I opened it with __Notepad++__ on my notebook using various codification (utf8, ansi, UTF8 without BOM, UCS2....)

The result was that the accented words or special char words are always not matching the right codification.

For example, I find
"blog_ranking_top_active_blogs" => "blogs_classifica_blogs_pi�_attivi",
instead of
"blog_ranking_top_active_blogs" => "blogs_classifica_blogs_più_attivi",

I tried also to download the 4.1 version, the zip version and also the tar.gz one.
The result was the same.

The last forum post module will not display any post unless you are logged in as admin.

Please see:
http://dev.tikiwiki.org/tiki-pagehistory.php?page=TikiTests&source=40

There is:
{CODE()}~~#FF0000:This is a great start! I think automated testing will be an important ingredient in the future, to keep TikiWiki stable.

That said, it seems to me that TikiTests still falls short of meeting many of my needs as a Test Driven Developer. I want to start ussing automated tests on Tiki ASAP, so let's figure out what's missing, and how to best support those needs.
~~{CODE}

This used to produce colored text. In a recent upgrade, it no longer does.

Is this a regression bug?
Or was this an accidental but never official feature?

Related:
{wish id=2496}

From tiki-devel. This is a blocker in my view.

{QUOTE(replyto=)}>> A user added a link to a comment, and now any page that tries to show the link (e.g. the wiki page or the comments admin page) gives me a sql error. My code is up to date to about a week ago ‑ has this been spotted and fixed? A quick search didn't turn anything up for me.
>>
>>
> No, I can reproduce this on current trunk. Here's the stack trace:
>
>> * /var/www/tiki/trunk/tiki‑index.php : 0 ‑> {main}(array ( ))
>> * /var/www/tiki/trunk/tiki‑index.php : 427 ‑> runSetups(array ( ))
>> * /var/www/tiki/trunk/lib/wiki/renderlib.php : 89 ‑> setupPage(array ( ))
>> * /var/www/tiki/trunk/lib/wiki/renderlib.php : 310 ‑> get_parse(array
>> ( 'page' => '\'HomePage\'', 'canBeRefreshed' => 'FALSE', ))
>> * /var/www/tiki/trunk/lib/wiki/wikilib.php : 375 ‑> parse_data(array (
>> 'data' => '\'{BACKLINKS()}{BACKLINKS}\\r\\n((nouvel escape
>> test))\\r\\n((Home
>> ))\\r\\n{YOUTUBE(movie="http://www.youtube.com/watch?v=_wesmkqvUPI")}{YOUTUBE}\\r\\n!!{img
>> src=pics/icons/star.png alt="Star"} Get started.\\r\\nTo begin
>> configuring your site:\\r\\n{FANCYLIST()}\\r\\n1) Log in as the
>> __admin__ with password __admin__.\\r\\n2) Change the admin
>> password.\\r\\n3) Enable specific Tiki features.\\r\\n4) Configure the
>> features.\\r\\n{FANCYLIST}\\r\\n\\r\\n!!{img src=pics/icons/help.png
>> alt="Help"} Need help?\\r...\'', 'options' => 'array (\'is_html\' =>
>> \'0\')', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 6370 ‑> cache_links(array (
>> 'links' => 'array (0 => \'http://info.tikiwiki.org/Learn+More\', 1 =>
>> \'http://info.tikiwiki.org/Help+Others\', 2 =>
>> \'http://doc.tikiwiki.org\', 3 => \'http://www.tikiwiki.org/forums\',
>> 4 => \'http://info.tikiwiki.org/Join+the+community\')', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 3505 ‑> cache_url(array (
>> 'url' => '\'http://info.tikiwiki.org/Learn+More\'', 'data' => '', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 3739 ‑> queryError(array (
>> 'query' => '\'insert into `tiki_link_cache`(`url`,`data`,`refresh`)
>> values(?,?,?)\'', 'error' => 'NULL', 'values' => 'array (0 =>
>> \'http://info.tikiwiki.org/Learn+More\', 1 =>
>> \'\\n\\n\\n\\t\\n\\n\\n\\t\\t\\n\\t\\t\\n\\t\\t\\n\\n\\t\\n\\n\\n\\t\\t\\n\\t\\t\\n\\t\\t
>>
>
> cache_url unconditionally calls queryError(). I don't know what
> queryError() is supposed to do (and certainly didn't hope to find this
> documented), but the following code from Bridge.php is odd:
>
> function query( $query = null, $values = null, $numrows = ‑1,
> $offset = ‑1, $reporterrors = true ) // {{{
> {
> return self::get()‑>query( $query, $values, $numrows, $offset,
> $reporterrors );
> } // }}}
>
> function queryError( $query, &$error, $values = null, $numrows = ‑1,
> $offset = ‑1 ) // {{{
> {
> return self::get()‑>query( $query, $error, $values, $numrows,
> $offset );
> } // }}}
>
> Calling self::get()‑>query() with in turn $values or $error as second
> argument is strange. I figure queryError is probably meant to call
> self::get()‑>queryError() instead.
>
> This code was introduced in r20205.
>
{QUOTE}

{syntax type="tiki" editor="plain"}

Try this path link:
http://tikiwiki.org/blogpost309
You'll get an error message and you’ll be asked to create the page ''blogpost309''.

[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=36394&comments_per_page=1&thread_style=commentStyle_threaded|Fixed]

People expect to find one here

{syntax type="tiki" editor="plain"}
tiki-listpages.php accessed via menu item Wiki -> List Pages shows a version column which is populated with valid version numbers.

The Plugin Listpages also shows a version column. However this is NOT populated.

I wanted to use __~np~ {LISTPAGES(sort=version_asc max=100)}{LISTPAGES} ~/np~__ in an attempt to find the first 100 version zero pages created within structures, which we extensively use in our one name genealogy study site. These would be pages which have yet to have content added by our community members and are in need of our attention.

Our own system is running Tiki v4.3 exhibits this defect. I've shown the defect to exist in v6 using the demo system at [http://php.opensourcecms.com/scripts/details.php?scriptid=63]. Sorry, don't have access to a v5 system.

Happy to help with any testing to resolve this issue,

Martin

{syntax type="tiki" editor="plain"}
I have installed tikiwiki 4.1 on hostgator. When I login from firefox it doesn't take me to the next page which contains admin menu and logout option even after successful login. If I login from IE, problem doesn't arise while loggin in but at logging out same problem arises i.e. it still shows admin menu.

{syntax type="tiki" editor="plain"}
When using the coelesce theme on v4.1 and using Firefox 3.5.7 on Ubuntu 9.10.

Screenshot -> http://i.imagehost.org/0558/RUR_screenshot.png (external link)

The problem did not occur using Chrome.

--

I also posted this in the forums..

After upgrading from 4 to 4.1
I now can't login to my tiki. Every time I try to login, I get the following error:
The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

Best regards

{syntax type="tiki" editor="plain"}
In barebones profile and in featured profiles, there is intro text about 1st login being necessary with u: admin p: admin (good)

However, this message stays and needs to be deleted by admin (bad)

Perhaps we should have a module with is only visible if admin password has not yet been set.

{syntax type="tiki" editor="plain"}
Comments to tracker items can be very a useful way to gather ideas, code snippets, links, etc. from the community regarding an a problem or an idea.

It would therefore seem to be natural to include tracker comments in search - otherwise there is a risk of losing valuable community contributions in a black hole of tracker comments.

Tracker comments should of course be included in "Entire Site", and maybe even have their own search category.

maketoc is often used in a div like this:

{CODE()}{DIV(float=>right,width="200px")}^{maketoc}^{DIV}{CODE}


How about making a param for this?
{CODE()}{maketoc float=left}{CODE}

A small collection of related issues with maketoc:

^{maketoc} -=Maketoc issues=-^
!!! ''TOC and heading type sizes''
* This is an issue that seems to crop up repeatedly on tw.o. Users would like to be able to easily control type size of both the TOC itself and headings created by maketoc. Type size for both seems to be theme-dependent now, with many themes using very large type size for headings, some with a type size for TOC entries that is too small for users with only slight vision loss. It would be a Good Thing if TOC and heading type sizes could easily be set globally, per object type, and by category, with switches available to vary those settings on a per page or object basis.
!!! TOC and heading character attributes
* It would help reduce inconsisistencies in TOC and heading character attributes (as in this tracker item) if the attributes could be set globally, per object type, and by category, with TOC switches available to vary those settings on a per page or object basis. However, the ability to manipulate emphasis within a single TOC/heading entry should be retained, so that for example, a single word could be italicized in a TOC/heading entry.
!!! Vertical linespacing between headings and text
* Under some themes, vertical linespacing between text and headings is too much for taste, or as in the theme affecting this tracker item, too small for taste. This is another setting that should be unleashed from the themes and made easily selectable by a Tiki admin through global, category, and object type settings, with switches for per page or object variation.
!!! ''Backlinks from headings.''
* Links from the TOC to headings are now 1-way. For larger pages, maketoc would be much more user friendly for those viewing pages if clicking on a heading would take you back to the TOC.
!!! Outline numbering.
* TOC formatting and heading formatting would be friendlier to the eye if both could be assigned numbering schemes such as 1., 1.1, 1.1.1, 1.2 or I., A., 1., a., II, etc. Settings might be implemented as described for ''TOC and heading formatting.'' If developed, this might be implemented for lists as well.
!!! Headings indentation.
* Many power users in the word processing and outliners worlds expect headings to inherit the indentations of the corresponding TOC entry. This would help break up the visual clutter that happens when many headings are close together vertically as a result of short text elements separating them, as in this tracker item (but it is far worse when there are subtopics and corresponding subheadings). Settings might be implemented as described for ''TOC and heading formatting.''
!!! Text indentation
* Many people used to word processors' outlining or stand-alone outliners expect text to be left-indented one tab more than its heading. Relevant settings might be implemented as described for ''TOC and heading formatting.''
!!! Associated features
* Display current settings in editor, change current settings from editor. Make changes to settings made from the editor apply only to the object being edited, so that users do not accidentally apply per object settings to other objects. Admins should have option to disable deviations from admin-set settings.
* maketoc is commonly used in conjunction with list features. Any changes to maketoc should not unintentionally impact the list feature and ''vice versa.''
* Need to ensure that all enhancements suggested render correctly when Tiki objects are exported as PDF.
!!! Future options
* Future options might be kept open by maintaining compatability between Tiki objects containing maketoc elements and various formats used by outliners such as OPML, XOXO, OML, or OpenDocument XML. (See corresponding Wikipedia articles.) E.g., it might be feasible at some point to directly export an outline file to Tiki where it is imported as a wiki or blog page and ''vice versa.''

Related: {wish id=1045}


dev.tw.o has too many items on the menu. Using ((doc:Module MenuPage)), so we would need CSS menu or Phplayersmenu.

But if so, we lose the version history, ease of contribution of a menu in wiki wage.

How about the best of both worlds?

Perhaps a menu using a special code around the hierarchy (with bullet points), it can be caught and used by css menu.