Category: 18.x

We use the code plugin with the Full WYSIWYG editor to display code snippets.
- Support Tiki's "wiki syntax" is checked
- Limited wiki parsing is unchecked
- Use Wiki syntax in WYSIWYG is unchecked
(in order to create true html wiki pages with some wiki syntax for plugins)

Steps to reproduce:
* Use code button in WYSIWYG editor, put some code in the body section and click save
{CODE(caption="Original code snippet" theme="default")}#include <iostream>
using namespace std;

int main()
{
cout << "Hello, World!";
return 0;
}{CODE}
* Clicking again on the plugin (or saving the page and view) will give you this distorted code snippet:
{CODE(caption="Code snippet after first save" theme="default")}#include &lt;iostream&gt;<br>using namespace std;int main() <br>{<br>    cout &lt;&lt; "Hello, World!";<br>    return 0;<br>}{CODE}
* Paste again the code snippet in the plugin and click save
* Code is displayed correctly
{CODE(caption="Code snippet after second save" theme="default")}#include &lt;iostream&gt;
using namespace std;

int main()
{
cout &lt;&lt; &quot;Hello, World!&quot;;
return 0;
}{CODE}

As the workaround is simple but annoying, I suppose this is quite easy to fix, is there someone who can check this out?

When you enter comments in wiki page sources, they should not get rendered.
https://doc.tiki.org/Wiki-Syntax-Text explicitly states that:

{CODE(Colors="Tiki")}
~tc~ this is a tiki comment ~/tc~
Will be kept in the Wiki source file but not seen when the HTML page is generated or HTML page source is viewed
{CODE}

But actually, everything between the two tilde tc tilde marks ''is'' being rendered... Nasty if you want to "comment out" a feature you only want to temporarily disable and not delete it's coding...

The listing of rules in the community control panel uses illogical icons. When you activate a rule, the icon changes to red, if you deactivate it, it turns green.

Quote from the page display's HTML source of /tiki-ajax_services.php?controller=managestream&action=list, "before and after", In both lines you see the logical contradiction in terms.
{CODE(Colors="Tiki")}
<span class="text-success tips" title=":Aktiviert"><span class="icon icon-toggle-on delete" ><img src="img/icons/delete.png" alt="toggle-on"></span></span>
{CODE}
and
{CODE(Colors="Tiki")}
<span class="tips" title=":Deaktiviert"><span class="icon icon-toggle-off accept" ><img src="img/icons/accept.png" alt="toggle-off"></span></span>
{CODE}

Once MediAlchemyst will be in Tiki18, we can add something like https://packagist.org/packages/caxy/php-htmldiff to compare the evolution of a file


See also: ((History)) for some potential code we could re-use

In /lib/prefs/paymen.php is a completely wrong description for a feature (AnonShopperProfile), and it's obviously a copy&paste-error. In 390 you will find
{CODE(Colors="Tiki")}
'payment_cart_anonorderitems_profile' => [
'name' => tra('Anonymous order item profile'),
'description' => tra('Wiki page containing the profile for creating order items for anonymous users (page name must not have spaces)'),
'help' => 'AnonOrderItemProfile',
'type' => 'text',
'default' => '',
],
'payment_cart_anonshopper_profile' => [
'name' => tra('Anonymous shopper info profile'),
'description' => tra('Wiki page containing the profile for creating order items for anonymous users (page name must not have spaces)'),
'help' => 'AnonShopperProfile',
'type' => 'text',
'default' => '',
],
{CODE}

The description of AnonShopperProfile is an exact duplicate of the description of AnonOrderItemProfile...

When importing a CSV from command line:
console.php tracker:import ''format_number'' ''file_name''
... tabular format "import updates" checkbox has no effect.

As far as I understand structure configuration is not being loaded in TrackerImportCommand.php

I've added the following line and everything seems to work:

