Loading...
 
Skip to main content

Category: Error

error message, broken, etc
A bug is something which doesn't work like it should. It is an obvious error.
This category was probably used as a fallback for bugs which did not fit other Bug subcategories before the general Bug category was created.
Error
Show subcategories objects

Name Type
Wiki Staging & Approval Does Not Work
{syntax type="tiki" editor="plain"}
Have tried a number of different fixes and environments but keep running into the same message when trying to approve a new page:

''Error: Either staging or approved page cannot be found.''

Well,that's a correct statement as it's a new page, there is no approved page yet. The function always states that the user is viewing the staging page for the approved page, even before it was approved.

For approving existing pages, the approval process works although it doesn't remove the unapproved page.

Have recreated this problem on the [http://php.opensourcecms.com/scripts/details.php?scriptid=63,|demo site], as well as a couple of Windows environments.

To recreate: create 3 categories (Staging, Approved, Out of Sync). Turn on Wiki Approval and Staging in the Wiki section. Make appropriate category selections to match categories you made. Setting: If not in the group, edit is always redirected to the staging page edit: Put the group, you are not in, so hit Anonymous. Create a wiki page, save, then when prompted try to approve it.
tracker item
Wiki strucutures show pages, even if user does not have permission to view a page
If a wiki page is included in a structure, Tiki lists the page when viewing the structure (or when listing TOC) -- even if the user does not have permission (tiki_p_view) to actually view the page. This presents an invalid structure to the use -- they are seeing pages that they do not have permission to view. Tiki should only show pages (in a structure) that you can actually view.

Alternative impelentaion (proposed by luciash):
To have an option "restricted pages in this structure will be ommited from the list" or "will be shown but marked as restricted"

Confirmed in 1.9.8 and 1.10.1
tracker item
Wiki Table-Syntax broken
Wiki syntax parsing for tables is broken

Following two things are supposed to work. These are just copied from the offered quicktags.

||r1c1|r1c2
r2c1|r2c2||

||r1c1|r1c2||r2c1|r2c2||

First one works, but the second ones ends the table at the || and then just prints the text " r2c1|r2c2|| ".

Ok, just saw that Trakcer-Items are Wiki-parsed, too. Good thing! As you can see the effect live! :)

Hmm, everything gets saved, when editing a Tracker except for the feature.... I really have to start working with them.... and search for bugs... sorry for three mails about this, if you are subscribed!
tracker item
wiki tag "file" rendering issue
Following code inserted into wiki page is causing problems.

{file name=attached_file_name}

In TikiWiki 1.9 was name of file shown with link to file. In TikiWiki 2.x only single closing bracket (i.e. '}') is shown instead.

Following wiki code gives expected result in both 1.9 and 2.x versions (please note space before closing bracket)

{file name=attached_file_name }

File tag is parsed in file lib/tikilib.php in function parse_data(). Tag file is translated to call of ATTACH wiki plugin. It seems that essential is call of split_tag() method with cleanup parameter set to FALSE (in tikilib.php revision 1.801.2.92 it's line 5474). In branch 1.9 was cleanup hardcoded to TRUE in split_tag() body. Setting cleanup to TRUE 2.x gives expected result.

I can see that optional cleanup parameter of split_tag() method was introduced in tikilib.php revision 1.602. At the same revision was cleanup value in file tag parsing section set to FALSE. Commit comment says "Minor tweak to preserve ' in {file ...} links.". I don't know idea behind it so I'm not able to correctly fix file tag rendering issue. Simple change of cleanup parameter to TRUE would probably cause regression of another bug.
tracker item
Wiki-links and non-latin characters
__problem __with Russian (and, as I understood, any non-English character language) wiki-links in CKE Editor (and plugins):
1. Let's create wiki page named "Фичи" (copy-paste, hope it'll be work)
2. Create page with any name e.g. test with wiki-link to a first page ("Фичи").
3. Link is broken. becouse on the stage of convertation from wiki-link to CKE URL something goes wrong and if You click on this link and choose "Edit Link" you'll see "tiki-index.php?page=Фичи"
3.1 Yes, link is broken:
Page not found
äøÃÂø
----
Hint: without WYSIWYG editor all will be ok. No broken links with any symbols.

__Why priority is high?__
-becouse we can't create ANY wiki-links from CKE-editor if wiki page named with non-Latin leters.

p.s.
double-checked here http://php.opensourcecms.com/scripts/details.php?scriptid=63
with WYSIWYG_6x profile.

