Category: 18.x

{syntax type="tiki" editor="plain"}
((doc:Together)) works for tracker items. No reason for it not to work for wiki pages

Let's coordinate ((Together|here))

When you have backlinks to calendar events enabled, a wiki page that gets linked to from a calendar event that has a repetition rule, the wiki page's backlinks list ALL instances of the calendar event, which can be up to 99 !

At this point of course the real culprit is the inability of Calendar to actually have (and admin) repetition rules. What calendar does in reality is that it creates "n" copies of the event, which is a nuisance.

And due to a bug in calendar, entering an event with a repetition rule is always created twice, so you have to manually delete one after the creation.

If a user is trying to use Mail-in and is not authorised to he will get an error message:
~pp~Mail-in auto-reply

Sorry, you can't use this feature. ~/pp~

This is good, but he will received the same message on and on and that may/will trigger the SPAM mechanism. It will classified or at list highly raised the possibility to have the domain used by the Tiki classified as SPAM.

The logic of the toolbar editor is somewhat confusing. But beyond that, there is function that is broken: Once you dragged a tool like superscript or subscript to the custom tools column (i.e. from the middle to the right), you cannot delete it. The description says, that dragging it back from the right to the middle would delete it, but it doesn't. You can click on the tool, then at the bottom you have a button labelled "delete". When you click that, you are asked "Do you want to delete?", and when you confirm with Ok, the custom tool is NOT deleted. And no error message. And it is (IMHO) no problem of permissions, because it also happens when you're admin.

At the bottom of the toolbar editor in the TEXT there is a link to delete the entirety of custom tools. That works, so this is kind of a workaround, but not a good one.

Also, but this is more of a feature request: IMHO dragging tools to the custom column should preset some of the entries like the icon and others. Custom tools do not have the proper icons, and there is no intuitive way to give them the correct icon once they are lost.

Thanks for your support
Hman

section_comments_parse does turn off wikisyntax in the comments, however, the editwiki_toolbar is still present

Please take a look at the attached screenshot:

The field list of this tracker (tiki-admin_tracker_fields.php?trackerId=2) is obviously not sorted by ID (which would be the logical sorting criterion).

There is not, like in MS Excel, an option to select by which column sorting shall take place (which could be the culprit). A look at the DB also gave no clue where this could come from. All records for fields look regular (tiki_tracker_fields).

Btw, tiki_tracker_fields is set to auto increment, which yields another effect, that re-importing exported fields into "gap" created by field deletion cannot fill gaps, but gets new IDs that start at the very end. Therefore I created this one from scratch so that all IDs nicely start with 10 (this is because there are 10 IDs in tracker #1).

The auto increment value of tiki_tracker_field is also correctly set to be 1 above the highest ID recorded.

And, before anyone asks, yes, in the properties of the tracker sorting is set to "by ID" and "ascending"...! I did check whether this is still set up like that, and it is...

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

On a tracker, when using the tracker field text prepend it works fine using the plugin tracker and trackerlist but not when using the plugin list.

Without using format=trackerrender the content for prepend or append doesn’t display in the plugin list.
IE : 16

Using format=trackerrender it will show the html code.
IE: 16~~#090:<span class="formunit">hr</span>~~

Using format=trackerrender and mode=raw it will show properly the append and prepend.
IE: 16~~#090:hr~~

But the content for prepend and append is displayed with the default value.
IE: NA~~#090:hr~~ (NA is the default value).

Tracker field text-area flow over the field name if using wysiwyg and same row=no in a tracker plugin.

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

There is an instance to check it:
http://bsfez-11581-6093.show.tikiwiki.org/tiki-index.php

At https://tiki.org/Contact-Us we have 2 fields with a regex validation.

__Subject__ that is a text field where validation using a regex code is working.

__Feedback__ that is a textarea using the same regex code (I know carriage return is missing I use the same pattern for comparison purpose) is not working even if entering a single english word.

An empty message error (orange background) is displayed and I can’t submit the form.
I removed it in the validation for now of course.

__To reproduce:__ Go to https://tiki.org/tracker24, fields, edit Subject field.
Copy regex pattern and set the same parameters to the Feedback field.
Go to https://tiki.org/Contact-Us try...

Tracker fields textarea content wiki parsing doesn't work the same as wiki page content parsing when using a page as a Smarty template with the ''wiki'' Smarty block. For example consider we have a textarea field and this wiki syntax in the page named "User Profile TPL":
{CODE()}{wiki}{$f_358}{/wiki}{CODE}

The code above indicates we want the field value to be wiki parsed using the Smarty wiki block.

This is the code to reproduce using PluginTrackerlist (I know it is not PluginList ;-) ... but the wiki parsing should behave everywhere in Tiki the same no matter what you prefer to use):
{CODE()}{trackerlist trackerId=38 list_mode=csv view=user wiki="User Profile TPL"}{CODE}

__The input:__
{CODE()}Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit "amet libero" vitae turpis mattis eleifend.

* meh 50%
* 123
* blah blah

Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.{CODE}