{CODE(theme="default")}$schema = new \Tracker\Tabular\Schema($tracker);
$schema->loadFormatDescriptor($info['format_descriptor']);
$schema->loadFilterDescriptor($info['filter_descriptor']);
// Added line
$schema->loadConfig($info['config']);

$schema->validate();{CODE}


Please, let me know if there is a better way to solve this issue.

Thanks,

Javier.-

Runing a command like this
{CODE(colors="shell")}
php console.php list:execute "Foo page" "Bar Action"
{CODE}

produced these report with warnings:

{CODE()}
PHP Stack trace:
PHP 1. {main}() /var/www/tiki18farm/console.php:0
PHP 2. Tiki\Command\Application->run() /var/www/tiki18farm/console.php:80
PHP 3. Tiki\Command\Application->doRun() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Application.php:148
PHP 4. Tiki\Command\Application->doRunCommand() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Application.php:248
PHP 5. Tiki\Command\ListExecuteCommand->run() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Application.php:946
PHP 6. Tiki\Command\ListExecuteCommand->execute() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Command/Command.php:252
PHP 7. ParserLib->parse_data() /var/www/tiki18farm/lib/core/Tiki/Command/ListExecuteCommand.php:68
PHP 8. ParserLib->parse_first() /var/www/tiki18farm/lib/parser/parserlib.php:1667
PHP 9. ParserLib->plugin_execute() /var/www/tiki18farm/lib/parser/parserlib.php:439
PHP 10. wikiplugin_listexecute() /var/www/tiki18farm/lib/parser/parserlib.php:1031
PHP 11. Search_Action_Sequence->execute() /var/www/tiki18farm/lib/wiki-plugins/wikiplugin_listexecute.php:172
PHP 12. Search_Action_ActionStep->execute() /var/www/tiki18farm/lib/core/Search/Action/Sequence.php:56
PHP 13. Search_Action_TrackerItemModify->execute() /var/www/tiki18farm/lib/core/Search/Action/ActionStep.php:64
PHP 14. Search_Action_TrackerItemModify->executeOnItem() /var/www/tiki18farm/lib/core/Search/Action/TrackerItemModify.php:86
PHP 15. Services_Tracker_Utilities->updateItem() /var/www/tiki18farm/lib/core/Search/Action/TrackerItemModify.php:138
PHP 16. Services_Tracker_Utilities->replaceItem() /var/www/tiki18farm/lib/core/Services/Tracker/Utilities.php:24
PHP 17. TrackerLib->replace_item() /var/www/tiki18farm/lib/core/Services/Tracker/Utilities.php:98
PHP 18. Tiki_Event_Manager->trigger() /var/www/tiki18farm/lib/trackers/trackerlib.php:2116
PHP 19. Tiki_Event_Manager->internalTrigger() /var/www/tiki18farm/lib/core/Tiki/Event/Manager.php:66
PHP 20. Tiki_Event_Chain->__invoke() /var/www/tiki18farm/lib/core/Tiki/Event/Manager.php:82
PHP 21. Tiki_Event_Manager->internalTrigger() /var/www/tiki18farm/lib/core/Tiki/Event/Chain.php:21
PHP 22. Tiki_Event_Lib->__invoke() /var/www/tiki18farm/lib/core/Tiki/Event/Manager.php:82
PHP 23. TrackerLib->send_replace_item_notifications() /var/www/tiki18farm/lib/core/Tiki/Event/Lib.php:26
PHP 24. TikiMail->send() /var/www/tiki18farm/lib/trackers/trackerlib.php:5268
PHP 25. tiki_send_email() /var/www/tiki18farm/lib/webmail/tikimaillib.php:246
PHP 26. Zend\Mail\Transport\Sendmail->send() /var/www/tiki18farm/lib/mail/maillib.php:185
PHP 27. Zend\Mail\Transport\Sendmail->prepareHeaders() /var/www/tiki18farm/vendor_bundled/vendor/zendframework/zend-mail/src/Transport/Sendmail.php:125
PHP 28. Zend\Mail\Headers->toString() /var/www/tiki18farm/vendor_bundled/vendor/zendframework/zend-mail/src/Transport/Sendmail.php:237
PHP 29. Zend\Mail\Header\From->toString() /var/www/tiki18farm/vendor_bundled/vendor/zendframework/zend-mail/src/Headers.php:426
PHP 30. Zend\Mail\Header\From->getFieldValue() /var/www/tiki18farm/vendor_bundled/vendor/zendframework/zend-mail/src/Header/AbstractAddressList.php:191
PHP 31. Zend\Mail\Header\From->idnToAscii() /var/www/tiki18farm/vendor_bundled/vendor/zendframework/zend-mail/src/Header/AbstractAddressList.php:132
PHP 32. idn_to_ascii() /var/www/tiki18farm/vendor_bundled/vendor/zendframework/zend-mail/src/Header/AbstractAddressList.php:105
PHP Warning: Filter not found: boolean in /var/www/tiki18farm/lib/core/TikiFilter.php on line 125
PHP Stack trace:
PHP 1. {main}() /var/www/tiki18farm/console.php:0
PHP 2. Tiki\Command\Application->run() /var/www/tiki18farm/console.php:80
PHP 3. Tiki\Command\Application->doRun() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Application.php:148
PHP 4. Tiki\Command\Application->doRunCommand() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Application.php:248
PHP 5. Tiki\Command\ListExecuteCommand->run() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Application.php:946
PHP 6. Tiki\Command\ListExecuteCommand->execute() /var/www/tiki18farm/vendor_bundled/vendor/symfony/console/Command/Command.php:252
PHP 7. ParserLib->parse_data() /var/www/tiki18farm/lib/core/Tiki/Command/ListExecuteCommand.php:68
PHP 8. ParserLib->parse_first() /var/www/tiki18farm/lib/parser/parserlib.php:1667
PHP 9. ParserLib->plugin_execute() /var/www/tiki18farm/lib/parser/parserlib.php:439
PHP 10. wikiplugin_listexecute() /var/www/tiki18farm/lib/parser/parserlib.php:1031
PHP 11. Search_Action_Sequence->execute() /var/www/tiki18farm/lib/wiki-plugins/wikiplugin_listexecute.php:172
PHP 12. Search_Action_ActionStep->execute() /var/www/tiki18farm/lib/core/Search/Action/Sequence.php:56
PHP 13. Search_Action_EmailAction->execute() /var/www/tiki18farm/lib/core/Search/Action/ActionStep.php:64
PHP 14. JitFilter_Element->boolean() /var/www/tiki18farm/lib/core/Search/Action/EmailAction.php:76
PHP 15. JitFilter_Element->__call() /var/www/tiki18farm/lib/core/Search/Action/EmailAction.php:76
PHP 16. JitFilter_Element->filter() /var/www/tiki18farm/lib/core/JitFilter/Element.php:60
PHP 17. TikiFilter::get() /var/www/tiki18farm/lib/core/JitFilter/Element.php:48
PHP 18. trigger_error() /var/www/tiki18farm/lib/core/TikiFilter.php:125
PHP Deprecated: idn_to_ascii(): INTL_IDNA_VARIANT_2003 is deprecated in /var/www/tiki18farm/vendor_bundled/vendor/zendframework/zend-mail/src/Header/AbstractAddressList.php on line 105
{CODE}

Today I have fought with a stubborn error in the output of my tools that extract and process the contents of tra() clauses. I could not find out what on earth changed key/value pairs, until I found an astonishing explanation: It's a bug, no, actually a feature of PHP that I didn't think of, and I believe also the devs who constructed Tikis tra() logic.
Basically there is an include file language.php which defines something like this:
{CODE(Colors="Tiki")}
$lang = [
"first key" => "first value",
...
"nth key" => "nth value",
];
{CODE}

Then there is another include file, custom.php, which can be edited through the custom translation admin page, which does something like this:
{CODE(Colors="Tiki")}
$lang_custom = array(
"something" => "else",
);
{CODE}

Then -if the bug ever gets fixed that this is omitted- custom.php close with a merge:
{CODE(Colors="Tiki")}
$lang = array_merge($lang, $lang_custom);
{CODE}

This is used so users/admins can modify the translation given in language.php. Newer values for keys given overwrite older definitions upon an array_merge.

Normally, this works as intended. BUT something completely different can happen if keys with numbers appear...

Voilà, according to [https://www.php.net/manual/en/function.array-merge.php|PHP manual]

"If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended. "

Which produces very funny (NOT) results, which are very hard to debug. And - language.php for German (de.de) DOES contain several numeric keys.

Also, a user or admin could at any time enter numeric keys. IMHO this "feature" should be documented and measures against numerical user entries be taken, unless I am completely mistaken. But simply try this little PHP demonstrator:

$lang is taken from the real language.php.

{CODE(Colors="Tiki")}
<?php

$lang = [
"1" => "1",
"5" => "5",
"10" => "10",
"15" => "15",
"30" => "30",
"2" => "2",
"4" => "4",
"6" => "6",
"7" => "7",
"8" => "8",
"9" => "9",
"20" => "20",
"40" => "40",
"50" => "50",
"60" => "60",
];

$lang_custom = array(
"something" => "else",
);

$merge = array_merge($lang, $lang_custom);
print_r($merge);
?>
{CODE}

Editing https://tiki.org/Consultants and https://next.tiki.org/Consultants or visiting pages like https://tiki.org/tiki-admin_tracker_fields.php?trackerId=22 made the server crash half a dozen of times. When t.o crash I had also crash on next.t.o doing something else.

From my understanding both are not on the same server.
Is it possible something still ties them together or could it be (extraordinary) random server crash occurring at the same time ?

{img fileId="1219" thumb="box"}
{img fileId="1218" thumb="box"}
{img fileId="1217" thumb="box"}
{img fileId="1216" thumb="box"}
{img fileId="1215" thumb="box"}

Note: It happened before I rebuilt the index using the web interface. At the end of the rebuilding they were multiples errors (much diverse than the screenshot show).

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

Please disregard this bug, please delete.

I think it all started when I was filling my availability row. This requires scrolling right, so I did not see the left-hand "save" icon. I saw a similar icon in the bottom and I clicked it (thinking "how clever, a floating save icon").
But it made me change pages to the calendar item of the top-selected time :-( (ooops!)
Then when I came back to the page, no availability was shown on my row (obviously) and I could not edit again (there was probably a lock) nor delete my whole line either.
Later on, I came back and I could fill availabilty agin and save.

Then I tried to add a new participant "Jyhem.logger" for confirming the issue
Then "Jyhem" was showing as if no availability was selected
But when I edited the line all was correctly selected. Just not shown
Also, I could not delete "Jyhem.logger" line

It was like there was some interference between the "Jyhem" and the Jyhem.logger" lines.

Then I edited the whole page and saw Jyhem had the proper selections. I cancelled edition of the page (no change).
Then all was good : I could delete "Jyhem.logger" and see the "Jyhem" availability
That's it

The cookie consent mechanism has this bold claim:

__"Complies with EU Privacy and Electronic Communications Regulations."__

First of all, let me express my thanks that someone has undertaken the task of creating a feature that at least tries to adhere to laws and regulations. Many IT systems do not even have that.

But the bold claim is only partially fulfilled. You ''can'' make cookie consent compliant with regulations, but it does not tell you how. And some defaults are ''not'' compliant.

To elaborate:
There is an option "Cookie consent disabled" with description
"Do not give the option to refuse cookies but still inform the user about cookie usage.". Enabling this would be a clear breach of regulations. In the European Union every user must be given the right to deny setting cookies. Luckily this one is default off.

This also implies that the setting "Cookie consent alert" with description "Sorry, cookie consent required" and hint "Alert displayed when user tries to access or use a feature requiring cookies." is non-compliant. The user has a right to refuse, and you cannot block his/her access upon that. It is okay if functionality is reduced (like remembering sessions), but you cannot block access.

There is a "Cookie consent question", "Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." with this default text: "I accept cookies from this site.". That's not a question, that's an answer :-)

"Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." Hm, no checkbox? Ask a clear question, one that users can answer binary "Yes" or "No".

The default label for consent is "Continue", which is not compliant. The label must clearly tell an medium level informed user what it does. Therefore it cannot be labelled "Continue". It can be changed, but this is the default.

Also, any kind of consent checkbox must not be preset!

So, I see the spirit of the devs to help admins be compliant, but this needs some brushing up to really enable admins to be on the right side of the law :-)

