Category: 21.x

Login with user "admin" doesn't work when CAS authentication is enabled.

I’m losing editing time after time on the wishlist.

https://dev.tiki.org/item7384-Tracker-TextArea-field-multilingual-parameter-filter-is-not-applied-in-plugin-List-all-language-are-displayed

https://share.vidyard.com/watch/rwF7GwJd6BKAuVK6WxpRzq?

In edit mode (and maybe also in view mode) ((doc:Items List and Item Link Tracker Fields|ItemsList Fields)) should offer an "Add new item" button and an edit and/or delete icon where the user has those permissions.

This should be new field options and default to off (i.e. empty) for upgrades. This should work like the existing addItems param on ItemLink fields, perhaps with a companion addItemsWikiTpl option for a template.
Options:
* addItem (text to show on an add new things button)
* editItem (y/n to show an edit icon next to each item)
* deleteItem (y/n to show a delete icon next to each item)
* editInViewMode (y/n whether the edit buttons and icons also appear when viewing an item)

mpdf seems to faill to include images in the generated pdf file when you use:
* some self-signed https certificate, or
* a valid one but issued from a certification agency (like from a local public administration, in our case at work) which is not recognized by your browser by default unless you import a specific authority file in the right place (and I don't know how to do that for mpdf).

I wish there was some way to tell mpdf to avoid checking https certificate validity, like the option you can have in many other programs (wget, curl, git, ...). If that is possible, then a new option should be added in Tiki UI to let the tiki site admin enable it in those known use cases in which you need that feature.

As an example, that would have allowed to use mpdf successfully in the last couple of years at work. And we still can't use it normally due to this issue.

I've made a page to display the ((Bug report evolution|Bug report evolution)) over time in dev.t.o, thanks to PluginPivotTable and dereived attributes of the dates, etc.

Charts are displayed, But the chart width seems to be hardcoded to 600px or similar, even if the PivotTable plugin params said width=100% initially, and I forced them to width=1000px, but no change. And in real world scenarios, with long dataset (like in the tiki community with the bug tracker :-) visualization is too concetrated.(and I did not find an easy way to make a quarter aggregation of items, but that's another topic)

Searching a bit, this seems to be an issue already identified in other implementations of pivottable.js in other softwares:
https://github.com/nicolaskruchten/pivottable/issues/848

An easy solution/workaround might involve maping param rendererOptions inside pivottable .tpl (to set plotly width and height) to to the width and height indicated in the pivottable tiki plugin params.
See:
https://pivottable.js.org/examples/scatter.html
{CODE()}
...
rendererOptions: { plotly: {width: 600, height: 600} }
...
{CODE}

Probably below this chunk of code in wikiplugin_pivottable.tpl (lines 411-51) in trunk:
{CODE()}
...
{{if $pivottable.heatmapParams}}
rendererOptions: {
heatmap: {
colorScaleGenerator: function(values) {
return Plotly.d3.scale.linear()
.domain({{$pivottable.heatmapParams.domain|json_encode}})
.range({{$pivottable.heatmapParams.colors|json_encode}});
}
}
},
{{/if}}
...
{CODE}

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

__The message below was edited.__ {sign user="Chealer9" datetime="2018-06-08T15:57:21+00:00"}

We are running into an issue of maketoc appending onto itself if more than one maketoc appear per page. for starters, our server is TikiWiki 3.2, Windows Server 2003, apache 2.2.13, mysql 5.1.39, php 5.3.0, Multiwiki setup.

We are seeing this in ((doc:Multiprint)). What I am seeing is that if I have Tikipage A with a ~np~{maketoc}~/np~ at the VERY top and headings 1, 2, 3 and Tikipage B with a ~np~{maketoc}~/np~ at the VERY top and headings 4, 5. When I Multiprint using the Pages selector (both Tikipage A and B) there will be 2 TOCs displayed in the resulting print page. The first TOC will show 1,2,3 and further down the page will be 1,2,3,4,5 (when I expected only 4,5). We are trying to Mulitprint hundreds of pages (and most have their own maketoc) so the very last TOC takes up 15 pages itself (after accumulating TOCS over 100s of wiki pages). Big problem for us as our nurses need to have a hardcopy/offline copy on hand in case our systems go down.



So it is the parsing of the maketoc that is causing the appending of subsequent TOCs. I found a bug by "larryg" where he tries to fix a similar issue (cf {wish id=2781} and [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=2&comments_parentId=34791]) but his fix did not work for me. I think that he is on the right track. Does anyone know of a fix? Has anyone experienced this? Is it fixed in 4.x?

Thanks in advance,

Tim

I go to page tiki-search_replace.php

I try to replace
-+ [https://wiki.inesss.qc.ca/ +-
with
-+ [ +-
in all wiki pages

I see a section of pages.
I select all of them.
I click on the "Replace" button at the bottom

Nothing was replaced. No error message either.

Replacing -+ https://wiki.inesss.qc.ca/ +- with nothing failed in the exact same way

More info :
If I don't actually « select all of them », all works well for small values, like "10".

If I select all of them, Tiki fails silently while the error log shows :
[17-Feb-2020 15:44:26 America/New_York] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0

* Tiki lets us configure min_username_length and max_username_length unless we select login_is_email
* If we select login_is_email, these configs are hidden __but max_username_length is still enforced__ in -+ lib/validators/validator_username.php +- and in -+ lib/registration/registrationlib.php +-

The database structure seems to let us have as many as 191 chars without an issue. Certainly these are actually bytes, not chars.
Notes: If we use english logins or emails as logins, it's 191 characters. Accentuated chars in french and other european languages use 2 bytes (éààê). Some other languages use alphabets in which all chars use 2, 3 or 4 bytes.

My suggestion :
* Important: We should not enforce ''min_username_length'' and ''max_username_length'' when preference login_is_email is selected.
* Nice to have: We should still have some hard limit of 191 bytes (not chars) even if login_is_email is selected (needs to be tested with utf8 characters) so that people get a nice explanation instead of a mysql error message about an insert failure.

I can't install media-alchemist due to several problems.. When attempted in 21.x through packages web control panel, this output is shown:
{CODE()}
Problem 1
- Conclusion: don't install media-alchemyst/media-alchemyst 0.5.5
- Conclusion: remove monolog/monolog 2.0.2
- Conclusion: don't install monolog/monolog 2.0.2
- Installation request for media-alchemyst/media-alchemyst ^0.5.4 -> satisfiable by media-alchemyst/media-alchemyst[0.5.4, 0.5.5].
- Conclusion: don't install monolog/monolog 2.0.2
- media-alchemyst/media-alchemyst 0.5.4 requires monolog/monolog ~1.0 -> satisfiable by monolog/monolog[1.0.0, 1.1.0, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.13.1, 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.17.1, 1.17.2, 1.18.0, 1.18.1, 1.18.2, 1.19.0, 1.20.0, 1.21.0, 1.22.0, 1.22.1, 1.23.0, 1.24.0, 1.25.0, 1.25.1, 1.25.2, 1.25.3, 1.4.0, 1.4.1, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.0.1, 1.0.2, 1.2.0, 1.2.1, 1.3.0, 1.3.1].
- Can only install one of: monolog/monolog[1.17.0, 2.0.2].
- Can only install one of: monolog/monolog[1.17.1, 2.0.2].
- Can only install one of: monolog/monolog[1.17.2, 2.0.2].
- Can only install one of: monolog/monolog[1.18.0, 2.0.2].
- Can only install one of: monolog/monolog[1.18.1, 2.0.2].
- Can only install one of: monolog/monolog[1.18.2, 2.0.2].
- Can only install one of: monolog/monolog[1.19.0, 2.0.2].
- Can only install one of: monolog/monolog[1.20.0, 2.0.2].
- Can only install one of: monolog/monolog[1.21.0, 2.0.2].
- Can only install one of: monolog/monolog[1.22.0, 2.0.2].
- Can only install one of: monolog/monolog[1.22.1, 2.0.2].
- Can only install one of: monolog/monolog[1.23.0, 2.0.2].
- Can only install one of: monolog/monolog[1.24.0, 2.0.2].
- Can only install one of: monolog/monolog[1.25.0, 2.0.2].
- Can only install one of: monolog/monolog[1.25.1, 2.0.2].
- Can only install one of: monolog/monolog[1.25.2, 2.0.2].
- Can only install one of: monolog/monolog[1.25.3, 2.0.2].
- Can only install one of: monolog/monolog[2.0.2, 1.17.0].
- Can only install one of: monolog/monolog[2.0.2, 1.17.1].
- Can only install one of: monolog/monolog[2.0.2, 1.17.2].
- Can only install one of: monolog/monolog[2.0.2, 1.18.0].
- Can only install one of: monolog/monolog[2.0.2, 1.18.1].
- Can only install one of: monolog/monolog[2.0.2, 1.18.2].
- Can only install one of: monolog/monolog[2.0.2, 1.19.0].
- Can only install one of: monolog/monolog[2.0.2, 1.20.0].
- Can only install one of: monolog/monolog[2.0.2, 1.21.0].
- Can only install one of: monolog/monolog[2.0.2, 1.22.0].
- Can only install one of: monolog/monolog[2.0.2, 1.22.1].
- Can only install one of: monolog/monolog[2.0.2, 1.23.0].
- Can only install one of: monolog/monolog[2.0.2, 1.24.0].
- Can only install one of: monolog/monolog[2.0.2, 1.25.0].
- Can only install one of: monolog/monolog[2.0.2, 1.25.1].
- Can only install one of: monolog/monolog[2.0.2, 1.25.2].
- Can only install one of: monolog/monolog[2.0.2, 1.25.3].
- Can only install one of: monolog/monolog[1.0.0, 2.0.2].
- Can only install one of: monolog/monolog[1.0.1, 2.0.2].
- Can only install one of: monolog/monolog[1.0.2, 2.0.2].
- Can only install one of: monolog/monolog[1.1.0, 2.0.2].
- Can only install one of: monolog/monolog[1.10.0, 2.0.2].
- Can only install one of: monolog/monolog[1.11.0, 2.0.2].
- Can only install one of: monolog/monolog[1.12.0, 2.0.2].
- Can only install one of: monolog/monolog[1.13.0, 2.0.2].
- Can only install one of: monolog/monolog[1.13.1, 2.0.2].
- Can only install one of: monolog/monolog[1.14.0, 2.0.2].
- Can only install one of: monolog/monolog[1.15.0, 2.0.2].
- Can only install one of: monolog/monolog[1.16.0, 2.0.2].
- Can only install one of: monolog/monolog[1.2.0, 2.0.2].
- Can only install one of: monolog/monolog[1.2.1, 2.0.2].
- Can only install one of: monolog/monolog[1.3.0, 2.0.2].
- Can only install one of: monolog/monolog[1.3.1, 2.0.2].
- Can only install one of: monolog/monolog[1.4.0, 2.0.2].
- Can only install one of: monolog/monolog[1.4.1, 2.0.2].
- Can only install one of: monolog/monolog[1.5.0, 2.0.2].
- Can only install one of: monolog/monolog[1.6.0, 2.0.2].
- Can only install one of: monolog/monolog[1.7.0, 2.0.2].
- Can only install one of: monolog/monolog[1.8.0, 2.0.2].
- Can only install one of: monolog/monolog[1.9.0, 2.0.2].
- Can only install one of: monolog/monolog[1.9.1, 2.0.2].
- Can only install one of: monolog/monolog[2.0.2, 1.0.0].
- Can only install one of: monolog/monolog[2.0.2, 1.1.0].
- Can only install one of: monolog/monolog[2.0.2, 1.10.0].
- Can only install one of: monolog/monolog[2.0.2, 1.11.0].
- Can only install one of: monolog/monolog[2.0.2, 1.12.0].
- Can only install one of: monolog/monolog[2.0.2, 1.13.0].
- Can only install one of: monolog/monolog[2.0.2, 1.13.1].
- Can only install one of: monolog/monolog[2.0.2, 1.14.0].
- Can only install one of: monolog/monolog[2.0.2, 1.15.0].
- Can only install one of: monolog/monolog[2.0.2, 1.16.0].
- Can only install one of: monolog/monolog[2.0.2, 1.4.0].
- Can only install one of: monolog/monolog[2.0.2, 1.4.1].
- Can only install one of: monolog/monolog[2.0.2, 1.5.0].
- Can only install one of: monolog/monolog[2.0.2, 1.6.0].
- Can only install one of: monolog/monolog[2.0.2, 1.7.0].
- Can only install one of: monolog/monolog[2.0.2, 1.8.0].
- Can only install one of: monolog/monolog[2.0.2, 1.9.0].
- Can only install one of: monolog/monolog[2.0.2, 1.9.1].
- Installation request for monolog/monolog (locked at 2.0.2) -> satisfiable by monolog/monolog[2.0.2].
{CODE}

When attempted through the command line with this command,
{CODE()}
php temp/composer.phar require --update-no-dev --prefer-dist media-alchemyst/media-alchemyst:^0.5.4
{CODE}

This is then the error message shown:
{CODE()}
root@computer: /var/www/html/21.x# php temp/composer.phar require --update-no-dev --prefer-dist media-alchemyst/media-alchemyst:^0.5.4
Do not run Composer as root/super user! See https://getcomposer.org/root for details
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Conclusion: don't install media-alchemyst/media-alchemyst 0.5.5
- Conclusion: remove monolog/monolog 2.0.2
- Conclusion: don't install monolog/monolog 2.0.2
- Installation request for media-alchemyst/media-alchemyst ^0.5.4 -> satisfiable by media-alchemyst/media-alchemyst[0.5.4, 0.5.5].
- Conclusion: don't install monolog/monolog 2.0.2
- media-alchemyst/media-alchemyst 0.5.4 requires monolog/monolog ~1.0 -> satisfiable by monolog/monolog[1.0.0, 1.1.0, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.13.1, 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.17.1, 1.17.2, 1.18.0, 1.18.1, 1.18.2, 1.19.0, 1.20.0, 1.21.0, 1.22.0, 1.22.1, 1.23.0, 1.24.0, 1.25.0, 1.25.1, 1.25.2, 1.25.3, 1.4.0, 1.4.1, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.0.1, 1.0.2, 1.2.0, 1.2.1, 1.3.0, 1.3.1].
- Can only install one of: monolog/monolog[1.17.0, 2.0.2].
- Can only install one of: monolog/monolog[1.17.1, 2.0.2].
- Can only install one of: monolog/monolog[1.17.2, 2.0.2].
- Can only install one of: monolog/monolog[1.18.0, 2.0.2].
- Can only install one of: monolog/monolog[1.18.1, 2.0.2].
- Can only install one of: monolog/monolog[1.18.2, 2.0.2].
- Can only install one of: monolog/monolog[1.19.0, 2.0.2].
- Can only install one of: monolog/monolog[1.20.0, 2.0.2].
- Can only install one of: monolog/monolog[1.21.0, 2.0.2].
- Can only install one of: monolog/monolog[1.22.0, 2.0.2].
- Can only install one of: monolog/monolog[1.22.1, 2.0.2].
- Can only install one of: monolog/monolog[1.23.0, 2.0.2].
- Can only install one of: monolog/monolog[1.24.0, 2.0.2].
- Can only install one of: monolog/monolog[1.25.0, 2.0.2].
- Can only install one of: monolog/monolog[1.25.1, 2.0.2].
- Can only install one of: monolog/monolog[1.25.2, 2.0.2].
- Can only install one of: monolog/monolog[1.25.3, 2.0.2].
- Can only install one of: monolog/monolog[2.0.2, 1.17.0].
- Can only install one of: monolog/monolog[2.0.2, 1.17.1].
- Can only install one of: monolog/monolog[2.0.2, 1.17.2].
- Can only install one of: monolog/monolog[2.0.2, 1.18.0].
- Can only install one of: monolog/monolog[2.0.2, 1.18.1].
- Can only install one of: monolog/monolog[2.0.2, 1.18.2].
- Can only install one of: monolog/monolog[2.0.2, 1.19.0].
- Can only install one of: monolog/monolog[2.0.2, 1.20.0].
- Can only install one of: monolog/monolog[2.0.2, 1.21.0].
- Can only install one of: monolog/monolog[2.0.2, 1.22.0].
- Can only install one of: monolog/monolog[2.0.2, 1.22.1].
- Can only install one of: monolog/monolog[2.0.2, 1.23.0].
- Can only install one of: monolog/monolog[2.0.2, 1.24.0].
- Can only install one of: monolog/monolog[2.0.2, 1.25.0].
- Can only install one of: monolog/monolog[2.0.2, 1.25.1].
- Can only install one of: monolog/monolog[2.0.2, 1.25.2].
- Can only install one of: monolog/monolog[2.0.2, 1.25.3].
- Can only install one of: monolog/monolog[1.0.0, 2.0.2].
- Can only install one of: monolog/monolog[1.0.1, 2.0.2].
- Can only install one of: monolog/monolog[1.0.2, 2.0.2].
- Can only install one of: monolog/monolog[1.1.0, 2.0.2].
- Can only install one of: monolog/monolog[1.10.0, 2.0.2].
- Can only install one of: monolog/monolog[1.11.0, 2.0.2].
- Can only install one of: monolog/monolog[1.12.0, 2.0.2].
- Can only install one of: monolog/monolog[1.13.0, 2.0.2].
- Can only install one of: monolog/monolog[1.13.1, 2.0.2].
- Can only install one of: monolog/monolog[1.14.0, 2.0.2].
- Can only install one of: monolog/monolog[1.15.0, 2.0.2].
- Can only install one of: monolog/monolog[1.16.0, 2.0.2].
- Can only install one of: monolog/monolog[1.2.0, 2.0.2].
- Can only install one of: monolog/monolog[1.2.1, 2.0.2].
- Can only install one of: monolog/monolog[1.3.0, 2.0.2].
- Can only install one of: monolog/monolog[1.3.1, 2.0.2].
- Can only install one of: monolog/monolog[1.4.0, 2.0.2].
- Can only install one of: monolog/monolog[1.4.1, 2.0.2].
- Can only install one of: monolog/monolog[1.5.0, 2.0.2].
- Can only install one of: monolog/monolog[1.6.0, 2.0.2].
- Can only install one of: monolog/monolog[1.7.0, 2.0.2].
- Can only install one of: monolog/monolog[1.8.0, 2.0.2].
- Can only install one of: monolog/monolog[1.9.0, 2.0.2].
- Can only install one of: monolog/monolog[1.9.1, 2.0.2].
- Can only install one of: monolog/monolog[2.0.2, 1.0.0].
- Can only install one of: monolog/monolog[2.0.2, 1.1.0].
- Can only install one of: monolog/monolog[2.0.2, 1.10.0].
- Can only install one of: monolog/monolog[2.0.2, 1.11.0].
- Can only install one of: monolog/monolog[2.0.2, 1.12.0].
- Can only install one of: monolog/monolog[2.0.2, 1.13.0].
- Can only install one of: monolog/monolog[2.0.2, 1.13.1].
- Can only install one of: monolog/monolog[2.0.2, 1.14.0].
- Can only install one of: monolog/monolog[2.0.2, 1.15.0].
- Can only install one of: monolog/monolog[2.0.2, 1.16.0].
- Can only install one of: monolog/monolog[2.0.2, 1.4.0].
- Can only install one of: monolog/monolog[2.0.2, 1.4.1].
- Can only install one of: monolog/monolog[2.0.2, 1.5.0].
- Can only install one of: monolog/monolog[2.0.2, 1.6.0].
- Can only install one of: monolog/monolog[2.0.2, 1.7.0].
- Can only install one of: monolog/monolog[2.0.2, 1.8.0].
- Can only install one of: monolog/monolog[2.0.2, 1.9.0].
- Can only install one of: monolog/monolog[2.0.2, 1.9.1].
- Installation request for monolog/monolog (locked at 2.0.2) -> satisfiable by monolog/monolog[2.0.2].

Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.

Installation failed, reverting ./composer.json to its original content.
root@computer:/var/www/html/21.x# php temp/composer.phar require --update-no-dev --prefer-dist monolog/monolog:^1.0.0
Do not run Composer as root/super user! See https://getcomposer.org/root
{CODE}
I could solve by means of downgrading the monolog/monolog package to 1.x, and then reinstalling through command line worked.
{CODE()}
root@computer:/var/www/html/21.x# php temp/composer.phar require --update-no-dev --prefer-dist monolog/monolog:^1.0.0
Do not run Composer as root/super user! See https://getcomposer.org/root for details
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies
Package operations: 22 installs, 1 update, 0 removals
- Installing symfony/polyfill-ctype (v1.14.0): Loading from cache
- Installing symfony/filesystem (v3.4.38): Downloading (100%)
- Installing symfony/polyfill-mbstring (v1.14.0): Loading from cache
- Installing symfony/debug (v4.4.5): Downloading (100%)
- Installing symfony/console (v3.4.38): Downloading (100%)
- Installing pimple/pimple (v1.0.2): Downloading (100%)
- Downgrading monolog/monolog (2.0.2 => 1.25.3): Downloading (100%)
- Installing evenement/evenement (v1.1.0): Downloading (100%)
- Installing alchemy/binary-driver (1.6.0): Downloading (100%)
- Installing swftools/swftools (0.3.2): Downloading (100%)
- Installing php-unoconv/php-unoconv (0.3.1): Downloading (100%)
- Installing php-mp4box/php-mp4box (0.3.0): Downloading (100%)
- Installing neutron/temporary-filesystem (2.4): Downloading (100%)
- Installing doctrine/cache (1.10.0): Downloading (100%)
- Installing php-ffmpeg/php-ffmpeg (0.5.1): Downloading (100%)
- Installing imagine/imagine (v0.6.3): Downloading (100%)
- Installing symfony/http-foundation (v2.5.4): Downloading (100%)
- Installing doctrine/collections (1.6.4): Downloading (100%)
- Installing phpexiftool/exiftool (10.10): Downloading (100%)
- Installing alchemy/phpexiftool (0.7.2): Downloading (100%)
- Installing alchemy/mediavorus (0.4.10): Downloading (100%)
- Installing alchemy/ghostscript (0.4.0): Downloading (100%)
- Installing media-alchemyst/media-alchemyst (0.5.5): Downloading (100%)
Package robloach/component-installer is abandoned, you should avoid using it. Use oomphinc/composer-installers-extender instead.
Writing lock file
Generating autoload files
> ComponentInstaller\Installer::postAutoloadDump
Compiling component files
root@computer:/var/www/html/21.x# php temp/composer.phar require --update-no-dev --prefer-dist media-alchemyst/media-alchemyst:^0.5.4
Do not run Composer as root/super user! See https://getcomposer.org/root for details
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies
Nothing to install or update
Package robloach/component-installer is abandoned, you should avoid using it. Use oomphinc/composer-installers-extender instead.
Generating autoload files
> ComponentInstaller\Installer::postAutoloadDump
Compiling component files
root@computer:/var/www/html/21.x#
{CODE}

I have test-upgraded my test site (which is a copy of the productive site with slightly less content, but duplicate files, layout, CSS) and upgrading failed. Miserably.

First, there was one (1) SQL error:
{CODE(Colors="Tiki")}
UPDATE `users_objectpermissions` SET `permName` = 'tiki_p_read_article' WHERE `permName` = 'tiki_p_topic_read' AND `objectType` = 'topic'
Duplicate entry '4dadd7eebd7a5fc8790114f9f5aaa8b6-topic-Anonymous-tiki_p_read_art' for key 'PRIMARY'
{CODE}

For the moment, I checked the checkmark in order to proceed (it's not the productive site anyway, and I have a backup of both the files and the DB).

After logging in, I was flabbergasted. I thought my layout (originally done by Gary to imitate a standard layout of 12.14 that was dropped with later updates: Geo) was kind of conservative, absolutely nothing fancy. Standard, classic Tiki layout with 3 containers, a header, a left module zone, a center wiki content and a right module zone.

There is one horizontal menu which was VERY hard to create on 18.8 (because creating menus from scratch is simply not possible (at all) on 18.8., due to an unfixed bug. I made it possible with a trick, I created a second standard menu, exported it, modified it as needed, and re-imported.

Since at that time I did not want to indulge in the depths of the CSS, I created style directives in the context of the menu, which worked satisfactorily. Most of the site is classic Wiki content. Some articles for news, a calendar (which was horribly bug-ridden and thus dysfunctional on 18.8) and a small shop (CART).

So nothing fancy at all. No categories (besides what CART brought with it), no perspectives, etc.

And now the catastrophe: The left module zone is now sitting on the right, and the right module zone went to far-right. Yes, both left and right module zone now sit on the right-hand side.

The menu is a mess with wrong fonts, wrong sizing, wrong spacing etc.

When I call the control panels, they come up as one column (!) in a seemingly endless page, hardly usable at all.

This is the worst upgrade I have ever witnessed. And I thought 12.14 -> 18.2 was a bad. Little did I know...

I checked the look & feel setting, found nothing special in there, it is still on "classic Tiki 3 container". The admin setting was off, to "1 container", but setting that to "Classic Tiki 3 container" to match the site's default changed nothing...

If Tiki keeps breaking my layouts, I am seriously considering to let go. If it weren't for more than one decade of content, I would be gone already. Enough is enough.

When changing a wiki structure with drag and drop in tiki-edit_structure.php, the 'save' button doesn't appear as it does in Tiki 18/19.
It's keeps being hidden by css with display:none, beside that it also doesn't work; it will not save the changes.

Please see as showed here, it's possible to drag a new page in to the structure but there is no save button.
http://wobow-11900-7179.show2.tikiwiki.org/tiki-edit_structure.php?page_ref_id=1

When you use the I18n admin control panel for the first time to create a custom translation (/tiki-language-manage_custom_translations) , it create the custom.php file.

However translation are not performed as it miss at the end of the file (like in the sample file we distribute : custom.php_example)
~pp~$lang = array_merge($lang, $lang_custom);~/pp~

Once you paste it custom translation are working.

Update: Even if you paste it in the file it is removed each time a translation is saved.

Modal popupforms in 20.x show tracker item edit fields narrower than in 18.x (input field to edit a tracker item were using full width), __when you have the option "Section Format" set to -+Tabs+- instead of "Flat" or "Configured"__.

See screenshot below comparing same item in a site in 18.x (FiveAliveHS) and after it's been upgraded to 20.x (using a different theme style - Cerulean, but with the same theme style FileAlive, the same problem was shown).

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

The overall look and feel is way poorer, since there doesn't seem to be consistency in the layout of fields of the same tracker item. In 18.x, the look and feel was better.

Reproduced here:
http://xavi-9794-7124.show2.tikiwiki.org/tiki-view_tracker_item.php?itemId=4
u: admin
p: 12345

Edit the item and you will see it.
Conveert the Section format from the properties of that tracker from "Tabs" to "Flat", or enable to use the former interface to add tracker items, and you will see he difference when editing tracker items.

When you create a new article and decide to __not publish it__ (which means actively removing the checkmark on the "published" checkbox), then it won't show up in articles module, and not on Home of articles (correct behaviour), but it does show up in the module "Since last visit". This is inconsistent...

mpdf doesn't seem to include content displayed through plugin map.
Tested using latest 19.x with mpdf (7.1) installed through control panel to install packages

See it reproduced here:
https://adup.cat/Inici#contentpestanyes_trobades-4

{syntax type="tiki" editor="plain"}
Printing with mpdf doesn't include images in many cases including params in the plugin img call such as zoombox, or when controlling the display of images from inside a ((doc:PluginFluidgrid)) , and in other cases reproduced in the show.t.o instance indicated:

Reproduced in a show2.t.o instance from another bug report (since setting up diagram generation requires some manual steps to get the composer package installed server side)
http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=Tiki-Wiki-CMS-Groupware
u: admin
p: 12345

Current code used in the show instance:
SVN (24.0vcs): Tuesday August 3, 2021 17:34:21 CEST - REV 78798 (InnoDB)

See pdf produced with pdf:
{file type="gallery" fileId="1564" showicon="y"}

See the corresponding pdf produced by a local pdf printer from the print veresion of that wiki page:
{file type="gallery" fileId="1565" showicon="y"}


Code being used for the first sections about images:
{CODE()}

{FLUIDGRID()}
5: {img src="tiki-download_file.php?fileId=5&display" width="200"} 6: {img fileId="6" width=200}
---
7: {img fileId="7"} 8: {img src="tiki-download_file.php?fileId=8&display" width=400}
{FLUIDGRID}

!!# Local Image with zoombox
{img fileId="4" thumb="box"}

!!# Another local Image without zoombox

{img src="tiki-download_file.php?fileId=5&display"}

!!# A remote image with zoombox

{img src="https://doc.tiki.org/img/wiki_up/393px-Pears.jpg" thumb="box"}

!!# A remote image without zoombox

{img src="https://doc.tiki.org/dl1480?display&x=250&y=180" }

{CODE}
---

retested today upgrading the show instance to latest 24.x
"Upgraded today (server side) to latest 24.x branch: r79594 (Last Changed Date: 2022-01-22 14:46:09 +0100 - Sat, 22 Jan 2022) ", adn removed and reinstalled mpdf and diagram packages.
Same issue.{sign user="xavi" datetime="2022-01-22T23:32:38+00:00"}

At https://tiki.org/forumthread70022-mpdf-Generates-Black-PDF-docs

Logged, I tried to check the PDF feature by going to the "Thread actions", click on the item "PDF".

It downloaded a blank document onto my computer.

Tested on Tiki24 still here.

some images are printed, but some others are not, and they seem to need to have no other params params than the minimum, however, using standard syntax from a brand new tiki site embeds wiki pages with a syntax that mpdf is not able to make it just work, and images are not shown in the pdf produced.

Reproduced here:
http://seeds4c.org/Ubuntu+16.04+LTS+for+Human+Beans
(you can produce the pdf by yourself there)

Code that mpdf doesn't seem to like:
{CODE(ln="1" colors="tiki")}
{img src="display466" link="display466" width="400" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"}
{img fileId="60" thumb="box"}
{CODE}

Code that mpdf seems to like:
{CODE(ln="1" colors="tiki")}
{img src="https://www.hecticgeek.com/wp-content/uploads/2012/09/Editing-the-disable_wol-script-in-Ubuntu-12.04.jpg"}
{img src="display550" width=600}
{CODE}

(removed the examples with params like src="dl437&display" since they were written by the time when tiki accepted that oldish syntax by mistake){sign user="xavi" datetime="2018-07-24T23:05:08+00:00"}

---
Update: {sign user="xavi" datetime="2018-06-21T11:04:30+00:00"}
In a production server in our work, no images are shown in the pdf at all, with neither syntax. Is there any log file with potential information on why no images are shown in the pdf produced by mpdf?
I confirm that we have php7.0.* and php modules gd, & mbstring installed server side.

Xavier

I removed "19.x" categorization because branch 19 doesn't exist yet. The category "regression from version 18 to 19" is accurate here and already assigned. {sign user="chibaguy" datetime="2018-07-12T07:46:41+00:00"}
---
Update answering luci (Why can't standard users reply to comments, such as my user "xavi" wit no admin rights? :-/ ). Answering here instead (lacking time):{sign user="xavi" datetime="2018-07-24T23:02:41+00:00"}
* replacing that old syntax with new and valid syntax (? intead of &) still yields some broken images in the pdf produced by mpdf. I granted access to amnabilal to a server where she can reproduce. I didn't hear any more feedback from her about it, but I confirm that this issue still exists in several servers of mine, with different setups.{sign user="xavi" datetime="2018-07-24T23:02:41+00:00"}
---
Update: Default syntax with param -+thumb="box"+- keeps images away from the printed pdf (even with valid https cert and fully valid params aside of mpdf) {sign user="xavi" datetime="2018-11-26T22:16:13+00:00"}
Example:
{CODE()}
{img fileId="60" thumb="box"}
{CODE}
---
Issue with -+thumb="box"+- or -+thumb="zoombox"+- for instance, confirmed still in 21.5vcs as of today {sign user="xavi" datetime="2021-11-19T16:14:52+00:00"}

internal wiki links are not clickable nor converted to the absolute url counterparts in the pdf when the option to show links at the bottom is selected in the tiki admin panel.

Reproduced here:
http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=Tiki-Wiki-CMS-Groupware
u: admin
p: 12345

Current code used in the show instance:
--SVN (24.0vcs): Tuesday August 3, 2021 17:34:21 CEST - REV 78798 (InnoDB) --

Upgraded today (server side) to latest 24.x branch: r79594 (Last Changed Date: 2022-01-22 14:46:09 +0100 - Sat, 22 Jan 2022)

In that page, there is an internal wiki link to HomePage:
{CODE()}
((HomePage))
{CODE}

The user would expect to have that link converted in the pdf as a link to:
http://xavi-9794-6688.show2.tikiwiki.org/tiki-index.php?page=HomePage

but it's not converted to any link, it's just shown as simple standard text (with no indication that it refers to another page in that tiki site)

See the pdf produced by mpdf for instance here:
{file type="gallery" fileId="1563" showicon="y"} (using trunk from august 2021, r78798)
{file type="gallery" fileId="1706" showicon="y"} (using branch 24.x Jan 2022, r79594)

Printing a structure with mpdf, some things are not printed properly:
* Footer (or header) {PAGETITLE}
A wiki page itself can be printed to a PDF, and {PAGETITLE} __in the footer __ will be translated correctly to the footer. But once the same page is printed as part of a structure, {PAGETITLE} in the footer will only produce a void.

* Plugin Last Modification
A wiki page itself is printed to PDF correctly showing the value for {lastmod}. If the same page is printed as part of a structure, {lastmod} will not be translated.

Working in wiki page alone:
{img fileId="1440" thumb="box"}

Bug in structure:
{img fileId="1439" thumb="box"}

{syntax type="tiki" editor="plain"}
Error "Out of range value for column 'entryId' at row 1" appears whenever modifying almost any content.

I have documented the problem and a workaround here:
* [https://doc.tiki.org/Troubleshooting?page_ref_id=4835#Ancient_Tiki_triggering_error_Out_of_range_value_for_column_entryId_at_row_1_on_every_change_advanced_|https://doc.tiki.org/Troubleshooting]

Maybe we should add a way of doing this automatically whenever necessary (every 10 years or so?)

Explaining the way to reproduce the issue;

Using a default Tiki21;
Set storage to use directory
Enable batch-upload and set the batch-upload directory

Upload folders with files in the batch-upload directory
Run the following in your terminal (change the fileId for the gallery you want):
~pp~php console.php files:batchupload 1 --subdirToSubgal --createSubgals —confirm~/pp~

It will create the subgalleries and place the files in each subgalleries.
You’ll have ~~#F00:1~~ file in your file directory for 1 file in your file galleries.

Redo the same operation with the same files and folder.
It will add a version to the previous files.
You’ll have ~~#F00:2~~ files in your file directory for 1 file in your file galleries.

Etc... It will add a file each time.

To illustrate:
{img fileId="1359" thumb="box"} {img fileId="1358" thumb="box"}

You may want only to store 1 file (especially if you have automatic script running that is the most important reason to use the console command)

---

How to limit the number of stored file per file in the file galleries.

In each file gallery subdirectory there is a setting "Maximum number of archives for each file" that is set to 0 (meaning unlimited).

As the file subgalleries are created by the console.php they are create by default with unlimited.
We need a way to set the value by default for all new created subgalleries.

I suggest a new parameter to set by default (for all new gallery) the maximum of version (archive) per file.
Eventually a parameter to override it in the console.php command.

We receive many issues while people try to register. So I went to test out what is going on... While testing new user registration in new incognito mode Chrome I got this when I submitted the filled in form:
{img fileId="1361" thumb="box"}

Not a good feedback to the user trying to register :(

Steps to reproduce:

# open new incognito window
# go to https://tiki.org/login
# click the Register link in the login form which brings you to https://tiki.org/tiki-register.php?key=randomstring
# fill in the form and click "Register" button
# you get the error screen

__Anyway, the user was created.__
As an admin I received immediately a watch notification email first:
^__User joined Registered__
The user lucitest joined Registered%%%
at: Sun 23 Feb 2020 17:13 CET^

Then --after some minutes (17:21 CET)-- 17:14 CET I received "Community Members Information" tracker email about the Item Creation too __with no link to validate the user__ (but at that time I validated the test user manually already).

We also receive many registration attempts (in comparison as seen while watching user joining Registered group) __without__ any tracker or validation link emails coming out / being received at all.
---
Confirmed sadly {sign user="jonnybradley" datetime="2020-03-09T17:22:33+00:00"}

Hello,

tried to do fresh installation of Tiki-21 (from *.xz tarball) on my production server and the installer seemingly choked after selecting "Inno DB", iow. pressing the button did not show any effect and it looked as the installed just died.

After several attempts, I had to leave the process working for some time having some non computer-related tasks to do and after returning back to the computer, discovered that installer did finish the job, but no progress-bar dialog was visible, although the feature did work during my testing of Tiki before release, so it is certainly a regression.


Sincerely,
Gour