V 9.0 breaks my T3 installation

[swissdude]

I just made an update of Flux via Extension Manager to Version 9.0.

After that, all I see is as «oops an error occured» in the backend and a «Class 'FluidTYPO3\Flux\View\PreviewView' not found» in the frontend.

Typo3 8.7.15

Any ideas how to fix this?

[wazum]

Clear the cache and/or update the autoloader information

[swissdude]

Not working. Did both. Now I get «Class 'FluidTYPO3\Flux\View\TemplatePaths' not found»

[NamelessCoder]

You have one or more other extensions that depend on Flux which you also need to upgrade. Either that or you have to remove cached and temporary files via the install tool because the cache flush is unable to complete due to those issues.

[swissdude]

#1574
Sorry guys, thanks for the help, but it ain't working.

I can install the update, but then I try to run the «execute update script». I get to the page that says «Perform migration» and then I get another error Class 'FluidTYPO3\Flux\Utility\PathUtility' not found. And indeed, there's no such file in the updated version.

Just for the record, I'm trying to update using the Extension manager.

Deleting the caches and dumping autoload information in the install tool doesn't help either.

[Edit]

As soon as I activate on of my extension-templates, I get the TemplatePath error again (those templates have grids in them).

[Edit 2]

Now the update script ran - saying there were no updates performed.

But when I activate one of my templates-extensions, I get this error:

Flux could not extract a Flux definition from "path_to_my_extension/Resources/Private/Templates/Content/CenteredContentWrapper.html". Check that the file exists and contains the necessary flux:form in the configured section "Configuration"

But the config is there:

<f:section name="Configuration">
<flux:form id="centeredContentWrapper">
flux:grid
flux:grid.row
<flux:grid.column name="content" label="Content"/>
</flux:grid.row>
</flux:grid>
</flux:form>
</f:section>

When I take out the grid, it works... is grid deprecated???

[swissdude]

As weird as it sounds, it's working - If I only knew what the steps were ;)

One thing I did in the end was deactivating the fluidcontent extension and downloaded the latest version from the dev-branch. Then it said «obsolete» in the extension manager - but without it, my templates wouldn't work. So I activated it and... yeeeha...

Thanks for the patience, guys. I hope I can repeat this on the productive system ;)

[swissdude]

Well, I yeehaad too early.
With the fluidcontent extension activated, I cannot add new elements in the backend. The FluxWizardItemsHookSubscriber is not found in WizardItemsHookSubscriber.php of fluidcontent.

But when I deactivate the fluidcontent, I get the Flux could not extract a Flux definition from... error again...

This is driving me nuts...

[NamelessCoder]

@swissdude Uninstall fluidcontent and make sure you update fluidpages to 4.2.0. If you have other extensions that also depend on Flux, make sure those don't use the classes that were removed.

<flux:grid.column name="content" label="Content"/>

If you had been able to run the install script you would have been warned that you now need to add colPos to all flux:grid.column usages. This is why your templates fail to parse (the error is actually an "required argument not provided" error, the actual message is in the system log, not the message).

One thing I did in the end was deactivating the fluidcontent extension

Leave it uninstalled - it is obsolete and will no longer be updated. Flux has taken over the features it provided. Then see #1542. You will need to perform some SQL queries to migrate your existing content records.

"Flux could not extract a Flux definition from..."

If you keep getting this it indicates that your templates still need to be migrated. It is key that you become able to run the EM update script for Flux since it will detect and warn about each template that must be changed.

[swissdude]

Thanks NamelessCoder for your patience, appreciate it a lot!

I got it working - more or less.
I missed one of the grid-colPos elements in a template (I got like 200 of them), that's why I got that error. I was also able to run the update script and it did change the colPos of a ton of elements.

However, it seems I have to manually set the element type in every element on my pages. I get an orange warning «INVALID VALUE ("fluidcontent_content")» which comes from the old fluidcontent-elements. Could it be that this would be automatically and I just messed it up by switching back and forth? Also, the list in the dropdown where I can select the elements is very long and my own elements all just appear under «Forms». That makes it kinda hard to find the element I need.

And - one last thing, just as a sidenote: Before, there was a nifty little icon that allowed me to collapse the grid-elements that contained a lot of other elements. This was very handy especially for large pages with a lot of elements on them. Did you leave this out on purpose and would it be possible to put that back in?

Again, thanks for your patience and the great work. I don't know what I'd do without flux!

[NamelessCoder]

«INVALID VALUE ("fluidcontent_content")» which comes from the old fluidcontent-elements. Could it be that this would be automatically and I just messed it up by switching back and forth?

You can migrate those elements using SQL queries. In short, you will need to write statements like UPDATE tt_content SET CType = 'myext_lcunderscoredtemplatename' WHERE tx_fed_fcefile = 'MyExt->Templatename.html' - check out #1542, there is a lot more information there.

Before, there was a nifty little icon that allowed me to collapse the grid-elements that contained a lot of other elements.

That should still be there. It sits to the right of the other icons in the header bar portion of the content elements' individual panels. It only gets shown if there is a grid inside the element (so that would depend on a correct CType value). The cookie it sets is the same as before so it should even read your previous collapsed states (it stores the UID of the parent so that doesn't change).

Sounds like you're almost there.

I would recommend however to try to limit the number of templates you use. If you really do have upwards of 200 content type templates that could be bad for your site's performance. If possible, you may want to try combining some of those (for example, if you have several variants of elements that create two columns, you could make the size of columns a value in set in the form, then use the same template for all "two columns" type elements). If nothing else, it makes it a lot easier if/when you do have to migrate something.

Again, thanks for your patience and the great work. I don't know what I'd do without flux!

Thanks for the kind words :)

[swissdude]

Thanks a ton (do you actually ever sleep? ;)

I hope I can figure out those queries ;)

As for the amount of templates: it's a multisite project. I already did what you propose but there are still a lot of unique elements to every site, hence the big amount of elements.

Thanks again for your help!

[NamelessCoder]

It shouldn't be too bad to migrate those, even with that large number of templates. Basically you just need to figure out the logic of how tx_fed_fcefile becomes CType. You can always create a duplicate column and update SQL to copy CType to that backup column before you do anything. Then you can copy that value back at any time.

I'll close this issue since the original problem seems to be solved!