I see that for some areas outside the EU one might want to be less adherent to EU laws and therefore might want to force users to accept cookies. But a GUI of a function that claims compliance should not encourage that. So either claim this and offer only compliant options or display advice or even alerts when admins click on settings that would make them breach compliance... Or have one checkbox "compliant settings only" or something like that.

Also, inform admins that by law, site admins must inform their users about what kind of personal data is stored, where it is stored, and for how long. Commercial sites must also tell which persons are to be contacted if users want to get a copy of all that data, or who is to be contacted is someone wants that deleted.

Go on "List Wiki page".
Select any page, copy it (duplicate page).
Enter any name to save.

Once redirected to the new page it show a warning : You don’t have permission to edit tags.
Tested on a new Tiki without tags feature activated and tested on nextdev.

When I set my country in the user preferences dropdown and save, later on a subsequent visit to my preferences page it gets reset back to "Other" as if I did not select it before...

Creating a translation of Tiki Wiki is a really arduous task, more like a project (I have spent more than half a month already, almost fulltime).

No one will want to do this more than once, at least I don't. The problem is, that in order to render a good translation, you have to see a text in it's context. The task is so tremendously labour intensive, because you have to backtrack clicking everything, activating everything, then deactivating everything, trying to provoke all errors etc. pp. et. al.

