Our customers realy want to keep the TinyMCE RTE for Umbraco, as they didn’t like the new tiptap editor.
We were told to just use the TinyMCE.Umbraco package, to keep the old RTE as is (we were also told this at the last Umbraco conference in DK). But, there is a problem.
After the upgrade had finished, we saw that all block items in the RTE had lost there reference to the actual block used. The markup for the block was there, but the actual content is gone.
Hi Steffen! I sadly don’t have an immediate answer for you, but could you log it as an issue on the GitHub repository for the package so that we can investigate it with the full details? Thank you!
There were two upgrades in version 15.0.0 and 15.1.0 that somehow did not ran right, when going from version 13 to 16 directly. By jumping to 13 and then 15.2.0, the upgrades ran much better and afterwards all the RTE blocks where back.
But I am not sure why a “extra” step like this, corrects the issue. It only makes me more currious as to what else might be broken, that I just havn’t found yet.
(Just some thoughts more generally about migrations…)
It is odd as you say.. because all the same migrations exist from 13 → 17 (Umbraco maintain migrations between LTS versions..) so you aren’t skipping any for 13 → 15 → 17
If you were say going 10 → 17.. then you’d have missed any 10 → 13 migrations..
But then I do also remember an old post that advised always migrating to the latest version of the major you were on and then stepping through each major upgrade to get to where you wanted to be..
eg 13.8.0 → 13.13.0 → 14.3.4 → 15.4.3 → 16.4.1 → 17.1.0
Another thought, are you taking you DB/setup offline locally and running the migration? If doing direct on production you might find issues with sql timeouts etc.. due to FileIO latency, cpu throttling, network latency etc..
Running locally you can also monitor the console to watch for any migration issues. (more immediate than trawling though logs via the backoffice) Or indeed dump into a local version of SEQ, for much better log viewer interface and search capabilities.
You can always reset the value in the umbracoKeyValue table to one of the guids in that migration plan.. and have the site recycle and rerun the migrations again..
eg resetting Umbraco.Core.Upgrader.State+Umbraco.Core = {7F4F31D8-DD71-4F0D-93FC-2690A924D84B}
would rerun all the v15 and up migrations against the DB
going to v17 from v13.13.0 I had legacy grid data in content versions (the latest and published version had been migrated to blockgrid..
The console simply filled up with failed to migrate {json} to blockgrid.
And MNTP with missing min or min.max set as strings and not integers in the json datatype settings, also were easy to spot in the console/logs
with an expecting integer, found string type message.
Plan Umbraco.Core failed at step {42E44F9E-7262-4269-922D-7310CB48E724}
System.InvalidOperationException: The configuration for data type 2417 : Umbraco.MultiNodeTreePicker is invalid (see inner exception). Please fix the configuration and ensure it is valid. The site may fail to start and / or load data types and run.
—> System.InvalidOperationException: Failed to parse configuration “System.Collections.Generic.Dictionary`2[System.String,System.Object]” as “MultiNodePickerConfiguration” (see inner exception).
@mistyn8 you are right that it is always best to migrate to the latest major version, instead of just going directly to the target version. But I believe that the migrations should be more strict in the way they run. If a upgrade fails to run correctly, or dosn’t run at all, this is where I would love for the upgrade to provide some kind of “this went good - this went bad” report in the end. Otherwise you would never realy know if everything went according to plan. I know that we can use the log and I did, but seing the same output during the upgrade from 13 to 16.1 and 13 to 15.2.0, then this is where the problem solving and debugging get’s hard quicly.
I always generate a database backup and host it locally, just to ensure that i don’t break production when running the upgrade
FYI: To all reading this issue, the problem is not in the TinyMCE.Umbraco package, but the actual 15.0.0 and 15.1.0 Umbraco upgrade, when jumping over the latest version of umbraco 15.
