Category: 2.x

Hi!

First: Thanks for this great project!

When you try to translate an article (by clicking on the small globe that is near the edit icon), it sends you to the wiki translation page, and content is empty, ie, it doesn't get the article's content to translate, and off course, even if it did so, the interface is not correct for article translation (it should have the same article interface, with heading and stuff).

I hasn't tried latest trunk, but bug is present on 5.1.

I tried to search for a similar bug already open (because of this forum thread: http://tikiwiki.org/tiki-view_forum_thread.php?forumId=13&comments_parentId=33126), but I found none, thus: I'm opening this open.

Thanks!

Quite strange, and maybe I missed somthing.

1-Create a new Article, and Topic,
2-Assign image to topic through Admin Topic
3-Select Topic..

All is ok, but it would be better to be able to scale the image, either at the Topic admin, or accept the Topic Own image scale factors.

Error part.
1-Select own image, Image uploaded.
2-Display ok.
3-Upload another Own image to replace the previous one.
4-Image name changes to the name of the new image, but the Image does not change.

The only way I can change the image is to select the Topic, but uploading a new image does not change the Own Image, what ever I do.

-I tried, Clearing all the Cache.
-Clearing and resetting local browser cache, This is not the problem, as I use Firefox and IE, and I edit with Fire fox, and then open IE to see if the image had changed, Plus I didn't run IE to see the previous image.

Work around is - I can delete the Article and create a new article of the same name, with the new image
But it would be nice if it worked as expected.

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

this is a problem concerning tikiwiki 2.4.

I have 3 groups: anonymous, registered and admins. After writing an
article it shows up for 'anonymous' and 'registered', exactly as set
in the group permissions. No problem there.

However, I also made several categories. As long as the article
remains uncategorized, everything is fine. But when I assign it to a
category it vanishes from the view of the 'anonymous and 'registered'
groups.
In the categories I have 2 permission options:
'tiki_p_view_categories' and 'tiki_p_admin_categories'. Even if I
assign both permissions to the category, it doesn't make any
difference. The article remains hidden.

Quite ridiculous is, that i have another instalaltion of tiki 2.4, where i can chose out of 5 differrent permissions within the categories.

Cashes have been emptyd.

Hiere is my configuration:

Group Anonymous:
tiki_p_articles_read_heading
tiki_p_list_image_galleries
tiki_p_messages
tiki_p_read_article
tiki_p_search
tiki_p_topic_read
tiki_p_view
tiki_p_view_calendar
tiki_p_view_categories
tiki_p_view_categorized
tiki_p_view_directory
tiki_p_view_events
tiki_p_view_faqs
tiki_p_view_image_gallery

The particular category "in progress" has no group-specific permission (standard / yellow)

The article has category "in progress" assigned.

Anonymous can´t see the article.

Ridiculous is, that if i try to assign a specific permission to the category "in progress", just the following two permissions are available for selection:

tiki_p_view_categories
tiki_p_admin_categories

Even if i assign those to the category for anonymous, they are not able to see the article.

One cannot assign permissions on individual FAQs. This prevents from creating FAQ for different level of users.

{syntax type="tiki" editor="plain"}
While updating from 1.9.11 to 2.1, we ran into a bug in tiki-categpermissions.php.

We have a category structure with multiple levels of categories, and assigning to children seemed not to work as intended.

I had a look at the code, and it seems like it only assigns to one level of children, and never checks for more levels of children. I rewrote the code quickly to solve our problem, and attaches the patch I used.

I don't know if this breaks all code guidelines in tw, but it works ;)

Using tw.o forums and 2.0 (afaik):

You add a screenshot attachment to a reply in a forum post, and if you click on "preview" first, (as you would do on wiki pages), the image is lost (no tag is inserted on the forum post to help you link the attachment).

However, if you do the same attachment on a post, and click to post it (without previewing it first), the attachment link is shown.

Example at tw.o forums where it recently happened:
[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=29608&thread_sort_mode=commentDate_desc&was_queued=n]

---
according to comment added to this bug report, this issue is still present in branch Tiki5 still (so probably also in trunk)
---
Unbelievable, bug still present in forum posts in 12.x since 1.x! (with forum replies, there is warning, at least, but not yet with brand new posts in the forum and attachment is lost indeed) {sign user="xavi" datetime="2013-11-22T09:45:52+00:00"}

Reproduced here:
http://xavi-9794-1986.show.tikiwiki.org/tiki-view_forum.php?forumId=1
u: admin
p: 12345

In version 1.10, when selecting the Autocreate Corresponding Category in trackers, the new categories are created. However, when they display, ie. in any area where you would assign a category, like article or blog, the category is listed by "tracker 15, item 53" or such and not by the description of the tracker.

Using __Shoutbox__ with __Autolink__ option enabled....

Entering http://www.foo.bar in the shoutbox correctly converts to [[Link], but entering http://foo.bar does not

It would be nice to generate periodical stats reports in order to track for example the learning curve

I'd like to see some sort of an "autosave". That way when you're engaged in editing a really lengthy page, it will save itself periodically. For those of us that have flaky internet connections, this would be a huge boon. My edits wouldn't necessarily be lost if my internet connection goes pouf for a few minutes.

There is bad output on the link when the linked page description has WikiWords.

Example:
[http://tikiwiki.org/TikiLiveCD]

On top, there is alink to pages which have as description the Word "TikiWiki". And it produces some outptut like:

^ca TikiWiki 1.9.7 + 1.10 cvs!" href='tiki-index.php?page=TikiLiveCD%2Cca&bl' class='wiki'>TikiLiveCD,caes TikiWiki 1.9.7 + 1.10 cvs!" href='tiki-index.php?page=TikiLiveCD%2Ces&bl' class='wiki'>TikiLiveCD,es
^

Banners show as just an empty box when displayed. Images don't work, text doesn't work, nothing will get it to display anything but an empty box.

{banner zone=XXXXX} doesn't work either.

Suggested on IRC:
(4:39:16 PM) mose: maybe what is missing in banners feature is a way to point to a custom tpl


This would give more flexibility. It would be easy to add Javascript, or very special banners or using variables (language, etc)

If a wiki page, we could easily delegate management and maintain edit history.

When doing administration in the wiki, for instance, in configuring menus, if you want to change permissions, you have to edit each item one at a time.

There appears to be some conflict regarding values returned by tikilib's list_file_galleries, returning 'parentId' instead of 'galleryId', when tiki-batch_upload_files.php wants galleryId.

This results in the pulldown list of which gallery to move the incoming files having wrong values set, moving them to the 'parent' gallery instead of the selected gallery, and for top-level galleries, moving them to the invalid "gallleryId = -1"-gallery, where they are unrecoverable.

Copied a bunch of files in directories several levels deep to my batch upload directory. Selected option "Use the last sub directory name as description". Files have no description. This is on a Linux Ubuntu TW 2.0 system.

This is a great feature for image gallery. Would be really nice for file gallery too.

{syntax type="tiki" editor="plain"}
__When you create a zip which contains subdirs the system seems to work but nothing is done.__
tikiwiki accepts only a zip file with one level to load a lonely galery.
~~#FF0000:__This can be, should be enhanced__~~

!!This is the bug : it must not don nothing without an error message.


!!The enhanced functionalities :
Now what is the most important problem. When you want to upload many files they are generally into a structure of directories and subdirs with some levels.
This subdirs structure fits with a meaning, groups of file, with same properties and generally the groups that you want to retrieve into the gallery structure (galleries hierarchy).
Generally the files systems don't support libel, comments etc... that be easily communicated, which informations we can hold with the tikiwiki file gallery.

The consequency of these premises is that the best way to load such a structure is that the zip subdir structure should be imported as a gallery structure with the attached files.
After the galery manager can enhance the information (files names, sub-galeries names, comments, properties, rights etc...)
!!
Further the problem of upgrading a voluminous file galery :
1- security and reliability : such load could not be done only into an empty galery without sub ones neither files
2- the system could memorize the subdir names and accept zip upgrades if the structure fits. First same dependencies, accept new subdir and new files, and following the update options of files with same name accept the upgrade keeping associated informations.

When renaming a page, an option to automagically add a placeholder page.

This placeholder page should be the redirect plugin, which sends to the new page and has "301" headers so search engines know to update their DB.


Related:
[wish1489|Wiki page name Alias]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
[wish1292|Plural WikiWords when using ((WikiWord))]

TikiWiki.org gets a lots of referral links from other sites that have the "Powered by TikiWiki" footer enabled. It would be great if we could take advantage of this.

I propose that the referring site's URL should be appended to the link, so that we could create (if desired) custom landing pages for incoming links from high-traffic sites (such as the FireFox support site). I envision the incoming list to be something like:

http://www.tikiwiki.org/powered+support.mozilla.org

Then on the wiki page "powered+support.mozilla.org" we could "sell" Tiki, explain why it was chosen to power that particular site, specific features, etc. In the .htaccess we could have a fallback page (simply "powered" to collect all other referrals that do not have a custom page.

[http://freshmeat.net/browse/1099/|bibliography management system] like www.bibwiki.com

http://refbase.sourceforge.net/

Could probably be done by a smart combination of ((doc:wiki)) & ((doc:trackers)) in a [http://profiles.tikiwiki.org|profile].

[http://en.wikipedia.org/wiki/Wikipedia:CITE|This guideline uses the terms "source", "reference", "citing", and "citation" interchangeably.]


Related:
[wish1825|Generate footnotes at the bottom of a wiki page] (a simpler version of the current wish)

{syntax type="tiki" editor="plain"}
"If a user upload a big avatar (more than 45x45 px) tiki 2.1 not 'avatarize' and show the big image in the forums. This problem may be very uncomfortable when you read a forum topic."

I can confirm that this still occurs on tiki.org and whatever Tiki version it is running presently, specifically with GIF images. -- ssanders

{syntax type="tiki" editor="plain"}
Dear community,

Here's a screenshot:
{img src=show_image.php?id=70}
Many blessings.

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.

Problem 1:
I created a Wiki page containing the following:

{img src=images/code.png}%%% {CODE()} {THUMB(id=5)}{THUMB} {CODE}

If I select Preview while in edit mode, the thumbnail is displayed, and placing the mouse cursor over thumbnail displays the fullsize image. After the page is saved and displayed, moving the mouse cursor over the thumbnail does not display the fullsize image.

Problem 2:
I created a Wiki page containing the following:

{img src=images/code.png}%%% {CODE()} {THUMB(image=>img/wiki_up/someimage.jpg)}{THUMB}
{THUMB(id=5)}{THUMB} {CODE}

If I select Preview while in edit mode and move the cursor over the first thumbnail, no fullsize image is displayed. If I move the cursor over the second thumbnail, the fullsize image corresponding to the second thumbnail is displayed. If I then move the cursor back over the first thumbnail, the fullsize image corresponding to the second thumbnail is displayed.