Now comes the problem of Tiki improvements. With every new release of Tiki, from the smallest bugfix to the biggest new release of a LTS possibly comes new text. And even correcting a single character that was part of a typo immediately leads to the translation vanishing into thin air because the pattern matching of tra() won't catch it any longer. The translation remains in the language file, but is never displayed again.

So everything will have to be re-checked., time and again.

Since Tiki Wiki does not have one file of text that resides in constants, you cannot simply generate a diff to see what has changed, and thus needs new (or altered) translations.

Therefore a tool would be necessary that extracts all text to be displayed. That tool could then also look up if there are pre-existing translations of those strings, and present them, too. As a side effect, such a tool could help developers to guard their code against strings NOT passed into tra() or tr (which makes translating them impossible).

In the first stage, such a tool could simply produce one file as output, in later development could be interactive. Such a tool would be a necessry prerequiste for version advancement of Tiki, because without it, all (!) translations are rendered into "status unknown" with any change of code.

Side remark: Such a tool does not necessarily have to be part of Tiki. It could make development easier it at first it would be stand-alone.

When you create a new menu in the admin panel for that (tiki-admin_menus.php) you see the predefined application menu (with ID 42), a popup comes that asks some basics like menu title, description, style etc. When you enter that and click the create button - nothing happens. I would expect the list of menu to contain then two menus, the preexisting application menu and the newly created one. But still, only the prexisting menu is displayed. And no error message...

So it is impossible to create new menus...

hman

When creating calendar events I noticed that I created two events. Since this happend to me three times in a row I can exclude user error...

