Category: Feature request

Some prefs should need to be different per language

Ex: logo, site title, meta-description, meta-keywords, menu

So we may avoid:
http://doc.tikiwiki.org/Multilingual%20Menu#Check_language_and_show_alternate_menu


tiki-edit_perspective.php (Tiki5) is an efficient way to override global prefs depending on perspective. So now, how to handle similarly for languages?

Please note that some times, we'll have both perspectives and languages.


Related:
{wish id=968}



Two solutions:
* Add tra() for site title, meta-description
* Make text areas for things that smarty logic would be useful (ex: menu) __Done in Tiki5__

We now need to fiddle in the templates to remove the print icon. In many cases, a print option is not useful.

Need both a tiki_p style permission and a feature_print style feature for this. Need to document the actual names we used, too.

One tiki-wide setting to deactivate all printable pages all links to these pages (with the little printer icon).

This will also be useful for http://mobile.tikiwiki.org/ Let's try to do before 1.9.1

obs: waiting for cvs to unlock to commit

This started when I discovered that when trying to register with an address using the "GMail-Format" like
normal.mail+something@gmail.com and it will fail although the address is valid. I have made a quick fix to allow '+' in the name part of the email address, but obviously more can be done to make this more RFC compliant. Will have to double check that email actually sends, of course.

Some references:

[http://www.regular-expressions.info/email.html]
[http://en.wikipedia.org/wiki/E-mail_address#Plus_.28or_Minus.29_addressing]

This is mainly a test bug report so we can try to make show instances on the two show servers for testing, and not get any existing bugs muddled up

Could someone please make the fields this tracker uses available to the community, please? (easily done, since there's an export/import feature!)

I'm trying to create a support web site, so obviously need much the same thing as this site. Trackers are quite a learning curve, so a couple of good examples would be really useful!

If someone does this, I'll add an export of the fields I end up using and make them available too (I've got a couple of other tracker apps up my sleeve too).

Cheers!

Too many people are having issues:

[http://tikiwiki.org/tiki-searchindex.php?highlight=open_basedir&search=|tikiwiki.org open_basedir issues]
[http://dev.tikiwiki.org/tiki-searchindex.php?highlight=open_basedir&search=|dev open_basedir issues]
[http://doc.tikiwiki.org/tiki-searchindex.php?highlight=open_basedir&search=|doc open_basedir issues]


We need someone who is strong with server administration in a shared hosting context to solve all these issues once and for all.

[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=26696|maybe a hint to the solution?]

Please see: ((tw:Viral Tiki))

Currently there is only one (two) methods to come from blog view (tiki-view_blog.php?blogId=<int>) to the view blog post page: Clicking on the small "Permalink" or "Comments" Link at the bottom of the post.
I find it more intuitive (or I'm just familiarized to this by the other blogging solutions out there ;-) ) to click on the title of the specific post to view it with its comments.

When you check both:

Tracker items allow attachments?
and display attachments in listing?

Then the dl-column (I guess it counts downloads) is being shown by default.

When editing a tracker item, there should be an easy possibility to select, which tracker is a duplicate of this item.

{syntax type="tiki" editor="plain"}
Full thread is here:
http://tiki.org/forumthread47305

"So should we have a new pref "unified_index" and add it as dependency for these features (PluginList, PluginListExecute, etc.), and thus people whose servers don't work with it have the option to turn them off? (effectively acting like a Tiki6)"

I often find a section of a wiki page near the bottom and want to edit just that section, and have to scroll all the way to the top to enable the icons, so either the icons should be always there but hidden (like the heading links), or we need a shortcut key to do that ("i" for icon, or "e"for edit... hmmm, simpler if they're always there)

Many people use the wiki without structures. It should be optional, like the rest.

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.''

See ((doc:maketoc))

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.

Tiki sends emails for several things (watches, password reset, newsletters, etc.) in addition to end users via ((doc:Cypht)) webmail.

System emails should be sent with a valid sender email. Many will put a bogus no-reply@example.org but that is bad practice. We should be using a real email account, accessible via ((doc:Cypht)).

See also ((Transactional Email Providers))

There will be manual replies. There will be bounces. This should be monitored, and handled accordingly. When you have hundreds or thousands of bounces in a ((doc:Cypht))-accessible account, it's tricky and time-consuming to manage.

If you don't handle this, and repeatedly send out emails to invalid accounts, you risk being flagged as a spammer.

Tiki should help detect types of bounces. Ex.:
* Manual reply
* Soft bounce (ex.: vacation message)
* Hard bounce: (user doesn't exist)

There should be a dashboard of all bounces, with a way to see
* The emails with the most bounces (top bouncing emails so site admin can go in order of priority)
* The actual emails with ((doc:Cypht))

And help Tiki admin handle this
* Show where this email is used (user profile, watches, etc.) and help remove.

See https://packagist.org/?query=bounce for potential libs.

XML files are cool for data interchange.

For example, you can create an xml file to feed a Flash animation. However, you still need to update that XML file via FTP. What if you could edit a wiki page (with permissions, history, etc) and have the Flash animation get the data from it as if it was xml?

Or maybe a button on a wiki page "save to .xml", which would save on the filesystem WikiPageName.xml? (where the Flash would know to look for it)

Related idea:
* {wish id=467}
* {wish id=3103}


Louis-Philippe Huberdeau --will look into-- used [http://www.yaml.org/|YAML] --to see if this could be useful-- and it is very useful for the ((Profile Manager))

Blog post edit page (tiki-blog_post.php) has a "Mark entry as private" check box, to restrict viewing to the author. But it doesn't work; any user can read the post.



Needs to be fixed or the option removed from tiki-blog_post.php in time for 1.10.0

Hello!

I'm wondering to know if it is possible to put ((Markdown)) support on TikiWiki roadmap. As many of you know, Markdown is a syntax widely supported by many CMS, text editors, JS and PHP libraries and other Wiki services.

There are even some e-mail plugins, like ((https://markdown-here.com/|Markdown Here)), that allow users to write e-mails on Markdown language and the convert to HTML before sending emails.

Some ""competitors"" allow Markdown support as a plugin, like:

* WordPress - https://br.wordpress.org/plugins/wp-markdown/
* Joomla - https://extensions.joomla.org/extension/ace-x-markdown-editor/
* Drupal - https://www.drupal.org/project/markdown
* Plone - https://docs.plone.org/adapt-and-extend/config/markup.html
* Magento - https://github.com/SchumacherFM/Magento-Markdown
* Jekyll - https://jekyllrb.com/ (AFAIK, this one is used on Github pages)
* Octopress - http://octopress.org/ (I used this one for a long time)

Also, some other frameworks have extensions for markdown:

* Symphony - http://symphonyextensions.com/extensions/markdown/
* Django - https://github.com/agusmakmun/django-markdown-editor
* CodeIgniter - https://github.com/jonlabelle/ci-markdown
* Rails - https://github.com/vmg/redcarpet

So, as Markdown became familiar for a lot of non-technical users, I bet supporting Markdown is a good move for Tiki and also, it may turn easy migrating from other platform using Markdown to TikiWiki.

Permissions on individual wiki pages are great.

But what if you want to change the perms


__Related__
{WISH(id="2151")}{WISH}

Hi,

I am working on a few datamanagement projects these days and look deeper and deeper to the boundaries of the Tracker feature and the Trackerlist Plugin.

Walper (Wolfgang) has a huge pro datamanagement in his company aswell and is committing very helpful additions and is doing high quality fixes to existing bumping features.

Now it appears (actually original idea from Wolfgang), that on the output side using Trackerlist, we face some strict limitations, which could be easily solved with a master and slave setup.

Tracker should be interlinkt on the output base (wikipages, trackerlist or list plugins) to provide some kind of "issue reports", "case reports" etc. where trackerlist output is conditionally interlinked similar to dynamic list inside the tracker.

__basic idea: __

Have two or more trackerlist on a wikipage (optionally paginated or so). the master is on top.

Filter content on the top tracker and dynamically get the related content (to the issue or to the case) viewed below.

In my example use case I see, that it would be important to have the option to print the interlinked output together, for example to print out a full overview of a case to have it physically when the responsible person goes to a court hearing. In Wolfgangs use case it might be mor a report for the customer or so to send out as pdf.

At this point I only did a rough sketch and appreciate ideas and input by other users and devs.
Not my sketched technical solution is what I am focussing on, but instead the idea of the workflow and a good UI/UX for aswell site developers and end users.

Thx for any ideas and help from coders.
I am seing more and more that data management would be one crucial killer feature in context of a better respectively a successful marketing of our "beast" Tiki.

Best regards to all community members,
Torsten

See show instance at http://marclaporte-11197-4860.show.tikiwiki.org/

For many people, Wikipedia (powered by MediaWiki) was their first contact with wikis. MediaWiki has a very nice interface and has done an amazing job to get Wikis known to the public, via Wikipedia. MediaWiki/Wikipedia is probably the best thing that happened to the Wiki world since Ward Cunningham invented the wiki in 1995.

MediaWiki is excellent to make an encyclopedia. However, it is not designed to be an Intranet/corporate wiki with an advanced permission system. Also, MediaWiki is "only" a wiki. It doesn't have extra features like forums, trackers, blogs, etc. Maybe these features will eventually be added to Mediawiki, but it doesn't seem imminent.

Users which want more can use some glueware to combine a Wiki and an existing full featured CMS (ex.: Drupal + MediaWiki or Xoops + MediaWiki) or they can choose Tiki Wiki/CMS/Groupware.

There are apparently millions of MediaWiki installs. In contrast, there are "only" tens of thousands installs of TikiWiki. While this number is very good, we can expect more & more people will want to migrate from MediaWiki to TikiWiki. Even if a small proportion of MediaWiki installs migrated to Tiki, it would still be a very large influx of users.

Tiki can already look like WikiPedia:
http://themes.tikiwiki.org/Tikipedia

One important step for Tiki's future is to have a converter from MediaWiki to TikiWiki so users can have a painless upgrade path and gain access to more features.

http://dev.tikiwiki.org/MediaWiki+to+TikiWiki+converter

Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]