Re: [Tiki-devel] Concerns with index errors for users upgrading from Tiki21 to Tiki24

Thank you for taking the time to answer me Victor.

> It is not an easy task to do as these errors must be caught by developers in order to produce more user-friendly messages.

Completely aware of this. Actually I can see the object_id in the index log (which is already good) but in this case:

>  In your case, the parser is trying to use a wiki page info structure (array) that is not found in the db. There should be an additional check in the code to make sure the page actually exists before using it and if it is not available, complain with the proper error message. 

Ah if it was just the Wiki page… ;-)
I think this is coming from any text area (supposition).

In this Tiki I’m checking, the Admin used them (a lot + toolbars and in some area wysiwyg) in Wiki pages, in tracker type fields text area, in articles and in forum post…
When I wrote a hundreds I should wrote a few hundreds...

> so I think it is a good idea to have several big databases to test against and we fix as many of these as possible before Tiki 24 is released.

That would be great ! (How can I help ?)

We could also have start a list of know errors (wiki page on doc or dev) with a troubleshooting table (error, notice => possible fixes)

But actually this is too vague for non-developer usage… 
On a hundred check, I caught quickly 3 or 5 errors and fixed (broken wiki link) but I have too many of the same error (/OutputLink.php) without seeing what is wrong.
I guess I need to dig into the index table itself. But that’s not what we want our users to do. ;-)

>> 2021-12-07T07:36:32+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/to.org/httpdocs/lib/core/WikiParser/OutputLink.php","line":125}


Regards,
Bernard

> On 8 Dec 2021, at 12:42, Victor Emanouilov via TikiWiki-devel <[email protected]> wrote:
> 
> Hi Bernard,
> 
> It is not an easy task to do as these errors must be caught by developers in order to produce more user-friendly messages. In your case, the parser is trying to use a wiki page info structure (array) that is not found in the db. There should be an additional check in the code to make sure the page actually exists before using it and if it is not available, complain with the proper error message. There could be numerous such cases especially when rebuilding the index, so I think it is a good idea to have several big databases to test against and we fix as many of these as possible before Tiki 24 is released. I remember fixing a lot of these before Tiki 21 but more seems to come...
> 
> Regards,
> Victor
> 
> On 12/7/21 4:09 PM, Bernard Sfez via TikiWiki-devel wrote:
>> Hello Devs,
>> 
>> I had more and more report (or cases) where perfectly indexed Tiki version 21 found themselves crippled with errors and eventually broken after upgrading too Tiki23.
>> 
>> While Tiki23 is “just” a stable, I guess upgrading to Tiki24 will have similar effect if not worst.
>> 
>> From Tiki18 to Tiki21 you can have “not perfect” Tiki and things will run.
>> Tiki where itemLink tracker have been deleted
>> Forums post containing a wiki link to a page that doesn’t exist
>> An trackeritem categorised with a category that was deleted (I think also if the category nae was changed)
>> An item where a mandatory field is empty (because the item was saved before the field was changed to mandatory, etc)
>> Weird article source: https://www.google.com/url?rct=j&sa=t&url=https://www.super-example.com/details/9781135105433/blabvlabla/&ct=ga&cd=CAIyGTg5MzhkZDZjMGJhMWM1MTA6ZGU6ZGU6REU&usg=AFQjCNHIC2pZkno7Su3uqfD93oKR9qXvfw
>> 
>> When you upgrade to Tiki23 and rebuilt the index you are warned about all this “anomalies” and some prevent the index to complete.
>> This is awesome and great as better Tiki data mean better performance and behaviour, but I have little doubt users will consider this as a regression and start to claim the upgrade broke their Tiki.
>> 
>> Not sure if we have a solution for that.
>> 
>> ====
>> 
>> May be to defuse this problem we should emphasis the fact that we added/improved values control and protection but also make more clear (for admins eyes) the problem to tracker errors and suggest fixes.
>> 
>> In the instance I worked on this morning I have hundreds of :
>> 2021-12-07T07:36:32+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/to.org/httpdocs/lib/core/WikiParser/OutputLink.php","line":125}
>> 2021-12-07T07:36:32+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/to.org/httpdocs/lib/core/WikiParser/OutputLink.php","line":282}
>> 
>> For trackeritems (missing itemLink), for forum post (missing mandatory title), for articles (not yet understood why… wysiwyg 🤔), etc…
>> This in the error log of the index doesn’t help the Power user and it require much more skilled level to understand what to fix or correct.
>> 
>> I wonder if we couldn’t have more explicit error description…
>> 
>> trackeritem206
>> 2021-12-07T07:36:32+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/to.org/httpdocs/lib/core/WikiParser/OutputLink.php","line":125}
>> Description: There is an error in the field 450 (itemLink source is missing)
>> 
>> ...
>> 
>> Regards,
>> Bernard
>> 
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> 
> 
> _______________________________________________
> TikiWiki-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel