@rflaraujoweb Do you use any sitemap component?

no

I just updated joomla I'm just using helix 3 and akeebackup

erro: Cannot use object of type stdClass as array

Caused by #20313 as noted in #20878

@rflaraujoweb Please have a Look at #20878, #20874

@rflaraujoweb so i would disable 3rd-Party Plugins one by one and ask help on the forums. This repository concerns in first Place Joomla-Core coding. For this Reason closing this Issue, thanks.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/20879

It is a bug, rather a regression introduced by #20313.

I am having the same problem, I have a basic site no 3rd-party plugins, only what is installed with Joomla. I upgraded to 3.8.9 and the issue began, so I tried upgrading to 3.8.10 to see it that would fix the problem, no dice. Any thoughts?

I cant reproduce this in the last staging....

I found that Helix3 was causing the issue. I disabled Helix3 - Ajax and System - Helix3 Framework and the issue went away.

Then @mbabker this is not related to the core, right?

Again. The root cause is the change in #20313.

You can disable extensions all day and try to play the "this isn't a core problem" game. The regression affects extensions which use the plugin system to hook forms, one of which specifically being the menu item form. Core on its own does not do this, to trigger this regression you MUST have a plugin hooking onContentPrepareData event working with the com_menus.item context.

No, I not like play games. Thank you for the explanation.

For helix3

Enabling Debug gives

0 Cannot use object of type stdClass as array

Call stack
\# 	Function 	Location
1 	() 	JROOT\plugins\system\helix3\helix3.php:55
2 	plgSystemHelix3->onContentPrepareForm() 	JROOT\libraries\joomla\event\event.php:70
3 	JEvent->update() 	JROOT\libraries\joomla\event\dispatcher.php:160
4 	JEventDispatcher->trigger() 	JROOT\libraries\src\MVC\Model\FormModel.php:321
5 	Joomla\CMS\MVC\Model\FormModel->preprocessForm() 	JROOT\administrator\components\com_menus\models\item.php:1254
6 	MenusModelItem->preprocessForm() 	JROOT\libraries\src\MVC\Model\FormModel.php:242
7 	Joomla\CMS\MVC\Model\FormModel->loadForm() 	JROOT\administrator\components\com_menus\models\item.php:552 
...

Edit file plugins\system\helix3\helix3.php

Add at about line 54
(or better at the beginning of method onContentPrepareForm)
$data = is_object($data) ? (array) $data : $data;

I think this two have related issue #17700 and #20275 (comment)

If we had typed Event objects like what the newer 4.0 event dispatching API offers, honestly #20313 would've never passed.

class PrepareDataEvent
{
    public function __construct(string $context, array $data) {}
}

Funny enough, in the cases fixed by #20313 those dispatches wouldn't have worked correctly to begin with because in practice the event signature is this when used anywhere else:

class PrepareDataEvent
{
    public function __construct(string $context, object $data) {}
}

So, it's an awkward as all hell thing to actually address. Because to fix it means reverting #20313 and plugins have to do a lot more work to determine the data type since essentially in practice we've told them "this argument can be either an array or an object, and it's on you to figure out how to work with that data source, oh and you should probably ensure you return the data in the same type it was passed in so you shouldn't arbitrarily cast an array to object and leave it that way". Or, you accept what is essentially a B/C breaking change in the data model for the data passed to this event in these two cases, which only slipped by because we have a loose typed API and no type validation before the event was triggered.

Either way, it's not good.

#17700 is totally unrelated.

