@AndySDH Please consider testing. Thanks!

I have tested this item ? unsuccessfully on 237dc74

After update to Joomla 4, the Joomla 4 dashboard became unusable. The errors hint to the fact that the database was not updated in the process.

Hmm. Without this PR, does the update works well for you?

I have to try it out. Will keep you posted

OK. Thanks @obuisard

I can confirm: the error does not come from the PR, the update from 3.10 alpha 6 dev to Joomla 4 beta 8 dev (update package) fails.

@obuisard Maybe you can raise a new issue for that? If you can let us know step by step what you did and got that error, that would help us to check to see why it happens and get it sorted

I followed the exact test instructions.
Except that upon update, the files are updated, not the database.
In the console, I get 1093 You can't specify target table 'y2jza_template_styles' for update in FROM clause
When I look at the database, the template_styles table has not been updated.
I will test with 'official' releases, not the nightlies to see if that is inherent to the fact that they are nightlies (and may be unstable).
If updating from 3.10 alpha 5 to Joomla 4 beta 7 fails, I will open a new bug issue.

I faced the same issue that @obuisard mentioned with the 4.0-dev nightly package without the PR as well as with the PR. Although, the article section in the one without the PR seems to be usable now, I don't know how that happened. Sadly, I can't say the same about the one with PR because I deleted that installation.

Since then, I have created two new Joomla 3 fresh installations and upgraded them with the 4.0-dev nightly with PR package and tested both of them successfully(one on Microsoft Edge, other on Firefox Private Window).

I have tested this item ✅ successfully on 237dc74

I have tested this item ? unsuccessfully on 237dc74

Using the provided files the update works but, the Joomla article layout is missing all settings tabs. This was before and after the patch after update to J4! So in both situations I couldn't check if the fields are there or not. I can confirm that the custom fields values are present in the DB after upgrade.

@RickR2H This PR just do the data migration, so the issue with Joomla articles layout might be un-related. After the update, could you please update your site to latest Joomla 4 nightly build package which can be downloaded here https://developer.joomla.org/nightly-builds.html , then check it again to see if articles layout is sorted?

No matter what I have tried, I was unable to successfully update from 3.9.10 Alpha 5 or 6-dev to 4.0 beta8-dev or 4.0 beta8-dev with the patch. I am going to file a bug report or is Joomla 3.10 not even ready for a direct update to Joomla 4?

No matter what I have tried, I was unable to successfully update from 3.9.10 Alpha 5 or 6-dev to 4.0 beta8-dev or 4.0 beta8-dev with the patch. I am going to file a bug report or is Joomla 3.10 not even ready for a direct update to Joomla 4?

@obuisard Updating 3.9.10 Alpha 5 to 4.0 beta8-dev should work. If not, open an issue please. Thanks in advance.

Today, I synchronize this branch with latest 4.0-dev. Tested it again and it worked. Update went well, data is migrated properly. Could you please help testing again one more time?

.. update works but, the article layout is missing all settings tabs. (only in the artcile that have had repeteable before migration)

Could you show me a screenshot? Strange it is working well for me. Here is screenshot for my test article

sure
this is when edit the article that have fields before migration no tabs

this is when edit the article with no fields before migration tabs

I have no idea. Maybe I should setup test articles with and without fields and testing again. Or maybe you can send export and send database of the updated site to me for debugging purpose? I sent you a message via Glip

weird

Strange, too. I use your database and here is the article screenshot, no error like in your test. Maybe the difference is I'm using Window ?

How did you perform updating? I download the package here https://ci.joomla.org/artifacts/joomla/joomla-cms/4.0-dev/32611/downloads/41493/Joomla_4.0.0-beta8-dev+pr.32611-Development-Update_Package.zip, then go to Components -> Joomla Update, Upload & Update tab to upload the package and update

I have the same error like @alikon on Ubuntu. systeminfo-2021-04-02T13 54 44+02 00.txt

@astridx I'm unsure what's wrong with the update as when I use the database from @alikon , import it to my site, the article is working well. Maybe you can confirm that by configure your fresh Joomla 4 installation to use the migrated database?