tags: utf-8, russian, link, wiki
tracker item
wiki-plugin trackertimeline display a improper timeline compared to what's configured
I've been trying to use trackertimeline in a wiki plugin alias and I cannot tell you why when I view the result it doesnt display as intented.

example: {CODE()}{TRACKERTIMELINE(lower="2011-03-22 07:00:00",upper="2011-03-22 17:00:00",(...))}{TRACKERTIMELINE}{CODE}

(like up here, but in a wiki-plugin alias)

would display a timeline that goes from 07:00 to 17:00 correctly. BUT. The elements in it, wont display in its proper place

example: An element has a start-time of 9h00 to 12h00

So, instead of placing it properly on the timeline, it will show it +/- 3hours later.

WHAT I CHECKED
* I checked if there is timezone problem in the phpinfo()
* I made sure that every fields were linking to the right tracker fields Id
* I made sure the format was fitting
tracker item
Wiki-syntax parsing is different in lot of other places than in Wiki
You can see the effect of Wiki-syntax getting parsed differently with the ~np~ ~np~ ~/np~ tag and the~np~ {CODE()} ~/np~ -plugin.

~pp~
~np~text here~/np~ - strips all linebreaks out of "text here" - ~pp~ works

{CODE(caption=>test)}
text here and some enclosed in <these brackets> here
{CODE}

The text between the <>-brackets doesn't get shown at all.
~/pp~