The issues you've experienced with #20275 are in part the exact issue we're describing here (some code paths are dispatching these plugin events with objects and some with arrays and there's no real consistency).

I really think #20313 should be reversed and new release done quickly then put into J4. It's a big BC break and it's breaking a lot of sites.

Someone needs to then document the expected parameter types for the onContentPrepareForm and onContentPrepareData events, with clear documentation on the exceptional cases and how to deal with those differences. Break or not it is also a major inconsistency in the API that requires exceptional handling by extensions and must be clearly documented as such.

And I agree with that @mbabker but it's an incremental release, it should break nothing what so ever. This is what J4 was for so changes like this can be quickly picked up by developers.

I'm not turning around to rush out another release. I'm pretty sure there would be a lynch mob at my door if we did a third release in a week (not to mention I really don't feel like working Saturday to make up all the time/pay I'd miss from work this week on releases).

This needs to be thought through and decided on before next release because there are implications either way, and considering extensions are making changes and releases because of it a flat out revert creates even more headaches for them at this point. I'm not arguing in favor of either stance at this point, both have their merits, but both have their baggage that needs to be weighed.

In which case I suppose that’s the answer, there is no point in fixing it later since developers will already be adapting their extensions to try and work with both arrays and objects. It’s just the native outpour we will be having because peoples sites are going down on an incremental release.

I thought changing an array to an object was against Symver because it’s a structural change.

On 27 Jun 2018, 14:30 +0100, Michael Babker notifications@github.com, wrote:

I'm not turning around to rush out another release. I'm pretty sure there would be a lynch mob at my door if we did a third release in a week (not to mention I really don't feel like working Saturday to make up all the time/pay I'd miss from work this week on releases).
This needs to be thought through and decided on before next release because there are implications either way, and considering extensions are making changes and releases because of it a flat out revert creates even more headaches for them at this point. I'm not arguing in favor of either stance at this point, both have their merits, but both have their baggage that needs to be weighed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Had I realized that before I would've said something. Hindsight is 20/20.

To counter that though is the argument that these cases were inconsistent and in a strictly typed API the inconsistent cases would've raised errors on their own (see my earlier comment on this thread). So from a strictly PHP perspective, if we had said typed API and changed method signatures to remove the type declaration on the $data param that too is a B/C break in PHP 7.1 and earlier (7.2 allows this type of contravariance). That's why it's a lot more involved IMO than simply reverting the PR.

I have just updated and I also receive the error reported on this post, if I try to modify / create a new menu item. But if I try to activate debugging I always have an "HTTP ERROR 500", how can I get more details?

@2of7 Please create new topic in Migrating and Upgrading to Joomla! 3.x forum and run Forum Post Assistant and include results in first post.

It’ll be a BC issue, make sure all plugins are up to date. Hopefully the developers of the plugin causing the issue have done it for you.

Many thanks

--
Tony Partridge
On 3 Jul 2018, 15:28 +0100, Wojciech Smoliński notifications@github.com, wrote:

@2of7 Please create new topic in Migrating and Upgrading to Joomla! 3.x forum and run Forum Post Assistant and include results in first post.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Thank you, this comment helped to solve the problem:
https://issues.joomla.org/tracker/joomla-cms/20879#event-369023

For helix3

Enabling Debug gives

0 Cannot use object of type stdClass as array

Call stack
\# 	Function 	Location
1 	() 	JROOT\plugins\system\helix3\helix3.php:55
2 	plgSystemHelix3->onContentPrepareForm() 	JROOT\libraries\joomla\event\event.php:70
3 	JEvent->update() 	JROOT\libraries\joomla\event\dispatcher.php:160
4 	JEventDispatcher->trigger() 	JROOT\libraries\src\MVC\Model\FormModel.php:321
5 	Joomla\CMS\MVC\Model\FormModel->preprocessForm() 	JROOT\administrator\components\com_menus\models\item.php:1254
6 	MenusModelItem->preprocessForm() 	JROOT\libraries\src\MVC\Model\FormModel.php:242
7 	Joomla\CMS\MVC\Model\FormModel->loadForm() 	JROOT\administrator\components\com_menus\models\item.php:552 
...

Edit file plugins\system\helix3\helix3.php

Add at about line 54
(or better at the beginning of method onContentPrepareForm)
$data = is_object($data) ? (array) $data : $data;

Awesome!!

Can this be closed?

Closed, please reopen if needed.