The events had this in common: They are whole day, they repeat every year, and they repeat 99 times (there is still no function in the calendar for endless repetition).

All doubles had precisely the same text, same date etc. The second entries could be manually deleted with no problems.

Thanks
hman

When I use the image plugin in TikiWiki 18.3 and set the text to flow around the image (imalign=right|left) then the text flows around as it should.

When I set a caption to the image (desc="") then the flow is immediately disrupted.

Captions, when no text flow is set, work perfectly, so these two features disturb each other. I posted this as a question in the forum, and got a workaround and the advice to report this as a bug.

Thanks for your help
hman

Steps to reproduce:
#Go to https://tiki.org/News
#Go to https://tiki.org/article452-Tiki-18-1-has-been-released-fixes-and-security-update
#Click "New Article"
#Enter a TEST title, Classification > Topic Releases and Patches, Publication > __uncheck the "Published" checkbox!__
#Click the "Save" button

You get switched back to default perspective. When you switch back to the first tab "Content" you see the form content is gone and the rest of the tabs got reset to the defaults as when you start editing new article... :(

When the session_storage preference is set to Database, some requests can misbehave due to a critical section in tikisession-pdo.php. This happens during concurrent requests, when one request is in the middle of a call to Session::write(). write() executes 2 queries, one which deletes the session (if it exists), and one which (re)creates the session. When write() is blocked between these 2 requests, 2 critical race conditions can occur. Assuming a first request is in between these 2 queries:
#If request #2 concurrently reads the sessions table, it will fail to find the session, causing Zend\Session\Container::getDefaultManager()->start() (in tiki-setup_base.php) to start a new session instead of resuming the session. This will cause:
## A multiplication of entries in the sessions table
## PHPSESSID to change unduly
## A loss of session data (in practice)
## The message "session cookie validation failed" to be logged in the system log.
# If the first race condition does not occur, but request #2 executes the DELETE in write() before request #1 has re-inserted the row, then whichever request finishes write() last will fail, due to an attempt to insert an existing row (the message will look like "Duplicate entry 'glmk0tl75dmi9rrkdfbgt7mr47' for key 'PRIMARY'").

! Symptoms

!! Images not displaying
This can be seen easily in a custom blog based on a wiki page in our Foncierpedia website. That page uses the LIST plugin to display posts with the author's avatar. Each time the page is loaded, there is one request to tiki-show_user_avatar.php per author, which redirects via HTTP 302 to tiki-download_file.php. The page currently has posts from 6 authors, so each load causes at least 6 requests using tiki-setup_base.php approximately simultaneously. In this context, the bug is very often visible, roughly 1 load every 5. To make it even more obvious, the critical section can be lengthened by calling sleep(2) between the 2 SQL queries in write(). With that, we see the bug [almost] on each load of the wiki page. The main symptom is that some images fail to display, due to race condition #2. This is very easy to reproduce with Tiki 15, since avatars are not cached, but in Tiki 18, tiki-show_user_avatar.php can return a 304 Not Modified, so if this doesn't reproduce on the first attempt, a full reload will be needed (Ctrl+F5 in Firefox).

This can also be reproduced with a wiki page which simply calls the IMG plugin. I used the following:
{CODE()}
{img src="tiki-download_file.php?fileId=6818&amp;display=y" width="100px"} {img src="tiki-download_file.php?fileId=5810&amp;display=y" width="100px"} {img src="tiki-download_file.php?fileId=5152&amp;display=y" width="100px"} {img src="tiki-download_file.php?fileId=6974&amp;display=y" width="100px"}
{img src="tiki-download_file.php?fileId=5800&amp;display=y" width="100px"} {img src="tiki-download_file.php?fileId=6889&amp;display=y" width="100px"} {img src="tiki-download_file.php?fileId=7052&amp;display=y" width="100px"}
{CODE}

!! Other
We are also experiencing abnormal user disconnections on the site. These are harder to reproduce, but likely related.
Related commit: {commit id=45249}

!! Logs
There are multiple messages in the actionlog. A query like the following can help see the pattern:
{CODE()}SELECT FROM_UNIXTIME(lastModif), `tiki_actionlog`.* FROM `tiki_actionlog` ORDER BY ip, lastModif{CODE}
Related commit: {commit id=56775}

! Source
This is a regression from {commit id=24568}.

Errors on database update after a brand new trunk install Revision: 63992

{CODE()}
Macintosh-2:trunk Bernard$ php console.php d:u

Warning: Illegal string offset 'galleryId' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20101126_fgal_add_gallerie_user_tiki.php on line 30

Call Stack:
0.0015 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3273 23818600 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3385 24111848 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3388 24113152 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3389 24113752 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3399 24126888 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3426 24127800 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
4.1942 24906584 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
4.1947 24912832 9. upgrade_20101126_fgal_add_gallerie_user_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:174


Warning: Illegal string offset 'galleryId' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20101210_fgal_add_wiki_attachments_tiki.php on line 30

Call Stack:
0.0015 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3273 23818600 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3385 24111848 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3388 24113152 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3389 24113752 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3399 24126888 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3426 24127800 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
4.3763 24925600 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
4.3768 24931912 9. upgrade_20101210_fgal_add_wiki_attachments_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:174


Warning: PDOStatement::execute(): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'lang' in 'where clause' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php on line 77

Call Stack:
0.0015 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3273 23818600 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3385 24111848 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3388 24113152 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3389 24113752 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3399 24126888 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3426 24127800 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
5.1030 25058928 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
5.1038 25087912 9. pre_20110727_tracker_multilingual_convert_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:180
5.1051 25094912 10. TikiDb_Table->deleteMultiple() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20110727_tracker_multilingual_convert_tiki.php:46
5.1051 25095488 11. TikiDb->queryException() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Table.php:109
5.1051 25095664 12. TikiDb_Pdo->query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb.php:72
5.1051 25095664 13. TikiDb_Pdo->_query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:118
5.1051 25097632 14. PDOStatement->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:77



[TikiDb_Exception]
Unknown column 'lang' in 'where clause'


database:update [--auto-register]
{CODE}

I re ran it and it changed for

{CODE()}Macintosh-2:trunk Bernard$ php console.php d:u

Warning: PDOStatement::execute(): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'lang' in 'where clause' in /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php on line 77

Call Stack:
0.0029 247624 1. {main}() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:0
0.3364 23818896 2. Symfony\Component\Console\Application->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/console.php:80
0.3489 24112240 3. Symfony\Component\Console\Application->doRun() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:125
0.3492 24113544 4. Symfony\Component\Console\Application->doRunCommand() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:224
0.3492 24114144 5. Symfony\Component\Console\Command\Command->run() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Application.php:888
0.3504 24127280 6. Tiki\Command\UpdateCommand->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/vendor_bundled/vendor/symfony/console/Command/Command.php:264
0.3532 24128192 7. Installer->update() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/Tiki/Command/UpdateCommand.php:38
1.1695 24643456 8. Installer->installPatch() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:129
1.1703 24672440 9. pre_20110727_tracker_multilingual_convert_tiki() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/installlib.php:180
1.1719 24679376 10. TikiDb_Table->deleteMultiple() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/installer/schema/20110727_tracker_multilingual_convert_tiki.php:46
1.1720 24679952 11. TikiDb->queryException() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Table.php:109
1.1720 24680128 12. TikiDb_Pdo->query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb.php:72
1.1720 24680128 13. TikiDb_Pdo->_query() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:118
1.1721 24682096 14. PDOStatement->execute() /Users/Bernard/Documents/Shocksite/www/htdocs/trunk/lib/core/TikiDb/Pdo.php:77



[TikiDb_Exception]
Unknown column 'lang' in 'where clause'


database:update [--auto-register]
{CODE}

Using the setting 'Default Category' on the admin page of a group doesn't work.
According to the label it should: Default category assigned to uncategorized objects edited by a user with this default group.

How to reproduce:
- Changing the Default Category on Group X from none to category Y.
- Creating a new wiki page by a user that is (only, except the build in Registered group) part of Group Y.
- Viewing the tab 'Categories' on the edit wiki page
- There is no category selected...

This means the users can set an incorrect category to a page, so they don't have access after saving the page.

I have reproduced it on the demo environment as the 'show' environment has a problem with Composer not installed:
https://demo.tiki.org/18x/tiki-editpage.php?page=Test123&quickedit=Create+Page#contenttabs_editpage-2
Login with
User: User_Test
passw: User_Test

The default size of article images is the least little bit too high in my view.

The explanation given to the admin reminds the admin "Maximum file size for an article image. Article images are stored in the database so it should remain low". And after stating that, the default is 500.000. Kilobytes :-) That's 500 MBytes for one single image. I wonder what MySQL thinks about a blob of 500 meg... And imagine a backup of that DB in .sql format... :-)