Also, (just in case it's related): tiki-view_blog.php complains to admin user about a division by zero by split plugin (tiki 1.9.2):
* {CODE()}
Warning: Division by zero in /var/lib/gforge/chroot/home/groups/gclub/htdocs/lib/wiki-plugins/wikiplugin_split.php on line 74
{CODE}
* This warning message was not present with 1.9.1. (Xavi - xavidp)

The blogs were htmlspecialchar()ed, too - it looks like fixed in CVS now!
tracker item
Wiki: CODE block may not contain "$0"
When you try to create a ~np~ {CODE()} {CODE}~/np~ block in the
Wiki which contains $0 somewhere (which is, e.g., quite
common in Unix init scripts), the page won't be
displayed (white screen).

this is easily reproducable by inserting the following
into a Wiki page:
~np~{CODE()}$0 {CODE}~/np~

The bug was not present in previous versions (I
recently upgraded from 1.8.5 to 1.9.0).


And as you can see, it works correctly here in the Tracker:
{CODE()}$0 {CODE}
tracker item
WikiLingo Feature
Enabling the prefrence 'WikiLingo' causes a fatal error on tiki-index.php

{CODE(caption="lib/wiki/wikilib.php")}$scripts = self::$wikiLingoScripts = new WikiLingo\Utilities\Scripts(TikiLib::tikiUrl() . "vendor/wikilingo/wikilingo/");{CODE}

There is no wikilingo vendors package.

I was trying to merge some of the uses of zeroClipboard while I came across this. Its one of the features that uses zeroClipboard linked (currently) to our lib folder.

This is an experimental feature that causes Tiki to Crash. There is also very little documentation on how to use it in tiki.

https://doc.tiki.org/wikiLingo
https://dev.tiki.org/WikiLingo
tracker item
Wikiparser interprets tags different in editpage than in the page view
If you enter following code in a wiki-page ~np~ ...page... ~/np~ there is a bug in the interpreter. The preview-mode is working right and shows ...page... as plain text, but when you save the page wiki-parser interprets it as a tag and shows the pagenavigation-bar.
tracker item
wikiplugin List filter using a smarty variable doesn’t work when the search engine is elasticSearch
I have a Tiki22 with a smarty template that use an embedded wikiplugin list.

{CODE()}
<td>{wikiplugin _name=list}
{literal}
{filter type=trackeritem}
{filter content=3 field=tracker_id}
{filter field=tracker_field_parentsIdNumber content={/literal}{$row.parentId}{literal}}
{OUTPUT()}<a href="tel:{display name=tracker_field_parentsMobile}">{display name=tracker_field_parentsMobile}</a> <a href="tel:{display name=tracker_field_parentsMobile}"><i class="fas fa-mobile-alt text-dark"></i></a> <a href="https://wa.me/972{display name=tracker_field_parentsMobile}"><i class="fab fa-whatsapp text-success"></i></a>{OUTPUT}
{/literal}
{/wikiplugin}</td>
{CODE}

If I use mysql search engine I have the expected results.
If I switch to elasticSearch I have no result for the query.

When I rebuilt the index using the console (--log) there are no errors or warning.
{CODE()}
tsaharoniki@server001:~/public_html$ php console.php i:r -p --log
[18-10-2020 13:54] Started rebuilding index... logging to file: /tmp/Search_Indexer_elastic_tsaharoniki_console.log

Unified search
--------------

Engine: Elastic, version 7.9
59 secs/59 secs [============================] -- Rebuilding preferences index
Indexed
trackeritem: 2362
tracker: 23
trackerfield: 192
file: 1363
file gallery: 18
comment: 0
user: 43
group: 6
calendaritem: 26
calendar: 1
wiki page: 46
category: 43
Rebuilding index done
Index: tsaharoniki_main_5f8c1f0180f47

Fallback unified search
------------------------

Engine: MySQL, version 10.3.23-MariaDB-0+deb10u1
Index: index_5f8c1f20f3b21

Execution Statistics
---------------------

Execution time: 58 secs
Current Memory usage: 77.9 MiB
Memory peak usage before indexing: 19.7 MiB
Memory peak usage after indexing: 79.8 MiB
Number of queries: 232317
{CODE}

If I use the html front-end I have a 500.
{img fileId="1455" thumb="box"}
{img fileId="1456" thumb="box"}
{img fileId="1457" thumb="box"}
tracker item
wikiplugin_files used on Wiki Pages dont update files.
{syntax type="tiki" editor="plain"}
Hi,
I found an issue using "wikiplugin_files" plugin.
If You try to use it (on Wiki pages or in other available places like parsable ptracker descriptions etc) Wiki page show files in the particular gallery but You can only download file. You cannot update newer version or see a history of that file althou theres an option to do it.
Ive try it both on TW 2 and TW 3(beta).
Ive tried to turn off/on all java UI thingy but w/o success.

Best regards,
Piotr
tracker item
wikiplugin_tracker.php crashes in tracker with mirror tables
I've got this error while attempting to insert data in a tracker with mirror tables from a Wiki page through wikiplugin_tracker.php.

In fact, the wiki page return an error message, and it seems as if item was not inserted, then, but item is inserted. However, the field "user" (login user, 1) is not saved in the tracker (and I was logged in, and I could insert a tracer item from the same user account through the tracker directly).

Note: Tracker has less than 40 fields, and I included 40 consecutive field ids in the plugin syntax.

That's the code in the wiki page:
{CODE()}
{TRACKER(trackerId=>1,fields=>1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:24:25:26:27:28:29:30:31:32:33:34:35:36:37:38:39:40,action=>Name of submit button,showtitle=>y,showdesc=>y,showmandatory=>y,embedded=>y)}Ben fet!{TRACKER}
{CODE}

Thant the error message:
{QUOTE()}Notice: Undefined index: name in /var/lib/gforge/chroot/home/groups/gclub/htdocs/carpetiki/lib/wiki-plugins/wikiplugin_tracker.php on line 138

Warning: mysql error: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '='prova4' where `itemId`='5'' at line 1 in query:

update tiki_trk_1 set =? where `itemId`=?


in /var/lib/gforge/chroot/home/groups/gclub/htdocs/carpetiki/lib/tikidblib.php on line 154

Warning: fread(): Length parameter must be greater than 0. in /var/lib/gforge/chroot/home/groups/gclub/htdocs/carpetiki/lib/cache/cachelib.php on line 47
{QUOTE}
tracker item
WikiPluginTracker :: non fonctional fields
The field "User Selector", "Header" and "email", "date and time", "JSCalendar" do not work with Wiki Plugin Tracker.

This is true also for "country", "date time". (Franck)
tracker item
Wildcard itemd feature in linked trackers forgets linked id from the 2 trackers
Wildcard items feature was added in ((doc:Tii17)), using some new functionality added in "item link/items list" tracker fields.

You can see it reproduced in the show2 instance linked to this tracker item, setup with
https://profiles.tiki.org/Wildcard_items

Once you link trakcer items from tracker2 "projext tasks" with an item from tracker1 "projects" and save the item in tracker1, the pId is lost from the linked items in tracker2.

Reproduced here:
http://xavi-9794-7119.show2.tikiwiki.org/tiki-ajax_services.php?controller=tracker&action=update_item&trackerId=2&itemId=18&modal=1
u: admin
p: 12345

Once you clik at the "update" button, the numbers selected in the pID from tab 2 "2) Tasks and resources": Checklist of Project Tasks, get lost. And instead, they should be kept, and the selected items with wildcard should be converted (afair) to the pID from that item.


And when you create a new project, and select some wildcard-item project tasks from the list, after saving their pID don't get converted from wildcard to the project number (as they should), but they stay as asterisk.
tracker item
Articles, WSoD when editing an article with Hebrew characters in the Heading field
On a Tiki23 I create a first article in "en" then create a "he" translation (new article) with everything in hebrew but __nothing in the body__ (using title and header field).
On save I have a WSoD.
If I refresh the page everything is here.

If I add a body (no hebrew in it, just an image) I got a Tiki system error:
{CODE()}
System error.
חזרה הודעת שגיאה זו:

Incorrect string value: '\xD7' for column `bernardsfez_tiki23`.`tiki_objects`.`description` at row 1
The query was:

update `tiki_objects` set `description`=?,`name`=?,`href`=? where `objectId`=?
Values:

להתאים את סביבת עבודה בדיוק איך שאתה אוהב
tiki-read_article.php?articleId=66
226

{CODE}

The article is saved and visible (while something seems weird in the display)

I tried to check if they were invisible characters or some specific word or letter that cause the issue and I couldn't find.

If I take the same text and remove it form the Heading to paste it in the body, it is working as expected.
---

It couldn't be reproduced on the show instance so I checked my database setting.

In my (Virtualmin) configuration file (my.cnf) I added :
{CODE()}
[client]
default-character-set=utf8mb4

[mysql]
default-character-set=utf8mb4
{CODE}

MariaDB System Variables look good:
{CODE()}
character_set_client utf8mb4
character_set_connection utf8mb4
character_set_database utf8mb4
character_set_filesystem binary
character_set_results utf8mb4
character_set_server utf8mb4
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/
check_constraint_checks ON
collation_connection utf8mb4_general_ci
collation_database utf8mb4_general_ci
collation_server utf8mb4_general_ci
{CODE}

tracker item
Deleting an archived file using a selection of file doesn’t work anymore
At tiki-file_archives.php?fileId=n when you select several or one archived file and try to delete it using the bottom action selector nothing happen.

Work fine if you delete one file using the "delete" action button action under the wrench menu.
tracker item
File gallery; File description cannot be emptied once it have been filed with a value
On Tiki24 on file gallery => edit properties you can add a description to a file.
If you come back and remove it, it will stay... forever ! ??‍♂️

http://bsfez-11581-8072.show2.tikiwiki.org/tiki-list_file_gallery.php?galleryId=1

Tested with 2 files.
Try to edit/remove save the description.
tracker item
WIP: Filter by group option for a userselector field hide some users if your are not admin
...

Couldn’t reproduce
tracker item
WIP: Global action on tracker item list is not working anymore
On a tracker if you don’t use the "Status" display option you cannot use the "Delete" action at the bottom of the tracker item list.

Curiously, if I enable the status display option I can delete __once__ items using the "Delete" action but then it is broken again.
tracker item
Prevent special characters in page names is not effective when using using multilingual
On a multilingual Tiki 22 with "Prevent special characters in page names" enabled and "Wiki link format" set to relaxed. (multilingual is important factor here, it is because you have many languages with accent or non-latin characters)

This is working ((Tiki and Virtualmin interop))
This is not working ((Tiki, Virtualmin intérop and more and m’ore and זה או זה))
''On dev "Wiki link format" is set to complete" so it is correctly displayed'' ?

{img fileId="1470" thumb="box"}
{img fileId="1471" thumb="box"}

Having a comma or a quote in the title of a page will break future usage of the page name as link. (wiki link)
The user has no warning about this and it gives a very bad user experience.

# Warning on edit/rebname
When renaming or naming (edit) a page the editor should be warned: "you are about to save this name for the page and it contains xxxx those character(s) may forbid..."
# Warning on using wiki link syntax
It should be forbidden (or at least a warning) for an editor to create a wiki link in a page that contain such characters to prevent breakeage and bad user experience.
tracker item
wiki-admin_modules.jpg
Screenshot of MYSQL bug #1 in admin_modules submitted by Russ.
image
wiki-new-user.jpg
Screenshot of MYSQL bug in admin_users submitted by Russ.
image
"internal link" button doesn't work -- "local.php not found"
the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found — This is normal if you have not run the tiki installer yet".


(but i run the tiki installer)
tracker item
"Mandatory category in the categ. tree" nullifies category list in wiki edit page
When I select "Admin > Wiki > Mandatory category in the category tree", the list of categories while editting a wiki page is blank, or it says no category is defined. However, if you click on "admin categories", they are defined indeed.

When you unselect this check box, and clean caches, categ. list is working fine again.

This is not a theme specific issue (reproduced with geo.css, tikineat.css, lesjetesdelencre.css, ...)

----
update: sylvieg fixed that months ago, I think. (thanks sylvie)
tracker item
Show PHP error messages