Category: Consistency

When codemirror is on and its default mode is set to "Off (but switchable)", the end user expects to see a button available in tracker item textareas (like in dev.t.o/t5 bug tracker).

But it's not available still.

To see it reproduced:
Log in here:
http://xavi-9794-5064.show.tikiwiki.org/tiki-index.php?page=Contact_us&itemId=1
u: admin
p: 12345

Codemirror has been set to on (with default theme). If you edit the "Contact_us" page you'll see the content highlighted.
However, no highlighting in the tracker text area field.

Maybe the best option would be to allow the tracker admin to set an option for text areas to include the button to toggle the "highlighter" upon user request (as with text areas in wiki pages).
This way, codemirror could be set to "Disabled but switchable" (default preference in new installs), and each user could decide whether to enalbe highlighting in that text area or not (to prevent side issues in some cases with codemirror on, from happening always in all text areas, etc)

In 18.x (and probably earlier) you can print the table of contents on the fly in the pdf produced by mpdf (at pdf generation time), regardless of using hardcoded maketoc calls, o hardcoded title calls with wiki argument variable -+{ { page } }+- (no space intended between angle brackets).

^ Preference: Control Panels > Print > mPDF > __Table of contents__ ^

This feature is nice, but if would deserve another minor level of integration, for those cases in which:
# the Wiki page title is hidden by default, and placed by hand in the wiki page where needed (or replaced by human-(more-)readable text), usually at the top with a heading 1 level style.
** current behavior: mpdf places the table of contents at the top, and page title is shown below the table of contents, which is counter intuitive
# A wiki page has the AutoTOC setting disabled at wiki page level, and a hardcoded call to __~np~{maketoc}~/np~__ is placed below the page title (or wherever, with whichever maketoc params for the users like, such as levels="2,3", my favourite, btw).
** current behavior: mpdf keeps the table of contents produced by itself, plus the table of contents that was previously generated in the rendered html page by the wiki markup). therefore, 2 table of contents are shown, which is not what most users would expect.

Potential solution to both issues: (2 birdies in one shot)
__Allow replacing hardcoded call to maketoc in page with the one produced by mpdf__

How? Brainstorm mode on:
* add a new param -+inpdf+- in maketoc plugin, with several values:
** __replace__: -+~np~{maketoc inpdf=replace}~/np~+- Replace that maketoc call in the wiki textarea with the output of the table of contents from mpdf
** __keep__: -+~np~{maketoc inpdf=keep}~/np~+- keep same behavior as nowadays, for those edge cases in which user has custom maketoc for partial sections of the page (or whatever), which want printed also besides the full table of contents at the beginning, etc.
** __ignore__: -+~np~{maketoc inpdf=ignore}~/np~+- ignore the maketoc call when creating the pdf, so that the only maketoc is the one produced by mpdf at the beginning (for cases with wiki page created by Tiki itself, etc, so that placement of the maketoc from mpdf is the expected one, etc)

Opinions?

Current feature Profiles in the Control Panels in Tiki searches profile names by category filters (15.x, etc).

Most profiles in profiles.t.o were reviewed in the last years and the suitable ones were added to the ((Profiles Wizard)), in most cases, and added tags to them to facilitate the discovery of profiles that will let you learn how to master feature X or Y that you might be more interested in (e.g., trackers in general, plugin listexecute, spreadsheets, tracker field itemlink, mathematical calculation field, staging and approval, etc).

