Category: Feature request

http://doc.tiki.org/PluginArticles

Currently, there's no option to display the comments of article when using PluginArticles

Using "Anchor links on headings" (tiki-admin.php?page=wiki&highlight=wiki_heading_links) you can enable having a link and an icon for it in your headings.

While it is awesome for certain headings (the higher one) it is very annoying for others (the lowers) and break design (adding an extra line to display the icon).

It would be nice to have a selector for this to select: H4 and above, H3 and above, H2 and above, H1 only).
(may need rewording).

{syntax type="tiki" editor="plain"}
On UI.tikiwiki.org, I can add a few annotations to some images, but if I forget to click "Save changes to annotation", I will lose my annotations.

Currently, an administrator of a Tikiwiki installation has to hunt for upgrades, updates, and security related information of his installation. It is often cumbersome and sometimes dangerous, think of the delay in fixing a crucial vulnerability, it has happened elsewhere before. It might also be nice to know that ppl are using current and feature complete software.

Anonymous comment posters do no receive email notification of replies to their comments, even if they leave their email as indicated as indicated.

There should be a way to communicate back with anonymous comment posters which provide their email (and have some new checkbox ticked by default with "__Notify me of replies__")

That's one of the main differences why there is lot of feedback on content in wordpress or other blogs or cms/s and almost no comments and feedback from anons to Tiki sites. If they ever come to leave a comment, they do not get feedback on their comment, and they are implicitly discouraged to come back or provide more feedback (or even become real users, when the site is open for anonymous registrations).

It's sometimes useful to allow anonymous or other users without full perspectives-related permissions to switch perspectives. For example, I want to demonstrate themes by using a link such as -+ tiki-switch_perspective.php?perspective=21 +- , in a dropdown menu, to switch to perspective 21. This perspective has preferences including a home page with info about the theme, using the theme itself, and so on, all set by the perspectives feature. The user continues to be in that perspective after leaving the page, so can see a blog or calendar or whatever using that theme, until switching to another perspective. This works fine for admin, who has all current perspectives permissions, but doesn't work at all for anonymous users. Visiting the page shows the theme set for the page but doesn't change the perspective.

I imagine there could be other scenarios where users would select a perspective and stay in it until they switch to another one.

There are now four permissions related to perspectives:
* Can admin perspectives (tiki_p_perspective_admin)
* Can view the perspective (tiki_p_perspective_view)
* Can edit the perspective (tiki_p_perspective_edit)
* Can create a perspective (tiki_p_perspective_create)
I propose that another permission be added:
* Can switch perspectives (tiki_p_perspective_switch)

Or whatever fix would be effective here. The "Users can change theme" option on tiki-admin.php?page=look serves the same purpose but seems to be set via that admin page rather than on tiki-objectpermissions.php.

Somewhat strangely, if I give anonymous the "Can create a perspective (tiki_p_perspective_create)" permission, then switch-perspective works for anonymous, who can see the list on tiki-edit_perspective.php and can input a perspective name but it doesn't appear in the list to be edited, etc. so this could be a hacky workaround but the clean solution of a new permission would be much better.

{syntax type="tiki" editor="plain"}
I think it would be good to have the option to have Automatic quarantine of forum posts that contain an external link. There would be an alert informing users that posts containing an external link will display after being approved by a moderator.

This would effectively end the kind of (likely AI or other automatic) spamming for link placement that we've seen in the tiki.org forums, I think.

This could be generalized to enable site admins to quarantine posts containing other content as well, such as hate speech. Maybe the admin preference would include a checkbox for "external link" and a text field for other content.

