Category: Feature request

Long overdue feature in TikiWiki:

http://en.wikipedia.org/wiki/Help:Section#Section_editing

[http://sourceforge.net/mailarchive/message.php?msg_name=435AF64C.1050106%40marclaporte.com|2005-10 discussion on the developer's mailing list.]

If "edit by section"=Y as a wiki feature, all H2 should create a bookmark and a section that can be edited individually. As an option, all heading levels could become sections.

Section edit should be optional and there should be a syntax to override (either way)

More explanation from our friends at WikiMatrix:
http://www.wikimatrix.org/wiki/feature:section_editing

New section edit feature is very useful. Three minor adjustments:

A- There is no way to edit the section preceding the first !,!!,!!! etc
This would be nice as well.

---

B- When getting to the section via an anchor, the edit by section icon is too high. To see what I mean:

1- login to doc.tikiwiki.org

2- go to
http://doc.tikiwiki.org/Editorial+Board+Meeting+2008+05

3- Then click on an anchor like:
http://doc.tikiwiki.org/tiki-index.php?page=Editorial+Board+Meeting+2008+05#2_3_Proposed_changes_to_doc_tw_o_site

Notice how the edit button is not accessible directly? I need to scroll up a bit (not ideal)

---

C- After editing a section, I should be sent back to the anchor of the section I just edited

So I can see what I just edited.

On Tiki Security and Login admin control panels we have an option to display Captcha_questions.
This is working fine where Google re-captcha fail (and it fail) or if your user have issues with the internal Tiki captcha.

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

But how do we do that ?

May be the easiest way is to perform a translation using the custom translation existing system, BEFORE the answer is verified.

Simple number case;
"Answer to submit, 3+4=:7" => "Combien font 3+4=:7",

Text case;
"In which country is the Liberty Statues: New York" => "Dans quelle ville trouve t'on la Tour Eiffel:Paris",

Translation being done before the verification allow a better multilingual and multi-cultural usage.

This would be useful for troubleshooting.

If Tiki can't find the location automatically, maybe we could have a pref, which indicates where the error log is.

Right now, the sefurl for article topics is:

articles?topicName=news to tiki-view_article.php

Possibly, articles/news should point to tiki-view_article.php?topicName=news

I think this might be common enough to be a core feature.

__A CMS without SEF URL means it is a Bug : Usability__

it's a by setup checkable standart in a high quality CMS
simple weblogs like http://www.s9y.org/ have such a feature

why :
google likes */this_is_a_very_god_page.html
and normaly google didn't index
*/mybugy.php?bestpage=my&t1=page&t2=is&t3=the&t4=best&indexed_by_SE=normalnever

i think the best webpage is nothing if SEFURL isn't working


the half way is done with the htaccess - ok
the next half way was a mod from http://www.coofercat.com/wiki/TikiURLtInstall

It's working in a root env with 1.9.x and 1.10cvs
that means only if /tmp is writable for the webserver - this is the bug

but online on a vserver this shit happens to me

Warning: mkdir(): open_basedir restriction in effect. File(/tmp/71) is not within the allowed path(s): (/srv/nww/webx/:/srv/nww/htdocs/phpMyAdmin/:/srv/nww/htdocs/confixx/html/gesperrt/) in /srv/nww/webx/html/wiki/lib/adodb/adodb.inc.php on line 1551

Warning: fopen(): open_basedir restriction in effect. File(/tmp/71/adodb_716f2422695ca15b221f4ce6f146321c.cache) is not within the allowed path(s): (/srv/nww/webx/:/srv/nww/htdocs/phpMyAdmin/:/srv/nww/htdocs/confixx/html/gesperrt/) in /srv/nww/webx/html/wiki/lib/adodb/adodb-csvlib.inc.php on line 298
......this msg repeats about 1000 times
did you know what's going on

I started to debug this problem
but it seams to get bigger and bigger

saved data titles must be renamed
becorce
http://localhost/HEAD/page-page%202.html
didn't result in
page 2
and so on

Links to -+tiki-admin.php+- pages should have a sefurl version - probably -+admin+- so Look & Feel would be [admin-look] etc (maybe this needs discussion)

Allow to choose in the RSS feed, one topic to show.

Semantic link relationships seem until now only browsable by admins.
Since there is - besides the admin view - no other way to get the semantic relations listed, no one else can get advantage of semantic links and will make no efforts in setting semantic relations.
Concidering the importance of semantics in wikis a plugin seems highly necessary to get the feature of semantic links in tiki started.

__Request:__
Likewise to the Plugin ((Backlinks)) all pages that link to a specific page in a specific semantic relationship.

__So far:__
The semantic_links module is supposed to enable views on semantic relationships.
And indeed, when selecting a semantic type and push the button "show usage", the result shown is exactly what I need.
However this view is only possible for admins.
But since that view for admins is already existing, I would estimate the efforts to implement a plugin as low.

__Plugin idea:__
Relating to the example shown in the documentation of ((SemanticAdmin)) dogs and cats are subsets of animals.
We want the page "animals" to list all subsets by a plugin likewise to

{SEMANTICLINKS (semantictype=subset, page=animals, info=hits|user, noheader=1}
{SEMANTICLINKS}

The result would be:
- dogs
- cats


__Insufficient workarounds:__
Until now the above shown results have to be specified manually as invert relations.
For automatic listing, existing plugins ((PluginShowpages)) / ((PluginListpages)) / ((PluginSearchtitles)) do not work.
So the only workaround without the requested plugin I could image would be to tag the pages "dogs" and "cats" with the a tag "subset-animal" and than use freetags plugin for a listing dogs and cats in the animal wikipage - likewise to the status tags in this tiki. However, that sounds like a bad abuse of tags, since we already got that information saved in our semantic links relationship - we just need to get it readable.

__Related pages:__
Relating to forum discussion with marclaporte:
[http://tiki.org/tiki-view_forum_thread.php?topics_offset=20&topics_sort_mode=lastPost_desc&forumId=4&comments_parentId=38751]

Aliases of the same page are not very interesting, because it's link to self.

But antonyms, related, etc would be nice.

{syntax type="tiki" editor="plain"}
The ((doc:Inter-User Messages)) system is quite nice.

However, it means:
1- That users have duplicate mailboxes
2- And the recipient can't just click reply

On dev.tikiwiki.org, this is not so nice because people already have an internal tiki mailbox on tikiwiki.org

So, let's think about an additional/modified feature called "direct message" or "direct mail".

This would simulate a regular email. (let's plan ahead that this should be able to send other types of messages (jabber, sms, etc.)

The headers could be:
"from" is Full Name ({$Username}) {senderemail}
"to" is Full Name ({$Username}) {recipientemail}
"bcc" to {senderemail} (So we have a trace of what we sent)

In case some spammers get a hold of it, let's have something like this at the bottom:
This message was sent via {$name of site}


Not sure if this should be done with the ((doc:webmail)) feature, or maybe as an option of ((doc:Inter-User Messages))

See how MediaWiki does it for a good example:
http://en.wikipedia.org/wiki/Special:EmailUser/Marclaporte

Tracker can be (and are starting to be) used for creating forms of offers and demands in communities... (knowledge banks, time banks, openmoney....)
In our case, from tracker demands there is a field linking (through "item link" field) to tracker offers (a demand in the demands tracker can be for a specific offer already inserted in the the offers tracker).

In this case, it's needed that (optionally) a inter-user message is sent to tracker item creator when that item is automatically linked from another tracker item (from another tracker, in our case).

Other way, it's hard for a user to know if another user has requested some of this offers...

http://moviments.net/intercanvis/trackers (1.10cvs)

http://moviments.net/valldelcorb/trackers (1.9.7)

It should be like this feature (tiki-send_blog_post.php?postId=95), but generic for all pages/features on a Tiki site.

Related: we need anti-bot code so spammers don't abuse it:
tiki-view_tracker_item.php?trackerId=5&itemId=546

We already have in version 3.0 on tiki-admin.php?page=login

On permission denied, display login box for anonymous:
On permission denied, send to this url:

Similarly, it would be nice to send people to a specific URL or wiki page upon logout.

Ex.:
"Thank you for visiting"


Some ideas for the future. We should have a section in the admin panel "login/logout/navigation" with things like:

redirect on login (which is group home pages)
redirect on user account validated. Ex.: Wiki page "Thank you for registering"
redirect on logout. Ex.: Wiki page "thank you for your visit"
Close site (except for those with permission). Ex.: Wiki page "The site is closed for maintenance"
Close site when server load is above the threshold (except for those with permission). Ex.: Wiki page "The site is under pressure."
On permission denied, display login module (for Anonymous). (as it does now)
etc.

Also on tiki-admin.php?page=features
Redirect On Error
Custom Home

This would be very useful as we move documentation from tikiwiki.org to doc.tikiwiki.org, for example.

For data interchange with other systems too.

https://developers.google.com/search-appliance/documentation/68/admin_crawl/Preparing#pagepart

class=”robots-nocontent”

http://antezeta.com/news/avoid-search-engine-indexing

{syntax type="tiki" editor="plain"}
For some situations it would be extremely useful to be able to set a separate permission to allow a Group to create a new Forum.

This would then avoid having to give the Group the full tiki_p_admin_forum permission, which then also allows users in this Group to set Permissions.

Whilst the full Permission functionality is extraordinarily flexible and feature rich, it can also be quite confusing for a less experienced user and the use of Categories (ie using pre-packaged sets of permissions) is a much easier function which obviously should still be allowed from the Create New Forum screen.

This is still a valid feature request - so I've refreshed it (Aug 2013) - but its not a particularly high priority

Now we have Scheduler and plugin ListExecute we can fairly simply make an automated notification system for this tracker, to:
* email the originator if it's pending and needing retesting
* open, not fixed and a volunteer is listed
* still open after a very long time (gone stale?)
...that sort of thing.

Anyone fancy trying to set it up? (:mrgreen:)

See screencast

Tiki22 require PHP 7.4.

After installing Tiki22 (git master) I ran setup.sh while running PHP7.2 and it thrown the following.

{CODE()}
Your choice [c]? c
Wrong PHP version: php54 < required PHP version. A version >= php72 is necessary.
Searching for typically named alternative PHP version ...
which: no php73 in (/usr/clearos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin)
{CODE}

Not having 7.4 installed yet I tried 7.3 and got the following.

{CODE()}
Your choice [c]? c
Wrong PHP version: php54 < required PHP version. A version >= php72 is necessary.
Searching for typically named alternative PHP version ...
which: no php73 in (/usr/clearos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin)
{CODE}

And then a lot of deprecation errors.

Tiki 22 work with 7.4 and it should verbose correctly and warn the users.

Show Category Path + Show Category Objects was implemented a long time ago, and somewhat in a rush. One of those temporary things which became permanent. It only works in wiki pages, yet it would be logical to have this throughout the various features.

Seeing the list of items in the same category is very useful as contextual navigation.

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?

I applied current profile related to spreadsheets (as of September 2015) in profiles.t.o:

... https://profiles.tiki.org/Spreadsheet_Test_Profiles

and it does enable the spreadsheet feature and create the intended spreadsheet indeed, but the indicated contents do not seem to get added.

Syntax in that profile page is:
{CODE()}
objects:
-
type: sheet
data:
-
title: Test Title
- [ Test, =A1 ]
- [ =B2, =B1 + A1 ]
{CODE}

I tried with 12.x and 14.x with same results.

Maybe something needs to be tweaked in the profile handler code?:
{CODE()}
/lib/core/Tiki/Profile/InstallHandler/Sheet.php
{CODE}

In trunk (future tiki15) it also fails to add the data to the sheet. Help is needed. {sign user="xavi" datetime="2015-12-31T14:33:57+00:00"}