I mean the data migration process works OK, I just don't know what part of the update process causing that error (the js error from browser console looks strange to me)

Our updates currently are missing the deletion of this or that file or folder on update, i.e. after an update there might be files still present which should be removed. It's the usual thing with the files and folders deletion in com_admin's script.php not being up to date. It's a work in progress to improve that maintenance task and automate it as much as possible. It's just my guess that something like that might cause the issues.

@astridx I'm unsure what's wrong with the update as when I use the database from @alikon , import it to my site, the article is working well. Maybe you can confirm that by configure your fresh Joomla 4 installation to use the migrated database?

I mean the data migration process works OK, I just don't know what part of the update process causing that error (the js error from browser console looks strange to me)

I can confirm this. I just cloned a new 4.0-dev branch and copied the configuration.php from the failed test.
Now I can edit all tabs of the article.

If so, please check the migrated data. If the migrated data for repeatable form fields is OK, I would say that this is a successful test.

The error which you are having here could cause by some files left during update (as explained by @richard67) and it is unrelated to this PR. This PR just focus on data migration only

The data was correct, there were only two text fields with simple texts.

If so, I would say that it is a successful test?

yes for me

I have tested this item ✅ successfully on 5af3c9a

@astridx Would you say your test was successful? If yes, please mark your test result. Thanks in advance.

RTC

I've restored @sksuryan 's successful test in the tracker so it's properly counted. The changes after that test which have invalidated the test result was only code style and quote names added.

OK let's get this in. Thanks!

I tested this and it looks ok only error message I get which I'm not sure if it's related after update for a media file:

<b>Warning</b>: Illegal string offset 'imagefile' in <b>/plugins/fields/media/tmpl/media.php</b> on line <b>31</b><br />
 

@HLeithner : Does the media file a part of repeatble field which we are migrating data to SubField?

@joomdonation yes

@HLeithner Could you send me a copy of the migrated database (maybe via Glip) so that I can debug (prefer sql format)?

sure

@HLeithner I can confirm the issue with media field type. The reason is because in Joomla 3, data for the field is stored in string format (something like images\powered_by.png) but in Joomla 4, we store it in JSON format (something like {"imagefile":"images/powered_by.png","alt_text":""}

Look like when media field is used alone, the plugin do that conversion itself https://github.com/joomla/joomla-cms/blob/4.0-dev/plugins/fields/media/media.php#L78-L88 . But when the field is used in subfields, it is not converted yet

Not sure if we can do that conversion somehow when media is used on subfields? Do you have any idea ? Or maybe @laoneo know a way?

Of course we can do that format conversion in the migration code but I'm unsure if that's the right away?

One more thing, we might have problem with media field (uses alone, not related to this PR). In Joomla 3, we just store path to the image but in Joomla 4, it also store size of the image {"imagefile":"images/joomla_black.png?joomla_image_width=225&joomla_image_height=50","alt_text":""} . From my quick test, without joomla_image_width and joomla_image_height, the image is not being displayed (with and height of the img tag set to 0 for some reasons)

I think that was a @dgrammatiko thing for lazyloading, maybe he can help us here.

I think that was a @dgrammatiko thing for lazyloading, maybe he can help us here.

As I read the comment I think this has nothing to do with lazyloading but rather the fact that the particular custom field now stores also the alt data. The lazyloading is still done with a string (appending some query params, which was hugely controvesial and there were arguments) but we kept it as a string for the shake of B/C. I guess Brian could have some insights on the implementation of the alt attribute (I don't think I was involved in that)

From my quick test, without joomla_image_width and joomla_image_height, the image is not being displayed (with and height of the img tag set to 0 for some reasons)

The image needs to be processed with

Edit the implementation is buggy, there needs to be a check for width and height before setting the attributes otherwise the defaults (for images without extra params) are 0, will do a PR to fix this

@joomdonation can you check #33093

@HLeithner The warning should be solved by PR #33094 , could you please take a look at it?