Category: Feature request

The actual text color selector should be improved.

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

First the tooltip says "Foreground color" but it should be text color or... something.

Second the color palette is really from another age and the colors are really not good.
There no "real" green or red, etc.

We should use the bootstrap colors: https://getbootstrap.com/docs/5.3/customize/color/

Location: local server
O.S. : Windows 10
Method: WAMP

Issue: Can't easily utilize FADE function. Assumption is when utilizing tiki on an active website, it will behave the same as a local server.

Request: Remove FADE as a plugin and instead make it part of TIKI so a user can just add FADE tags herself.

Benefits:
* This will ALWAYS work as opposed to right now, FADE magic wand won't
activate after it was already clicked on.

* User can drag and drop items into a wiki page and keep current formatting.
Yes formatting is intact when pasting, but NOT when pasting inside the current fade menu.

* User can edit at any time, move the faded items any where and keep formatting inside the FADE tags. Information is only handled once.

Example:
User opens a new tiki page utilizing the wysiwig editor.
User would paste formatted items into her page.

User adds FADE tags without clicking on the magic wand.
1. Prep your kit
[FADE color=red; iconarrow=no; title="Click here if you are a newbie"]
1. do something.
2. do something after first step.
3. do something again.
[/FADE]

Later, user edits the page again to add another FADE tag. This time NESTING and adding bulleted list with color fonts.

1. Prep your kit
[FADE color=red; iconarrow=no; title="Click here if you are a newbie"]
1. do something.
2. do something after first step.
3. do something again.
[FADE color=yellow; iconarrow=yes]
1. when condition is met do this....
2. if not your condition do this instead
[/FADE]

Open the following if you need to copy and paste 30 lines of code.
[FADE color=orange; iconarrow=yes]
30 lines of code
[/FADE]
[/FADE]


Expectations: When using WYSIWIG editor.

* Being able to keep formatting when pasting into a FADE user interface.
(It doesn't keep format, no bullet list, no colors)
(Also, when you save and view the page, the items pasted into FADE are all
jumbled page code, not neat listings.)

* Being able to utilize the FADE function more than once.
(It works once, then you have to save and re edit).
This causes needless tracking, needless rollback history.

0x40736375

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))]

The help for the survey features says this about option "Wiki textarea":
"Options are: rows,columns,toolbars.
Example: 10,60,n (toolbar can be "y", "n" or "c" for comments toolbar)"

Actually it's not rows and columns, but height and width. No matter how small you define it, user can enter text (virtually) limitless.

And the option c for comments toolbar is without any effect that I could notice?

In Tiki23 (and more) we have different name for what appears in the user name the same thing. (bolder if he is not English mother tongue)

{CODE(caption="This parameter is a caption" theme="default")}Caption{CODE}
{FADE(label="This parameter is a label" icon="y")}label{FADE}
{ALINK(aname="This parameter is a (anchor) Name")}Name{ALINK}
{button href="#" _text="This parameter is a label" _type="info"}

Etc... You understand the idea. Sometimes it may be different WITHIN the tool usage (one word in the Admin area, another on the wiki page, etc).

I don't want to argue about what do what and improve the exact terminology of things.
I want to improve the user experience by using consistent parameters so he feel less confused (Tiki is confusing... ?)

So when the user (not necessarily Admins) edit a page and add a plugin directly he doesn't have to look the doc to know if he should use; caption, label, name or title.

We may end with some "specificities" due to the real usage but it have to stop to be a Russian roulette. ;-)

We have in Tiki a way to submit and approval Wiki page revisions.
Unfortunately the naming and labelling of things make hard for new coming (and oder) to find documentation and the feature on the Tiki preferences;

Related
*https://tiki.org/forumthread77682-Information-Documentation-on-Tiki-wiki-staging-and-approval
*https://doc.tiki.org/Flagged-Revisions
*https://doc.tiki.org/Wiki-Page-Staging-and-Approval
*https://doc.tiki.org/Wiki+Page+Staging+and+Approval
*https://dev.tiki.org/Flagged%20revisions%20tab
*https://profiles.tiki.org/Staging_and_Approval
*https://doc.tiki.org/Staging-Approving-Group-Category-Permissions
*https://doc.tiki.org/tiki-searchindex.php?filter%7Econtent=staging

We should decide a name for this and use it everywhere.

We already have:
* ((doc:PluginTrackerStat))
* ((doc:Computed Tracker Field))

But we would need something additional for the following use case:

We have a tracker with a list of tasks. Each task has typical values:
*Open/Pending/Closed (tracker status field)
*Name (text)
*Description (text area)
*Assigned to (user)
*Assigned by (user)
*Priority (drop-down of 1 to 5)
*Creation date (system generated field)
*Last modification date

This is very similar to:
http://profiles.tikiwiki.org/Simple+Bug+Tracker

((doc:PluginTrackerStat)) could provide some stats on how many tasks are in each priority.


Now, imagine each task has 3 additional values:
*Original estimate (do not change the value of this field)
*Hours spent so far
*Time remaining estimate.

((doc:Computed Tracker Field)) could calculate 2 additional values.

* ''Current estimate'' would calculated by ''Time remaining estimate'' plus ''Hours spent so far''
* ''How on-target are we?'' would calculated by ''Current estimate'' divided by ''Original estimate'' times ''100''

So far, so good!

However, we would like to know:
*The total number of all hours of work remaining.
*The overall ''How on-target are we?''

((doc:PluginTrackerList)) coudl be extented to have a report of the total number of hours, with certain filters.

Then, Tiki could be used to manage a Tiki Sheet:
http://profiles.tikiwiki.org/Time+Sheet

In the future, we could generate ((doc:Graphics and Charts)) from this data, like we do in the ((doc:spreadsheet))

Tiki has internal ((doc:search)). It is fully integrated, checks permissions, and works on shared server, etc.

However, in some contexts, better support for external search technologies would be useful.


Related:
http://framework.zend.com/manual/en/zend.search.lucene.html
http://www.sphinxsearch.com/
http://www.google.com/sitesearch/
http://lucene.apache.org/solr/
http://ir.dcs.gla.ac.uk/terrier/

Please see: ((tw:CMS Landscape)) and ((tw:Wiki landscape)) and try to edit those pages without getting lost.

Now you understand what we need :-)

Also: https://doc.tiki.org/Unified+Index

This looks cool:
http://twiki.org/cgi-bin/view/Plugins/EditTablePlugin

When trying to remove an item from a Structure, the page refreshes and there are 2 options at the top of the page that aren't very obvious to the user.

This is inconsistent with our typical Tiki UI. Usually we either have a Popup with a request for action OR a page that requests Confirmation.

I would like to see a Popup with request for action

When a calculation field is empty it stop the index rebuild operation.

In the console it throw an none very instructive error:
{CODE()}
[root@server html]# php console.php i:r --log
[04-03-2020 16:20] Started rebuilding index... logging to file: /tmp/Search_Indexer_mysql_xxxxx_tiki21_console.log
Unified search engine: MySQL, version 10.1.44-MariaDB
error: The search index could not be rebuilt.
Expecting "(" near ""
{CODE}

#The error should be explicit: Field (permaname and Id) is empty or misconfigured.
#The index should jump over and continue

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.

It would be useful to extract all permissions of File Galleries or Wiki pages or Forums, etc

This would provide a way for admins to know who actually has access to what.

[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)

Right now, group expiry just removes the user from the group.
In use cases of membership management in associations, or business, in which members pay a fee per year, this feature is needed for an easier setup without so much intervention of the admin in so many steps.

Scenario: NGO with 3 levels of users:
* A) "regular members", needing tyo pay fee FA
* B) "associated members" , needing tyo pay fee FB
* C) "students", needing tyo pay fee FC

2 levels of time-dependent fees for each group:
* first year you pay feee F*1
* from second year onwards you pay a different fee F*2

When the membership payment for a year is over, that user should be automatically re-assignable to another group defined in the group transitions, which should allow to set conditions for the trigger to happen:
* when group expiry happens
* when freeperiods frmo ((doc:PluginMemberPayment)) expire
* when some tracker field = some value, higher/lower than some date or other tracker field, etc. (this one is just brainstorming; it should be thought more {sign user="xavi" datetime="2016-05-27T10:51:06+00:00"})

This way, they can be requested to pay for the fee F*2, knowing that they have to pay FA2, FB2 or FC2. With current codebase, after gruop expiry, you do not know which group that user belonged to, and you can't offer that user the right fee to be payed for with plugin MemberPayment.


HTH

It would be great to be able to bind arbitrary actions to user creation.

For example, I would like to have a blog created on user registration, named after the username.
Then I might want to have only that user with permissions for some items.
Maybe point the user's group homepage to something user-specific.

And et cetera :)

Discussion over at ((Spam Protection))

http://www.wikimatrix.org/wiki/feature:Blacklist

I'm new to tiki and just installed tiki 13.1 on my server. After a fresh and what seemed to be a standard install I had a blank page displayed when trying to reach the main administration page : tiki-admin.php. No error message, just a blank page. And some other admin pages where reachable. (tiki-adminusers.php for instance)

It turned out in the Apache logs that a php function, iconv_get_encoding(), used in Zend framework was called but undefined, leading to a fatal error. And it turned out that a __php dynamic extension, iconv, was not loaded in the php.ini__

It seems to me that it should be checked during the install, or at least __be part of the Tiki server compatibility check__ and should be mentioned here : http://doc.tiki.org/Requirements

Thank you very much.

p.s : I wrote a post on the forums about it, but it seemed appropriate to send a message here too. Keep up the good work.

For social media sites, not all users get along with each other. It's just part of human nature. Rather than involve administration over every single quibble there should be an option for users to block/ignore other users.
Ideally, the block feature should be easily accessible from the Userlist, Messages, forum, and any author link.

Blog post comments are often overlooked by the blog owner, because the owner doesn't get notification of blog posts. I propose we add the option of getting notified when someone comments on your blog.

With the Journal theme, blog descriptions (at the top of tiki-view_blog.php) are displayed with a #b7b7b7 (light gray) text color on a white background. Considering that text is small, this b7b7b7 to #ffffff contrast means that the text is not only hard to read, but even easy to miss, as can be seen in the attached screenshot.

This happens because the Journal theme specifies color #b7b7b7 for class help-block, and because blog descriptions have the help-block class. I understand that help text is made discreet. But frankly, such a low contrast is a readability issue. Moreover, descriptions are not help text. They do not warrant big red text, but with such a small size, I'm not sure they even warrant gray. I would have no problem if they were pure black.

I am not clear on what change(s) are best, but I don't exclude that ideally:
# help-block color would be changed
# Blog descriptions would be changed to use a different, more prominent class

Setting feature_tell_a_friend=n doesn't affect the "Email This Post" functionality for the blog, so visitors is always offered to mail the link for a post. Imho the admin should be able to choose if this is allowed or not.

We need a "Blog This" thingie.

I'm talking about something similar to Blogger's BlogThis gizmo. This is a button you can add to your browser toolbar, configured to connect to your Blogger blog, so you can make an entry right from a web page you're browsing, without having to go to your blog creat a new message, post the url, copy the text, etc... instead you just click the BlogThis button and it pulls up a form right there.

Here's the description.

http://www.google.com/support/blogger/bin/answer.py?hl=en&answer=41469


It would be SUPER.

With the prefs.feature_blog_heading perm enabled and tiki_p_edit_templates dissabled, users - with the perm to create blogs - will be able to create blogs but no heading will be shown when their blogs are viewed in tiki-view_blog.php.

In essence, unless both above named perms/prefs are enabled a user won't be able to create a heading, and no heading will be saved in DB for the blog.

And since the conditional to handle situations when $heading is empty has been removed in rev 9146 the blog will show no heading what so ever when it is viewed.

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.