We use composer in one of our customer installations with the following path to the plugins: web/app/plugins/{$name}/ and the following wordpress-install-dir: web/wp
With winden 1.x everything works. when upgrading to 2.x neither the back- nor frontend works. the paths to the files are declared incorrectly:
- GET https://DOMAIN.TLD/home/httpd/vhosts/DOMAIN.TLD/httpdocs/web/app/plugins/winden/resources/assets/index-B0f32LeW.js 404 (Not Found)
- GET https://DOMAIN.TLD/home/httpd/vhosts/DOMAIN.TLD/httpdocs/web/app/plugins/winden/resources/assets/index-M2AqLvZS.css net::ERR_AB
Something seems to be wrong with the autoload. How can we fix this?
Hello Simon,
I was facing the same issue today and managed to produce a workaround. We are also using a composer-based setup with the same folder structure and this seems to be working for now.
In order to resolve this, we created a beta branch on our private repo and included this in our composer.json (require vendor/winden:dev-beta) in order to update the main branch later when this is officially fixed.
On beta, we changed /app/Helpers/CoreHelper.php and added a helper function:
public static function getWpContentURL() {
return WP_CONTENT_URL;
}
similar to the already existing getWpContentPath() used in pluginUrl().
Then, we changed pluginUrl() to:
public static function pluginUrl( $path = ” ) {
return self::joinUrls( self::getWpContentURL() . ‘/plugins/’ . CoreHelper::baseName(), $path );
}
and the backend functionality becomes available again.
Hope this helps in mitigating the issue for now (works on my machine :D) and looking forward to an official patch!
Best Regards,
Henning
you are my hero 🙂 The backend is now working. However, the cache does not seem to be correct yet (both the path to the cache file and to the “scanner”). Ff a path is specified for the scanner, the following error message appears: “The ‘/home/httpd/vhosts/DOMAIN.TLD/httpdocs/web/wp/home/httpd/vhosts/DOMAIN.TLD/httpdocs/web/app/plugins/oxygen-elements’ directory does not exist.
How can i fix the remaining cache problem? Then we would have solved the problem with composer 🙂
Hi Simon,
I have not encountered the cache file path issue yet, as the website in question on our end is not live yet (I assume yours is?). Without being able to reproduce, I can only guess: There is another function called uploadUrl() in CoreHelper.php that is also returning a path instead of a URL. If you try changing this function to use the new helper, does that help with the error?
public static function uploadUrl( $path = ” ) {
return self::joinUrls( self::getWpContentURL() . ‘/uploads/’ . CoreHelper::baseName(), $path );
}
If you look at TaskCache.php, the function uploadUrl() is used inside getDirUrl(), and I assume that it should actually be returning a URL, instead of a path on the filesystem.
If I should encounter this issue as well before dplugins can provide assistance, I will update my findings if I should find a workaround.
Cheers and much success!
Tthank you for the feedback. I have to correct myself, there are currently the following problems:
– the cache is generated (if no path is entered at the scanner), but in the folder below “wp” (where the WordPress core data is located, instead of “app”, which corresponds to wp-content): /httpdocs/web/wp/home/httpd/vhosts/DOMAIN.TLD/httpdocs/web/app/uploads/winden would be correct /httpdocs/web/app/uploads/winden (in the previous Winden version this was still correct for this installation)
– if the cache (without your fix) is activated, the path is generated incorrectly: https://DOMAIN.TLD/home/httpd/vhosts/DOMAIN.TLD/httpdocs/web/app/uploads/winden/tasks/59f8fd35-251b-4ffa-9908-a9e4244b27a1/styles.css
– if the cache is activated (with your fix), the path is correct in the frontend (but I had to copy the folders and files manually): https://DOMAIN.TLD/app/uploads/winden/tasks/59f8fd35-251b-4ffa-9908-a9e4244b27a1/styles.css
I also noticed: in TaskCache.php, getDirPath refers to the uploadPath function, which in turn calls the rootPath() function in Application.php – maybe the path is not correct in this (Composer) constellation?