Multisite wrong GCS path

[alimuzzaman]

I see the code that is supposed to handle that but maybe it does not work on multisite. The folder should be /gravity_forms/ in the root of the /wp-content
Can you make sure this works on multisite?
that folder structure on there is like /wp-content/blogs.dir/<blog_id>/files/gravity_forms

[alimuzzaman]

It does not only affect Gravity forms but Multisite in general.

http://multisite.local/site-2/wp-content/uploads/sites/2/gravity_forms/1-f6e9d16c113ac67c274e72c71efe6776/2019/12/9TzAWl3v_400x4001.jpg

In GCS https://storage.googleapis.com/udx-ci-develop-alim/multisite/gravity_forms/1-f6e9d16c113ac67c274e72c71efe6776/2019/12/9TzAWl3v_400x4001.jpg.

@antonkorotkov any thought!

[alimuzzaman]

If we fix the issue, how we will handle existing media?

If the user regenerates existing media then the image will be copied to new location. And there will be duplicates.

[antonkorotkov]

If the user regenerates existing media then the image will be copied to new location. And there will be duplicates.

Sorry, I did not understand why it will be copied to a new location. Can you inspect the flow in detail for me?

[alimuzzaman]

@antonkorotkov

Server URL: http://localhost/multisite/test1/wp-content/uploads/sites/2/2019/12/xyz.jpg

Old URL: https://storage.googleapis.com/udx-ci-develop-alim/multisite/2019/12/xyz.jpg

New URL: https://storage.googleapis.com/udx-ci-develop-alim/multisite/sites/2/2019/12/xyz.jpg

Here

• multisite is Bucket Folder.
• localhost/multisite is a WordPress installation.

Prior to now, we didn't have sites/2/ (sites/<blog_id>) in the GCS URL.

Now if we synchronize image after making changes considering sites/<blog_id>,

1. The image will be downloaded from GCS and all sizes will be regenerated.
2. The image will be synced to a new location considering the sites/<blog_id>.
3. The old copy of the image will be still there.

[ewsopp]

@antonkorotkov please provide some insight here. We need to get this right.

[antonkorotkov]

@alimuzzaman I don't think we have many options here.

We can:

1. Leave copies as is and add some notice that we changed the way multisites are handled, so copies could be safely removed from the bucket manually if they don't need them.
2. If possible, we could track what files were regenerated to the new location and delete old ones later, but I think this is pretty hard to implement (I don't know how right now). This option may be a bit dangerous since before deleting anything need to be sure we will not lose any media.

I personally, prefer the first option because the old media can play the role of backup for some installations. @ewsopp Do you have any thoughts?

[ewsopp]

I think we start using the proper/updated path for new uploads and maintain existing paths for previously uploaded media (regeneration). Is that easy enough?

[antonkorotkov]

@alimuzzaman what do you think about this? I'm not sure if that is something we can do.

I think we start using the proper/updated path for new uploads and maintain existing paths for previously uploaded media (regeneration). Is that easy enough?

[alimuzzaman]

@ewsopp Yes, that's easy enough.

With the current code in Multisite branch:
When users regenerate old media image will be copied to a new location. And the previous image will be still available.

@antonkorotkov
But if the user has a large amount of media then there will be lots of disk image uses.

Maybe removing them can be optional, via sync tab.

[alimuzzaman]

@ewsopp @antonkorotkov
Do we need this if we solve issue #149 (wildcards for bucket folder settings)?

This solution could break things without users realizing it.

[ewsopp]

I think so, but I'll come back with some additional notes.

[alimuzzaman]

Closing this since it is being handled at issue #149 and #284.