{CODE(Colors="Tiki")}
'article_image_file_size_max' => [
'name' => tra('Article image maximum file size'),
'description' => tra('Maximum file size for an article image. Article images are stored in the database so it should remain low.'),
'type' => 'text',
'size' => '10',
'filter' => 'digits',
'units' => tra('kilobytes'),
'default' => 500000,
],
{CODE}

On the wiki control panel is a button that links to /tiki-admin.php?page=wiki&rmvunusedpic=1.

This button fires without warning, IMHO a "Are you sure?" dialog is really necessary, because you do not know, and are not informed of, what you delete here. Possibly some images you just forgot to use somewhere, or that users just recently uploaded and had not time to use. In the case of user images the risk is imminent, that no backup exists, which will lead to loss of data!

The dialog should include a list of images to be deleted, ideally with the option to opt out certain images (cheboxes for each, inluding "select all" and "unselect all" buttons.

I have a tracker A with items
I have another tracker B with items with an itemLink field on tracker A items

When I want to delete items from the tracer A using the "spanner → Delete" to the right end of the line it tells me how many other items from tracker B link to it and lets me suggest a replacement link. Then I can delete them all.

Issues:
* no itemlinks are modified in tracker B
* The entry from tracker A is not deleted

-----
I can't reproduce fully on show.tiki.org yet:
I delete Item "Mrs. HHHHHH" from [http://jyhem-9952-6871.show.tikiwiki.org/tiki-view_tracker.php?trackerId=2] while choosing to replace the occurence o
It fails to delete

I try to delete ''Student: Bacc.'' titem from [http://jyhem-9952-6871.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1] (see attachment)
On step 2 (see attachment), I ask to replace the link to 'Student: Bacc.'' with links to 'Student: M.Sc.''. Then I click on "Delete item".

It DOES change the link on [http://jyhem-9952-6871.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=18] from Student: Bacc.'' with links to 'Student: M.Sc.'', which is not the case on my production site…
It still fails to actually delete the item, but that was not the biggest issue (it can be deleted once nothing links to it).

I'll try again.

----
After comparing the network queries from both sites, I feel the difference in behaviour is due to having sefurl in the real site and not on show.tiki.org.

More interestingly, I got the same error message in both situations, so we __do__ have something to fix.
{CODE()}
[Fri Oct 19 17:21:22.867750 2018] [:error] [pid 13504] [client 90.126.49.74:59730] PHP Fatal error: Call to a member function getLanguageField() on boolean in /var/www/jyhem-9952-6871/lib/core/Tracker/Field/Language.php on line 99, referer: http://jyhem-9952-6871.show.tikiwiki.org/tiki-view_tracker.php?trackerId=1
{CODE}