__The expected result:__
{HTML()}<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit "amet libero" vitae turpis mattis eleifend.</p>
<ul>
<li>meh 50%
<li>123
<li>blah blah
</ul>
<p>Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.</p>{HTML}

__The actual result:__
{HTML()}<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In quis orci ante. Aliquam sit """"amet libero"""" vitae turpis mattis eleifend.<br /><br />* meh 50<br />%* 123<br />* blah blah<br /><br />Maecenas sodales felis sed magna cursus, eu ultrices metus scelerisque. Vivamus viverra ipsum aliquet commodo mollis.{HTML}

__Reproduced on the show instance__: http://luci-199-7045.show.tikiwiki.org/
(use show:show as user:password and for admin login use admin:12345 to play with it)

Hello folks,

I found out a strange behaviour at least for .pdf files:

I use a Tracker with a field of type "files" to provide a "file-pool" respectively a download area for an npo's member are - Tiki 18.0 alpha. On another site with Tiki 17 the error does not appear.
File gallery is set to store in directory on both sites.

__When a user tries to upload a file of any size that was ===either created on a Mac or that was sent from a Mac=== by email (so has been stored/saved on a Mac), it is not possible to upload to Tiki via the files field.__

Error: Upload impossible. There are restrictions.
(translated)

The same file __can be uploaded via the file gallery__ - but then it does not appear in the tracker.

{QUOTE(replyto="jonnyb")}
Jonny in IRC at 26 March 2018:
"4:57:20 PM - jonnyb: althugh the error looks like one i exposed recently in 18.x - before when it errored it just removed the tracker item edit modal so you lost all your changes an so i fixed that, but i should not have introduced any new errors - maybe the file is too big, or doesn 't meet the mime type or somthing? check the extension is .pdf etc, maybe it's something like that?"
{QUOTE}

When I recreate the file (I use Ubuntu 14.04), by importing to a software and save as new file or I split and remerge it with pdfSAM, __the newly ===recreated=== file can be uploaded__ via the tracker field files.

It is not enough to simply save a copy from the .pdf viewer, but it must be really created new. pdfSAM is a workaround for multipage files, but not sufficient for a growing amount of files.

As I am stubborn in the npos where I am engaged, that we need OS independend solutions, not excluding for ex Linux users, I cannot expect from Mac users to not being able to use the Tracker field of type files and even not be able to privide files to the teams.

I am wondering why this occurs, cause afaik the main developer of this field type is a Mac user himself -Jonny, right assumtion ;-) ?

Please help or comment.

If no quick fix possible, I'll post a bugreport including this description later on today.

Thx for help and considerations.
Torsten

Hi,

Since Tiki 15x (so since Bootstrap) tracker field type Multiselect with the parameter 'Input type: List box':

*displays an unusually tiny box
*uses a very small font to display the text in the box
*only displays one row of options (no options to choose how many rows to display)

Here is a pic of what it looks like:
{img fileId="1239" thumb="box"}

This renders the multislect field unusable in 'List box' format (or very difficult to work with in the best case scenario).

Has anyone experienced this?

Thanks,
Mike

__UPDATE, Oct. 16, 2018 / 19:12__
I created a Show Instance with two examples (on Home Page, login/pass: admin / admin54321)
*the top example contains simply Smarty code in the Wiki page template

*the second example is Smarty inside a Fancy Table on teh Wiki page template

So it looks like the problem only occurs in the second instance.
Any way for Multiselect to show properly in a Fancy Table via a wiki page template?

I set the tracker plugin with transaction step.
So I split the initial plugin tracker into 5 plugin trackers setting the following parameters for each one: transactionName, transactionStep and transactionFinalStep.
Something that looked like:

{CODE()}{TRACKER(trackerId="4" fields="1:2:3" transactionName="new" transactionStep="0" transactionFinalStep="n")}{TRACKER}{CODE}

{CODE()}{TRACKER(trackerId="4" fields="4:5:6" transactionName="new" transactionStep="1" transactionFinalStep="n")}{TRACKER}{CODE}

…/… till the last step a bit different.

{CODE()}{TRACKER(trackerId="4" fields="10:11:12" action="Save" transactionName="new" transactionStep="4" transactionFinalStep="y")}Thanks{TRACKER}{CODE}

The page show an error : You need to define both transaction name and transaction step, or none of the two.

It has been confirmed that it is not working

Each tracker can have 1 title field. When an item of that tracker is listed, the value of that field can link to tiki-view_tracker_item.php. When listing with the TRACKERLIST plugin, the showlinks parameter controls this behavior.

As can be seen in Tracker_Field_Abstract::renderOutput(), this works by surrounding the return value of renderInnerOutput() with opening and closing HTML a element tags.

While this works for simple field types, this is highly unreliable when rendering a textarea field which is wiki-parsed. If the parse generates a link, the result is invalid HTML.

For example, if tracker 1 contains a single Textarea field, and a single item with value "foo\n!!! title
", calling the plugin with "~np~{trackerlist trackerId="1" showlinks="y"}~/np~" will cause the field to show as a link only on the first line ("foo"), at least in Google Chrome, since a header inside a link is invalid. I am not sure why, but if listing the items from tiki-view_tracker.php?trackerId=1 instead, the link only stops between the second and third lines (i.e. the title itself links).

This issue has probably been there from the time TRACKERLIST was written (r3627). If not, it must have been in r33456 (see renderValue() in https://sourceforge.net/p/tikiwiki/code/33456/tree/trunk/lib/trackers/trackerlib.php ).

For a project with requirements that are too complex for Tiki-Calendar, I use the TrackerCalendar plugin. One of the problems I'm struggling with is the handling of timezones. I am running two Tiki installations on the same server. Both with Tiki version 18.3 and PHP version 7.1.28, but with different MySQL settings. For both systems Search engine Lucent was active and timevalues were displayed correctly. On both systems I changed to MySQL full text search; clear all Caches; rebuild search index; clear all Caches again.

Now system 1 still shows timevalues correctly in TrackerCalendar plugin. System 1 is running on MySql 5.5 with InnoDb.

But system 2 shows UTC values. System 2 is running on MySql 5.7 with MyISAM.

I tested today the plugin helper ui to select fields in plugin trackerlist, but I had no way to get my typing stored/saved in the page for the "fields" param: numbers got lost when clicking elsewhere, and text (field names) didn't make any matxh in the dropdown.
This used to work with no problems in the past (Tiki15 LTS at least).
Editing by hand in the wiki textarea (aside of the plugin popup helper ui) worked as expected for the param "fields" in plugin trackerlist, but new users got confused aboput why that text input/dropdown for "fields" in plugin trackerlist didn't work in the popup helper.

In the properties of a tracker, there is a multiselection where you can select which fields get displayed in a pop-up, when the mouse pointer is over a record.

That list of field isn't updated properly. That is, it gets updated when you add new fields to the tracker. But fields do not get removed when a field gets deleted. This leads to the list being cluttered with old info if you delete and add fields...

There is a typo in /lib/prefs/short.php which makes displaying the help texts impossible, and it is carried on (through copy&paste by the dev).

Look at these code snippets:
{CODE(Colors="Tiki")}
function prefs_short_list()
{
return [
'short_date_format' => [
'name' => tra('Short date format'),
'descriprion' => tra('Specify how Tiki displays the date (shorter version)'),
.....
'descriprion' => tra('Specify how Tiki displays the time (shorter version)'),
{CODE}

The error is in lines 13 and 23: "descprion" should read "description"... This results in help texts that contain a heading (contained in 'name'), but no text...

This affects ''all'' languages, including English...

In the update wizard /templates/wizard/upgrade_others.tpl there is this:
{CODE(Colors="Tiki")}
{tr}You can prevent that unresponsive time by means of setting Tiki to store notification emails in an email queue (see <strong>Settings > Control Panels > General > General Preferences > Mail > Mail sender > STMP</strong>, and <strong>Mail Delivery > Queue</strong>), and request the server to process the email sending based on a cron job{/tr}.
{CODE}
Of course that should be SMTP :-)

Because I keep finding bugs where translation is impossible due to missing tra(), tr() or tr in curly braces, I opened this new umbrella bug report.

Here I will add only newly found bugs, I will not integrate the already existing bug reports into this!

/lib/prefs/calendar.php has this on line 78:

{CODE(Colors="Tiki")}
'description' => 'Interval to show between minutes on time selectors',
{CODE}

Without tra(), the description cannot be translated into any language...

Show.tiki.org is not configured properly

The public/private keys configured to connect to show.tiki.org were not accepted. Please make sure you are using RSA keys. Thanks.

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

Using the native Geolocation feature for Articles, Wiki Pages, Blogs, etc, once a geolocation is assigned, using edit properties, you can change the location, but you cannot detach a location. Sometimes, a location may be accidentally added, but one should not be a part of that page.

In my case, I have wiki page templates, I accidentally assigned that template a location, and now the template shows up on my map. There is no way to detach the geolocation from a page, article or blog.

Tried to create a Show Instance, but it's not working.

I'm unable to reply or post to comments to my tracker items with some default Linux browsers, such as __Chromium__ or __SeaMonkey__ (default in [http://www.lxle.net/|LXLE]) internet browsers (fine with Firefox)

Reproduced here with user "xavi" (with no admin rights, in case it matters):
https://dev.tiki.org/tiki-view_tracker_item.php?itemId=6689&threadId=6491&cookietab=1

It would be good to make the 'User' (i.e. user name) a required field when adding a new Tiki User (Admin Users)

Recently, I tested adding a new user without this (left blank), but added the password (2x) and an email. Tiki went the the next step, 'Confirm adding new user', then went to the full user list. Of course it was not visible anywhere in the full list of users (only one page, under 10 users total).

Also, it might make sense to change the name from 'user' to 'user name', or even more direct 'login'.

br,
Mike