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?
Any update/idea? 😉
Not at priority for the non-default WP Environment
As we already have allowed the wp-content folder dynamic path in the last update, which is for some host that moves the wp-content folder outside of WP directory and so, but we can’t test all the rare-cases,
So this issue with Composer setup is already on the roadmap, but no ETA for this.
Regards,
Mohammad Arshad
DPlugins Support
Hey everyone,
I tested the cache challenge issue today and was able to reproduce it. With the current version 2.0.8, when enabling the cache feature in a roots/bedrock environment, the files are created in the wrong directory. The resulting paths look like “/path/to/wordpress/path/to/wordpress/uploads/winden/…”. After some trial and error, I managed to create a workaround to get the files placed in the correct directory (/path/to/wordpress/web/app/uploads/winden/…) – however I am not sure if this might cause other issues in different areas of the plugin, but so far nothing has happened.
I was following Simon’s suggestion in Application.php and changed uploadPath() to omit the rootPath() (for clarity I left the previous function as a comment):
public function uploadPath( $path = ” ) {
// return $this->joinPaths( $this->rootPath( CoreHelper::getWpContentPath() . ‘/uploads/winden’ ), $path );
return $this->joinPaths( CoreHelper::getWpContentPath() . ‘/uploads/winden’, $path );
}
With this change in place, the files are placed in the correct folder. Hope this helps!
Thanks for testing – that’s great – finally the cache works 🙂 only in the backend the links to the files are not correct (view cache) – but that’s not tragic 😉
Hi there, we have changed the path scan in Winden to a new method in Winden 2.3.0, Kindly check with if you issue is also solved, otherwise let us know and this will be our priority for next update now.
Regards,
Mohammad Arshad
DPlugins Support