[Resolved] WPML can't be deployed via Rsync

Hello,

Thank your for your answer, but,

> I understand but the problem is not WPML it is rysnc command.
WPML is the ONLY plugin affected by this issue. We have about 50 plugins on our site. The only one creating this issue is the WPML plugin.
As mentionned in this issue (https://wpml.org/forums/topic/when-already-using-composer-and-rsyncing-project-to-server-it-throws-an-error/#post-11109513), it looks like there is probably an issue between rsync and the composer installers included in your plugin (I am pretty sure this issue comes from sitepress-multilingual-cms/vendor/otgs/installer).
All others plugins I have also include a composer file.
My main site also include a composer.json as root (it is a bedrock-like stack), like mentionned in the other post.
The guy on this on this topic pointed an issue which is actually real. I just tried to give the additional answer you were asking for: a step-by-step to reproduce.
It's not only an rsync issue, it is about the composer installers being ran after the plugin is deployed through rsync. And it should not happen.
We should actually be able to upload the plugin through FTP, rsync, or the wp-admin, without any differrence. That's not the case.

I am not saying the issue comes more from WPML than rsync. I am just saying that both are conflicting with each others. As I said, there's probably a file that needs specific permissions, and that would be great if, as developers, we could know which ones, so we could still be able to deploy sites without a single plugin crashing the whole process.

> It is possible that not all files are not copied.
The answer is no, as stated in the initial topic :
"Before you ask, after rsyncing, I used scp to download back all the files locally, and git did not find any differrence, any modified or missing file."
However, git does not check permissions.. That's why I guess it can actually be the real culprit.

> 1. You can try -v parameters to check the output of command.
I'll try that and let you know.

> 2. Also use --delete-before to delete previous files before copy.
I tried to deploy on a fresh instance, meaning that actual folders on the destination server were totally empty. I'll still try but that's not the issue.

> I am sorry, but we can't do much here unless you are sure it is WPML's fault.
I gave a step-by-step to reproduce the issue. Not sure what I can do more to confirm there's an issue with the composer installers from WPML.
This issue was inexistent on earlier versions.
However, if you need me to build an example stack, that would be pretty simple. But would you try? It just requires to create a WP instance from a root composer file, by loading johnpbloch/wordpress for example, and then rsyncing the whole site to a server. Once uploaded via rsync, you just won't be able to activate the plugin, and will get, instead, the mentionned errors.

> Also, please look at the path
> Your target is /var/www/mysite.dev/public/wp-content/plugins
My paths are correct. The fact you see an issue there is because I manually changed them while writing my topic to hide sensitive data, since those posts are public. I just made a typo while trying to hide sensitive data.

Regards.

Hello,

I figured out that Rsync is not the issue.

Like @juslintek from the linked post, I am using a similar workflow, but completely differrent tools:
- like him, I am cloning a repository which includes the WPML plugin, and a composer.json root file.
- like him, I am running a composer update command with some productions arguments (I think this is where the issue actually comes from).
- like him, I then push the whole directory to the remote servers via rsync.

Rsync is not the issue since I can actually locally unzip the WPML plugin, and then rsync it to the remote.
I think that running the composer install command affects the main vendor directory from my project and breaks the WPML's PSR-4 assignations, which then leads to those "class not found" errors. I am not sure why exactly. This issue does not occur from others plugins. It's only happenning with WPML.

My stack is using Shipit. This is the workaround I had to create (which is similar to juslintek's one). I just unzip your plugin locally and then rsync it to remote. If I don't do that, I get the mentionned errors in the initial topic.

shipit.blTask('composer:install', async () => {
    await shipit.local('composer install --prefer-dist --no-scripts --no-dev --optimize-autoloader', {cwd: shipit.config.workspace});
});

shipit.on('fetched', function () {
    shipit.start('composer:install');
});

shipit.blTask('wpml', async () => {
    await shipit.local('rm -rf /tmp/shipit/sitepress-multilingual-cms && mkdir -p /tmp/shipit/sitepress-multilingual-cms && unzip -q /tmp/shipit/workspace/config/sitepress-multilingual-cms.zip -d /tmp/shipit')
    await shipit.remote('cd httpdocs/current && rm -rf public/app/plugins/sitepress-multilingual-cms && mkdir public/app/plugins/sitepress-multilingual-cms');
    await shipit.copyToRemote('/tmp/shipit/sitepress-multilingual-cms', 'httpdocs/current/public/app/plugins', {
        rsync: ['--delete']
    });
});

shipit.on('published', function () {
    shipit.start('wpml');
})

Note: I also tried the composer install command without the --optimize-autoloader argument: same issue.

This workaround actually fix the issue, but it is bad practice and makes the deployment workflow harder and unusual. Best way to resolve would be, I guess, to figure out why a production composer install command affects the WPML plugin in such a manner.

Best regards.

Hello,

> In the meantime can you please pass the -c parameter to check for checksums and let me know how it goes?
I'll try that and let you know. However, I assume you are still expecting a missing or corrupted file while uploading to the remotes. As said previously, I already checked that the files were correctly uploaded by downloading them back, and then by making a git compare (but I'll try to also make a test from a project without any gitignore file... just to be sure, and I'll let you know). I think that the problem appears in the root_project/vendor directory (after executing a composer install (with given arguments above), not in the root_project/wp-content/plugins/sitepress-multilingual-cms/vendor directory.

> Also, can you please let me know if this happens only on the first/initial rsync? Or does it also happens after the files are synced initially, WPML is fixed with manual install/update then further rsync of the files?
This happens on every sync, even if the plugin has not been updated, even if there is absolutely no change to the plugin, even if I previously temporarily fixed the error by manually uploading the plugin via the WP plugins page, which actually probably confirm that the issue appears somewhere else than in your plugin folder. Again, I think that the problem occurs in a project that contains a root composer.json file. Composer is somehow breaking the PSR-4 assignations from your plugin but I don't know why. However, this seems to be an issue largely reported (hidden link). But I simply can't figure out the issue since your plugin does not include the composer.json file.

I'll check in the next few days about the mentioned tests and will let you know.

Regards.

Just decided to search the web about "this git issue"... It is not one, but it looks like it is just the default Git behavior.
It seems that by default, Git doesn't care about capitalization changes.... https://stackoverflow.com/questions/6899582/i-change-the-capitalization-of-a-directory-and-git-doesnt-seem-to-pick-up-on-it

What a nightmare... Looks like

git config core.ignorecase false

is a must use...

I wasn't expecting this...

Sorry I reported such a "WPML issue" while the solution actually stands in a single Git config line...

Regards.

Thank you for your patience and the interest you put into that issue. I hope this ticket will help anyone struggling with that kind of git configuration strangely leading to missing files after updating.

Best regards.