About the implementation, on the edit-forum page (such as tiki-admin_forums.php?forumId=14&cookietab=2#content_admin_forums1-2) there is an "Approval type" admin pref with options "All posted", "Queue anonymous posts", and "Queue all posts". To me the wording is a little unclear but maybe "Queue posts with external links" could be added here.

(I think "Require approval for" would be clearer than "Queue" in the wording of the options.)

It might also be good to extend this to also apply to comments, or to be ready to, if spam starts showing up there.

Use case:
* You have content templates enabled, and revision approal system set for wiki pages.
* You create a new content template "MyTpl" based on a wiki page, under revision approval.
* MyTpl Version 2 is approved. Version 3 is the last edited version of the content template, with no approval yet.
* You create a new wiki page "MyPage", apply the template MyTpl, and you get applied v3 (non approvaed), instead of V2, which is the approved one and should be the one applied by default.

To reproduce, log in as admin:
u: admin
p: 12345
Wiki page:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-index.php?page=MyPage
Template:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-index.php?page=MyTpl
History of versions of the wiki page template:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-pagehistory.php?page=MyTpl

See that last approved version is v2, but there is a v3 which has more content.

Edit the wiki page and try to apply the template:
http://xavidp-1553-5818.show.tikiwiki.org/tiki-editpage.php?page=MyPage

V3 is applied instead of v2 (the last approved version)

Related: ((Areas Perspective Multi-domain dogfood))

This can be viewed both as a bug report or a feature request:

The logic for article images breaks standard Tiki admin logic in that you cannot (!) use images from the file galleries. You have to upload them separately into where ever they get stored (unknown), stripping users of the ability to centralize image storage and scaling images by demand. This also means that the user must use a local image manipulation tool for scaling...

This is true for both standard images (by topic) and for user images!

The following patch provides a version of the ARTICLES wiki plugin, that displays article titles only. To use, people simply specify titleonly=>1 in the options for the ARTICLES command. This is in production use on the [http://www.asperger.asn.au|Asperger Services Australia] website -- just look under ''News'' on the right-hand side of the page.

To filter articles by language:
{CODE()}
{ARTICLES(lang=>)}{ARTICLES}
{CODE}


Using the nifty lang & notlang as below gives more flexibility:
{CODE()}
{LANG([not]lang=>code[+code+...])}text{LANG
{CODE}

Articles do not have history. With wiki pages, there is always an undo (and multistage, and with comparison etc.). Articles don't have that, and I believe they should, and it shouldn't be hard to add... The revision system could be shared, or at least recycled, from the one wiki pages have.

{syntax type="tiki" editor="plain"}
There is no option in the admin topics to display the last date an article was updated (modified).
This is very common for articles or news to show this information.

I believe we have it stored somewhere.
It would be nice to add this option at : tiki-article_types.php

You can use Tiki articles in multilingual website having article for several language.
The usual process is to create a main article (default language) then create other articles with different language and assign them as translation of the previous article.
Article => Edit => Advanced, Attach existing article ID as translation

You have to insert the ID of the article and that really not user friendly.

You should be able to retrieve articles by name in a select.

---

On second thought...

If wed really like to improve we could reuse the same interface/system we have with wiki pages (translation) as it is working fine is much better (proposing translation if missing and displaying set of translated documents) and will be better for UX (consistency).
I just wonder if it worth the investment.

Clicking on the title of an article should be like "read more", like for the image. Seems more intuitive to me.

Please see:
http://tikiwiki.org/tiki-view_articles.php

And imagine clicking on the title to be taken to:
http://tikiwiki.org/tiki-read_article.php?articleId=166

This is an easy fix.

Some routine to link a tracker to an Image Gallery, making a tracker of every image gallery, adding an item to the tracker for each item in the ig, etc, would seriously enhance the functionality in the image galleries feature. Image Galleries do handle right the image files (tif support would be nice, though). However, it is near to useless to classify the images themselves, the "categories" feature being of very little use, for example, to have a catalogue of paintings with artist's names, titles, dates, etc. Having some linking code written, it would be easy to use the images through the tracker feature, leaving the handling of the image files to the gallery.

would be much nicer

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

At https://dev.tiki.org/tiki-list_comments.php you can see the list of comments.
(I went there because for some obscur reason I don’t receive notification on comments and I was trying to find a way to get the information).

{img fileId="1431" thumb="box"}

All those without title or/and untitled (not sure what is the difference in the code) make it impossible to follow the comments origine and it doesn't look good.

The parent object name should be use as reference when the title is missing

IE: Use this tracker item title as comment title if comment is not found.

No problem at all, but a request for more integration with the wiki and forums.

At this moment (in version 3 (after the bug is corrected)) there is only one forum, which can be used to discuss a wiki page. This is really great.

A number of users in the [https://tiki.org/forumthread59532?topics_offset=29|forum] liked my suggestion of an "auto delete unverified user feature." Often times spammers attempt to create accounts with fake email accounts. These accounts accumulate over time creating a nightmare to clean up after a while.
A feature to delete users matching this status after a specified period of time will help reduce the need to search through the user lists to purge invalid accounts.

phpBB is a popular open source forum software.
Sometimes, a forum is not enough.
So, the data must be migrated from phpBB to Tiki forums...

If you want to help:
Please post links to similar scripts.
ex.: phpbb to invision board, etc
If/when we do a script, we should do for all major forums.
---
__From kerrnel22 on 11/20/07:__

I have almost completed an integrated TikiWiki forum migration tool for 1.9.8.x and 1.10. Initial release will be to migrate only Tiki forums from one Tiki install to another. However, hooks are in place, and the intention is there, to work on extending the migration tool to importing of phpBB2 (or any other forum software) into Tiki. If you would like more information, email tiki.kerrnel@kerris.com. I expect a general release of the forum migration tool (for Tiki forums only) into cvs of both branches for beta testing by December 1/07. If all goes well, I'll have something released for phpBB2 migration prior to Dec 31.

UPDATE: It's not a regression, sorry for the noise (I was confused). {sign user="xavi" datetime="2013-11-18T13:09:45+00:00"}

Usability improvement: nl1 missing in route.php for newsletter1

If Trackers had the "tracker template" feature, it would allow for better pre-made extended features for Tiki at install time.
In tw.o forums, some people requested like: address books (imagine with the same basic fields as Mozilla Thunderbird & Evolution, etc. address books, ... Export from you local program (through csv), and import to your address book in Tiki (through csv).

The same for "Offers & Demands (linked or linkable)", that many people/communities would like to use like "out of the box" feature. I do have that kind of trackers made (basic, but working for production already: http://valldelcorb.org/trackers - http://valldelcorb.org/Comparteix (1.9.x) or http://intercanvis.net (1.10.x) using tracker plugins in a general Wiki page).

Since duplicate tracker is already coded in 1.10, and templates concept already exists in Tiki, Tracker templates would be a nice MUST in the MID and LONG run.

Tracker templates should be selectable at install time (in the new installer devs. are thinking/designing -> ((Install)) ), or at a later stage through Mods, maybe?