Category: Regression

After upgrade from tiki 16 to trunk, index rebuild fails.

{CODE()}php console.php index:rebuild
PHP Notice: Undefined index: pass_chr_num in /var/www/trunk/lib/user/blacklistlib.php on line 51
Started rebuilding index...



[TikiDb_Exception]
Specified key was too long; max key length is 1000 bytes{CODE}

After upgrading from 1.9.11 to 2.2, the Last Files module is showing up empty.

After upgrading from 1.9.3 to 1.9.9, the DB-based sessions do not work unless the user select the remember me option when logging in.

{syntax type="tiki" editor="plain"}
Ajax seems to be buggy and producing a serious bug which duplicates the content of wiki page edit under some circumstances.

[[10:07] chibaguy Yeah, I've seen a number of complaints about that in the tw.o forums.
[[10:08] xavi It's been reported as such by some users and they discovered that disabling ajax solved (as a workaround) the issue. And the issue is a big bug (I suffered from it in tiki 3 something a few months ago)
I was going to fill a bug, but dev.tw.o down nowadays to me
[10:10] xavi that's the recent bug report in he forums, where they talk about the disabling-ajax workaround:

[http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=34537&topics_offset=5&topics_sort_mode=lastPost_desc&forumId=4]

----
See similar bug (but not related to ajax) here, reproduced also with 5.0rc2:
http://dev.tikiwiki.org/bug3211

===WAS: Alias Donation not working on t.o===
On Google I was looking for "Tiki Wiki Donation".
I get a result and this is the link:
~pp~https://tiki.org/tiki-index.php?page=Donation&structure=Donation~/pp~

But it goes to a non existing page that need to be created.

If I go at https://tiki.org/Contribute-to-Tiki I see this page as a "Donation" alias.
Something is not working as expected. (removing &structure=Donation doesn’t help).

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

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

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

---

===Update: 2021-05-19===
Now on Google when you look for "Tiki Wiki Donation", the output is:
* https://tiki.org/sheet15 : a public sheet that display 2011 donations (===anonymous can see !===)
* https://tikiwiki.org/sheet15?parse=edit : an error page (Permission denied: feature_sheet)
Not really an improvement of the situation... ?

Note: Googling "Tiki Donation" output is:
* https://tiki.org/Contribute-to-Tiki
* https://tiki.org/sheet15 : a public sheet that display 2011 donations (===anonymous can see !===)
* https://tikiwiki.org/sheet15?parse=edit : an error page (Permission denied: feature_sheet)
There too it is not really optimal

See http://doc.tikiwiki.org/tiki-pagehistory.php?page=File%20Gallery%20for%20Images&preview=10

If you use align=center inside a ~np~{img}~/np~ the image will be displayed floating in middle of the text. This is a regression, align=center used to work well in previous versions.

Hello,

Relating to id2936 id2950 and another id lost (mine but when the author was not set always into track id data's.

It remains impossible to an admin to changed quite anything depending of admin (can create wiki, articles) but not to end any admin task.

The action as, change a user prefs etc, disconnect admin and send the ERROR Connect page __access not allowed__ so the corresponding sites are dead sites.

An installation of 3.3 or upgrade to 3.6 must be done again from database backup.

The problem is that if users has been connected between the upgrade and the necessity for admin to make some changes (I have made...) I had to manually add articles and wiki pages from sql.

We must admit that upgrade from 3.x to 3.x is impossible in some cases unknown, not yet found

I test today if an upgrade 4.2->4.3 had an effect but none.

trebly

I dunno when this stopped working, but it's definitively not working any more in Tiki12.

See the Featured profile: https://profiles.tiki.org/Personal_Blog_and_Profile_12x

See this:
{CODE(colors="yaml")}
objects:
-
type: blog
ref: personal
data:
title: $profilerequest:Blog Title$My Personal Blog$
description: $profilerequest:Blog Description$Random daily thoughts and travel stories$
user: $profilerequest:Blog Owner$admin$
allow_comments: y
{CODE}

However, once the profile is applied, comments are not allowed yet on that blog.

The documentation for the blog handler says both things comments and allow_comments:
https://profiles.tiki.org/Blog%20Handler

I tried both things, and none of them works for me.

Maybe some bug was introduced somewhere?

I had a look myself but unsure how to fix. (profile internals are not within my expertise)

Reproduced in the show instance:
u: admin
p: 12345

Applied the profile, and when the blog is edited, "Allow comments" is still unchecked:
http://xavi-9794-5157.show.tikiwiki.org/tiki-edit_blog.php?blogId=1

On a Tiki22 I had the following in a module displayed at the top area.

{CODE()}
{LIST()}
{filter content="2" field="tracker_id"}
{filter content="{{user}}" field="tracker_field_childrenFamilyName"}
{output template="child_picture_inner.tpl"}{ALTERNATE()} {ALTERNATE}
{FORMAT(name="picture")}{display name="tracker_field_childrenPicture" default=" "}{FORMAT}
{LIST}

{LIST()}
{filter content="3" field="tracker_id"}
{filter content="{{user}}" field="tracker_field_parentsFamilyName"}
{output template="child_picture_inner.tpl"}{ALTERNATE()} {ALTERNATE}
{FORMAT(name="picture")}{display name="tracker_field_parentsPicture" default=" "}{FORMAT}
{LIST}
{CODE}

A user have an item in one tracker or the other.
And so pictures here (tracker2) or there (tracker3) not in both so it worked ok.

This code using Tiki22:
If you have a picture in tracker3 and not in 2 then if you have a picture in tracker2 but not in 3.
{img fileId="1574" thumb="box"}
{img fileId="1575" thumb="box"}

Same code using Tiki23:
Chrome
{img fileId="1576" thumb="box"}

Safari
{img fileId="1577" thumb="box"}

The anchor link on title (h1, h2, h3) are now always displayed even if I don’t mouseover.

Pretty ugly :)

{img type="fileId" fileId="1134" thumb="box"}

I didn’t see that on dev... Only on instance for 17.x is a weird situation...

In the current (r22100 or so) trunk, the switch-theme module (or url tiki-switch_theme.php) only works for logged-in users. This is a regression from just a few days ago. Anonymous users need to be able to change the theme, for example at the themes demo site.

The switch-theme module appears to work without error but when the page refreshes, the theme hasn't changed.

I'm not sure of the revision when this started, but anon can change theme in my install of exported files dated Oct. 3 (approximately r21960), but by Oct. 6 in my updated trunk (approximately r22000), it's no longer possible.

Attempt to apply Personal Blog and Profile on clean 18.2 install does fail.

Here is the [http://gour-11559-6743.show.tikiwiki.org/tiki-wizard_admin.php|show.tiki.org] instance which shows the problem:
u: admin
p: 12345


__Edit:__ Here I also include screenshot with the error after trying to apply profile from within Control Panel (as advised in #tikiwiki):
{img fileId="1208" thumb="box"}

This is flagged as a regression but it is in both 12.x and 13.x so may be an old bug ....

... but when a newsletter previously created with the wysiwyg editor (ie it has had the various HTML flags set), it shows the raw html when it is retrieved from the archive for simple viewing - but it is OK if retrieved for immediate resending

.. just to confirm that this is still a bug in Aug '15 at r 55993

Please see image

The footer of doc.tiki.org has:
Argument 6 passed to Symfony\Component\Process\Process::__construct() must be of the type array, null given, called in /var/www/virtual/doc.tiki.org/html/lib/core/Tiki/Process/Process.php on line 20

{syntax type="tiki" editor="plain"}
Testing how custom attributes work when creating an article, I added a new custom attribute on the article types page (tiki-article_types.php), which added a new input on the advanced tab of my articles edit page (tiki-edit_article.php?articleId=3#content-edit_article1-5). I input text for the data of the attribute and published the article, and it worked fine (the attribute name and data displayed at the top of the article text). But when I tried to re-edit the article, I got this error:

{CODE()}Fatal error: Uncaught TypeError: Cannot access offset of type string on string in . . . \master\lib\articles\artlib.php:1661 Stack trace: #0 . . . \master\tiki-edit_article.php(685): ArtLib->set_article_attributes('3', Array) #1 {main} thrown in , , , \master\lib\articles\artlib.php on line 1661{CODE}

WAS TICKET 6651 (I can't find it anymore) {sign user="Bsfez" datetime="2018-08-19T10:00:56+00:00"}

Since update 18.0 article generator cannot produce articles anymore. It was (and should be able) to built articles from external feeds.

Demonstrated : http://arthurt-11797-6651.show.tikiwiki.org/
I reproduce on the show and I confirm the regression. {sign user="Bsfez" datetime="2018-08-19T10:00:56+00:00"}

On Tiki 15.x REV 59543 setting Articles out of the box;

There is a "un-natural" limitation for Article image size by default.
When I try to save an article with a picture heavier than 1mb (approx.) the article is saved without any error message and no picture is saved.

If I reduce size, the image is saved in the top image gallery without any acknowledgement, selection or choice. (openeing a discussion in the dev list)

It may be a system setting, but anyway, the user should be warned and the article should not be saved with improper picture ommited.

------

Out of the box I went to admin, activate the Articles feature.
I create a new article enter a title, heading, body and an image article.
http://bsfez-11581-6098.show.tikiwiki.org/tiki-read_article.php?articleId=1

The image is within several bootstrap classes (class="col-xs-6 col-sm-5 col-md-3") and it flows under the heading text making this feature broken.

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

{syntax type="tiki" editor="plain"}
As seen in the video attached to this item. (demo tiki)
The own image article is lost if the classification (topic or type) of an article is changed.

To reproduce;
In the Tiki Articles I create an article and set his own image.
I save, the image is displayed.

I edit the article change the topic or the type of the article and save.
The image is gone.
It was working fine, __this is a regression on Tiki 29__.

Currently, when you write __a new__ article at tiki.org and then click the preview button, the page refreshes with all the form empty, so all the inputs and edits are lost. (Seems like I reported this earlier, but the bug list search also didn't work when I tried to find it, so I'm not sure.)

On a quite big and several time upgraded Tiki all unified-index errors were running without errors.
Since a few month I see an error for each article that has the field source filled with an URL.

2022-11-14T07:55:37+00:00 INFO (6): addDocument article 470 {"memoryUsage":"38.5 MiB"}
2022-11-14T07:55:37+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/xxxx/xxxx/lib/core/Search/ContentSource/ArticleSource.php","line":53}
2022-11-14T07:55:37+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/xxxx/xxxx/lib/core/Search/ContentSource/ArticleSource.php","line":56}


{CODE(caption="lib/core/Search/ContentSource/ArticleSource.php, lines 47:59")}
$rss_relations = TikiLib::lib('relation')->get_object_ids_with_relations_from('article', $objectId, 'tiki.rss.source');
$sitetitle = '';
$siteurl = '';
if ($rss_relations) {
$rssId = reset($rss_relations);
$rssModule = TikiLib::lib('rss')->get_rss_module($rssId);
if ($rssModule['sitetitle']) {
$sitetitle = $rssModule['sitetitle'];
}
if ($rssModule['siteurl']) {
$siteurl = $rssModule['siteurl'];
}
}
{CODE}

Normally the "Read more" link of an article (displaying on the articles main page) links to the article's individual page. (From [https://doc.tiki.org/Article-User#Editing_or_Submitting_Articles]: "Source (url) - If appropriate or useful, a reference link can be specified. This displays at the end of the article." ) But in trunk now, if you add a "Source" URL for the article, which is supposed to (and previously did) link to an external URL, then the "Read more" link somehow gets that "Source" URL information.

For example, if my article is based on some announcement from the United Nations, I might put http://www.un.org/ in the Source text field. But of course I still want "Read more" to link to the body of my article. However, now "Read more" links to the United Nations website.

Also the article title, which on the view-articles page is normally a link to the article's individual page, takes on the "Source" URL as well.

In the article actions button group, there's an i18n icon and a chevron, to click to open the translation management dropdown and the article actions dropdown, respectively. But in trunk now, the translation management dropdown opens when both are clicked. The article actions dropdown (containing edit link, etc.) doesn't display at all.

{syntax type="tiki" editor="plain"}
When assigning a new module, the page layout and process for the user have changed. I'm comparing a Tiki 27 to master - I don't know whether all the changes were intentional but it kind of amounts to a "mini-revamp" with maybe a combination of intentional changes and unintentional results.

In Tiki 27, after clicking the "Add module" button, the page that displays has the "Edit module" tab open and a selector to choose the new module and, below that, the "Module Options" button. It's very straightforward and uncluttered. When you click the "Module Options" button, the page opens to the "Basic" tab where you select the module zone for it, etc.

In master, when you click the "Assign new module" button, the same page displays again, cluttered with the tabset containing the module zone tabs and already-assigned modules, with the "Assign new module" button displaying __again__, then down below the tabset is the selector to choose the module. The button was already clicked; it shouldn't display again. The tabset is just in the way. It isn't needed in this step of the process.

I think the problem is because the tabs aren't quite right. Initially when you navigate to the admin-modules page, the tabs are "Assigned modules", "Custom Modules", and "All Modules". When you click the "Assign new module" button, the page displays these tabs: "Configure new module", "Custom Modules", and "All Modules". But the page also displays the assigned modules. These should display under an "Assigned modules" tab, not under "Configure new module". This tab arrangement can be seen after clicking the "Module options" button, after selecting a module. Now the tabs are "Assigned modules", "Configure new module", "Custom Modules", and "All Modules". This is how the tabs should be on the previous page.

There's another problem in that when you do arrive on this page, to edit/configure the module, there are four new tabs: "Basic", "Module", "Appearance", and "Visibility". In previous Tiki versions, the "Basic" tab is open, which is the logical choice. In master, though, the "Module" tab is open and the user has to switch tabs to "Basic" to specify the module zone, module position, visibility to groups, etc. that I imagine are generally set first, and which was the case in older Tiki versions.

I will make a video

{flash type="url" movie="display516" width="720" height="612"}