Searching profiles from within Tiki by tags (folksonomy-based search) is not yet possible. The interface is ready to search by categories (top-down approach, if the naming of the profile doesn't match your expectations, you will miss it probably). "Who knows that Barter_Market will let you practice with itemslist tracker fields? or which profiles will let you learch how to use maps with tracker items? or with convene plugin? or with listexecute plugin? etc.

We currently allow the profiles control panel to search by profile name filtering by category matching the corresponding tiki version. __We should allow that profiles control panel (and /or the Profiles Wizard interface!) to search by tag name while filtering by the same category corresponding to the corresponding tiki version.__

https://profiles.tiki.org/tiki-browse_freetags.php?tag=listexecute&category=18.x ...

I tried once, but my php skills were not high enough, and didn't get the desired result.
Anyone willing to give it a go? (it shouldn't be that difficult for a senior dev, I reckon)

{syntax type="tiki" editor="plain"}
On the top of tiki-admin_forums.php is the button "List forums" which should send the admin to the forum list at the bottom of the page (as I guess). But with firefox 2/3 it makes just a reload of the page.

I wonder why I haven't seen this before. But now I see a CSS problem with the already bug-ridden calendar feature:

When you click on an event, to view it, on my site the classic 3-container layout produces an obscure error: The right module zone "jumps" to below (!) the center, the content zone...

It is kind of similar to the complete breakup of the layout when I test-migrate the test instance of the site to 21.x, but with one significant difference: When the layout breaks down upon upgrade to 21.x, the right modulezone is on the left, in between the left module zone (which remains left) and the center content zone. And on upgrade, the entire layout shows this behaviour, on every page of the Tiki.

HERE this happens ONLY when viewing a specific calendar event. It does not happen anywhere else in Tiki. It also does not happen when viewing the calendar as a whole, only when viewing an event...

So this is obviously a CSS issue. This is with a customized version of Geo, written by Gary. I have to try if it also happens on non-customized, original Geo.

Thanks

The subject says it all.

Cannot demonstrate 9.x on show.tiki.org anymore. Demonstrated 12.x where it seems to be fixed but 9.x is still LTS so should be fixed there too, right ?

Any registed user can use "Switch User".

I think this is very important, because everybody is able to be admin. :-(

Or can i dit a Misconfiguration? I dont think so.

---

today i see, everybody IS admin! (but i don't assign admin-perms to these users)

---

I found the Problem:

if i have tiki_p_search-permission so i have all "tiki"-perms too :-(

- How can i configure a group (or all users / anonymous) that they can use "search" (most important function of a wiki, i think) whithout make them admin?

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)

{img fileId="452"}

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!

Tiki Articles do not support the FOOTNOTEAREA plugin. In Tiki 5 and 6 I used:
{CODE()}
foo bar {FOOTNOTE()}http://www.foo.bar{FOOTNOTE}
---
{FOOTNOTEAREA() /}
{CODE}

Tiki renders the footnote (superscript) properly, but does not include a Footnote area at the bottom of the article.

Tested & confirmed on info.tw.o using Tiki 5 and 6

If you have an article listing on your front page, and you create a "breakout" page with older articles, you want to skip those that have already been presented on the front page. In order to achieve this, you can instruct the plugin to skip a number of articles (or a period). But this does not work together with pagination...

{CODE(Colors="Tiki")}
{articles max="6" topicId="2" largefirstimage="y" actions="n" title="News" quiet periodQuantity=3 start=5 periodUnit="week" more=y}
{CODE}

would be the code to display articles older than 5 weeks. And this works. But displays only 6 articles (as instructed). Once you add

{CODE(Colors="Tiki")}
usePagination="y"
{CODE}

The articles plugin no longer skips older news, but starts with the very same, newest article like to front page does... It does paginate, but it starts at the wrong article...

AutoToc:
{CODE()}http://dev.tiki.org/How+to+release#8.__Dogfood_release_policy{CODE}

MakeToc
{CODE()}http://dev.tiki.org/How+to+release#Dogfood_release_policy{CODE}

The MakeTOC URL is much better because URL doesn't change when sections change numbers

Also, the double underscore causes an issue in links

http://dev.tiki.org/Calendar
{img fileId="507"}

http://dev.tiki.org/BigBlueButton
{img fileId="508"}

http://dev.tiki.org/Group
{img fileId="509"}

http://dev.tiki.org/Social+Networking
{img fileId="510"}

http://dev.tiki.org/Endangered+features
{img fileId="514"}

Also:
http://dev.tiki.org/Web-based+source+code+editor
http://dev.tiki.org/Accessibility

{syntax type="tiki" editor="plain"}
In view mode:

PluginCODE should have horizontal scroll bar when there is too much code on one line. This used to work a while ago on some browsers, but not all.


In edit mode:
CodeMirror seems to force the page to be super large

In /lib/prefs/feature.php is a help string that does not work in English __and__ makes life of translators hard, because it is badly escaped (actually, not at all):
In line 550 you will find:

{CODE(Colors="Tiki")}
'feature_comments_send_author_name' => [
'name' => tra('Add author name in From email header'),
'description' => tra('Add the name of the comment author in the email header "From", making the email look like sent from "John Doe <noreply@example.com>"'),
'help' => 'Comments',
'type' => 'flag',
'default' => 'n',
'tags' => ['basic'],
],
{CODE}

The problem is the mock sender's mail address contained in braces. It IS the notation most mail clients use, real name and address in less than and greater than signs. But tra() seems to be unable to handle this. Possibly tra() interprets it as HTML entity (?) and discards it, so output of this description stops after John Doe. The address is omitted, as well as the closing quote sign.

And for translators this is hard, because if you add the string that is displayed to your custom.php, the pattern matching won't find it.

I have a 3.3 Tiki Application with a File Gallery configured to store files in the MySQL database. It IS possible to upload zip files and unzip them during the upload. Very useful!

I'm testing a 4.0 instance of the same application, and now the "batch upload" feature does not upload and unzip *.zip files.

I noticed the following comment in the Tiki docs....

~~#f00:"Note that you can use the Batch uploads only when you don't use the database to store the content of the files!"~~

Was some functionality taken away?! I sure miss it.

If I change to storing files in a directory (instead of the DB),
will that also mean the loss of full-text search capabilities?

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?

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.

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.

Verified in the latest 17.1.7 release. Could not get demo site or show instances to run so not sure there. Verified still in SVN trunk and on branch 18.x (in file tiki.sql)

The menu item "File Galleries" and its first entry "List File Galleries" does not SEF URL rewrite to "files". Using the SEF "files" does not work either.

It appears the tiki.sql file, in line 3335, has the entry for SEFURL rewrite of "files" set to 'tike-file_galleries.php' which no longer exists. The menu entry simply has 'tiki-list_file_gallery.php' without any parameter; which is what seems to work and is what the URL appears as when listing all user galleries. Just changing the table entry in the DB of an active system does get the SEF URL output rewrite to work (so the the /files appears instead of the PHP file reference). After making the change in the DB table, selecting via the menu errors back to the site HomePage (or similar) so likely something else needs to be fixed; not just the table entry (and tiki.sql entry). Checked the secDB menu tables and the template files; all seemed already changed as well (from what my naive eyes to the code can see).

Longer term, especially since image galleries are deprecated, would be nice to change the SEF URL rewrite for the general galleries page to something more recognizable than "files". Especially since hierarchical galleries are allowed. Maybe "dirs", "directories", "folders", or "galleries" (if really gone) is appropriate. But I guess I should submit a "wish" instead of cluttering up this focused bug report :)

(note: ShowTiki still not working. Get error on startup of missing third party extensions)

{img fileId="905"}

When you click on the browse button/link in the file gallery, a new window opens and that is it, it displays the same as the normal page. No preview, images or what ever

On Tiki 18 and 19

On Trackers when you insert a tracker field type file you can (have to?) select a gallery for your files. It is the gallery where files you upload using this field will be saved. You have also an option to "browse" if you want the user to be able to select a file from your files gallery.

When editing an item you can then browse a gallery but the modal show ALL the files in the complete files gallery. It should show (by default or restricted) the files from the selected gallery.

One of the wizards displays one particular bubble help beginning WAY off the browser window, that is Random Header Images on /templates/wizard/profiles_useful_micro_confs.tpl. It starts a couple of hundred pixels outside the browser window, which means that all lines start with invisible (!) sentence beginnings... This is so far the only bubble help that starts off-screen, the others behave normally.