Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


SOLVED Approved plugin that needs to access /app/code/wp-settings.php



  • I have an odd use-case which I'm only still unfolding as I write this, but been troubleshooting and thought I'd mention it here in case others have had this issue or have some suggestions or if it's a limitation, etc.

    Right now I have a site in the managed version of WordPress in Cloudron, and I added WooCommerce and a custom PHP plugin to WooCommerce to accept AliPay and WeChat Pay, working with a custom merchant provider for that part.

    Most of it works fine up until the very end when the transaction occurs, we get the following errors:

    2020-10-04T23:29:03.000Z 172.18.0.1 - - [04/Oct/2020:23:29:03 +0000] "GET /wp-content/plugins/motionpay-Plugin/lib/paymentNotify.php?work_mode=test&order_id=1313&mid=100105100000011&outTradeNo=202010042328599934830842&counterForTimeout=0 HTTP/1.1" 500 185 "https://<hostname>/checkout/order-pay/1313/?key=wc_order_310LLLhwBKaSC" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15"
    2020-10-04T23:29:03.000Z [Sun Oct 04 23:29:03.014596 2020] [php7:warn] [pid 138] [client 172.18.0.1:44746] PHP Warning:  require_once(/app/data/wp-settings.php): failed to open stream: No such file or directory in /app/data/wp-config.php on line 70, referer: https://<hostname>/checkout/order-pay/1313/?key=wc_order_310LLLhwBKaSC
    2020-10-04T23:29:03.000Z [Sun Oct 04 23:29:03.014657 2020] [php7:error] [pid 138] [client 172.18.0.1:44746] PHP Fatal error:  require_once(): Failed opening required '/app/data/wp-settings.php' (include_path='.:/usr/share/php') in /app/data/wp-config.php on line 70, referer: https://<hostname>/checkout/order-pay/1313/?key=wc_order_310LLLhwBKaSC
    2020-10-04T23:29:08.000Z [Sun Oct 04 23:29:08.031676 2020] [php7:warn] [pid 137] [client 172.18.0.1:44750] PHP Warning:  require_once(/app/data/wp-settings.php): failed to open stream: No such file or directory in /app/data/wp-config.php on line 70, referer: https://<hostname>/checkout/order-pay/1313/?key=wc_order_310LLLhwBKaSC
    2020-10-04T23:29:08.000Z [Sun Oct 04 23:29:08.031714 2020] [php7:error] [pid 137] [client 172.18.0.1:44750] PHP Fatal error:  require_once(): Failed opening required '/app/data/wp-settings.php' (include_path='.:/usr/share/php') in /app/data/wp-config.php on line 70, referer: https://<hostname>/checkout/order-pay/1313/?key=wc_order_310LLLhwBKaSC
    2020-10-04T23:29:08.000Z 172.18.0.1 - - [04/Oct/2020:23:29:08 +0000] "GET /wp-content/plugins/motionpay-Plugin/lib/paymentNotify.php?work_mode=test&order_id=1313&mid=100105100000011&outTradeNo=202010042328599934830842&counterForTimeout=1 HTTP/1.1" 500 185 "https://<hostname>/checkout/order-pay/1313/?key=wc_order_310LLLhwBKaSC" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15”
    

    It seems it's expecting to open /app/data/wp-settings.php which doesn't exist of course because it's in /app/code/wp-settings.php (code vs data). Haven't run into this issue before, but assuming their custom solution expects to read wp-settings.php and it can't find it so it errors out.

    Can I use a symlink do you think? Just thinking out loud. Or must I migrate this whole site to Unmanaged version to allow this?

    Currently unsure if I need to edit the wp-settings.php at all.



  • They hardcoded the wrong path. The path should be relatively coded; bad coding practices at hand here. Who wrote the code and are they willing to fix their code to take a relative path for their require_once statement?

    If not, if I had that plugin I could fix it for ya and send it back in like ten minutes assuming their hardcoded app/data path is the only thing they did wrong.



  • @Lonk I was wondering if that could be it. I'll check with them, maybe they can fix that up. I was immediately worried it had to do with the managed aspect of the WordPress install, but maybe that's not the case then.



  • @d19dotca Not at all! Properly using relative paths when coding allow plugins to exist in any environment and this is no different. Understand the concern though and it's cool you brought it up here first. Wordpress is my expertise of choice personally. And Cloudron...well, I'm getting there. 😅



  • @Lonk I may give my own hand at it too by duplicating the app from backup to a new subdomain, then digging into their code and see if I can fix it (assuming it's more of a find and replace type task). If not I'll leave it to the provider (MotionPay) to fix up their code if that's the issue which I agree it sounds like it is because it's assuming wp-settings.php is in the same directory as wp-config.php but it isn't.



  • @d19dotca They coded it and it works in their environment and technically it would be a simple find "app/data" and replace it with a string that actually locates the file. You may need to use a relative path but they're easy to create. Two dots go up a directory. So if I was a plugin.php file in the root of the plugin folder, I'd do require_once("/../../../wp-settings.php").



  • Or if you want to make it fancier:

    require_once(rtrim($_SERVER['DOCUMENT_ROOT'], '/') . '/wp-settings.php');


  • Staff

    Is there a reason why the plugin tries to load wp-settings.php directly? My understanding is this is all loaded by WordPress.

    If there is some reason the plugin does include wp-settings.php directly, then it should loading as require_once ABSPATH . 'wp-settings.php'; where ABSPATH is set in the plugin code as /app/code.

    Maybe you can quickly look into that file paymentNotify.php and check how or why it's loading wp-settings.php. Or maybe send the dev to this post) and we can either fix our WP package or the plugin.



  • I'm currently working with the developer who made that custom plugin for WooCommerce, and they determined an issue existed in their SDK and they're fixing it up for us. So hopefully this will be resolved soon out of band. I seriously appreciate the help everyone! It was very time-sensitive and my gut immediately went to "oh crap, I need to use unmanaged for this I bet", haha, but thankfully it doesn't seem to be the case here. Thanks everyone for the help! I'll update this if I need more but I suspect this will be resolved by the developer at this point.



  • Quick update for those following along:

    Developer said this morning that it'd take them 1-2 weeks to accomodate the way this WordPress is installed (I assume more just as they're not able to dedicate time right now to this), and I'm not a developer and since this is for payment processing I don't feel comfortable even touching it anyways. Don't want to accidentally introduce any security vulnerabilities for example. It seems their plugin doesn't work well with the symlinks from /app/code/ to the /app/data/ area, but I told them I assume it'd be improperly coded then since every other plugin works fine. I.e. their problem, not mine. 😛 They seemed to agree in a roundabout way. lol.

    This was their reason earlier btw for why they reference wp-config.php file (we were wondering that earlier on): "I have to manually include the "wp-config.php" file to have the WordPress Defined Variables. The reason is the file in the plugin that receives notification from APIs is not initialized by WordPress."

    Anyways due to time constraints on their side and my customer's side who basically wants it done by end of this week if possible, I'm going to try migrating the site to the unmanaged version to see if this helps things, which I assume it will since it's more of a typical/expected WordPress deployment in that case.

    Thanks again for the help earlier. I'll try to update this post later once the project is complete or if more questions come up / anything interesting is learned. 🙂



  • @d19dotca

    "I have to manually include the "wp-config.php" file to have the WordPress Defined Variables. The reason is the file in the plugin that receives notification from APIs is not initialized by WordPress."

    Okay, that's an intelligent answer at least. Though I'm sure they meant wp-settings.php. If a web hook (which is set up on the processor's side) from a payment processor is set up to call a Wordpress link like most are (Stripe being the prime example) instead of a direct file link (ie: https://example.com/wp-content/plugins/payment-plugin/web-hook-response.php) - then there would never have been an issue since all of Wordpress variables load when POSTing to a link, not a file.

    But if they did this to increase the loading speed of the checkout (since not loading all of Wordpress in the web hook would come with that benefit), I can understand that, it just means they need to make their require_once PHP command follow either mine or @girish's examples. Definitely send them the link to this forum page so they understand what they need to do. ☺



  • @Lonk I think I may just do that. 🙂 I gave him earlier the suggestions for the require_once part, so maybe he'll see that and go "Oh yeah that's a good idea, I can do that in a short amount of time" lol but no idea, he may have found other issues too that I'm not privy to at the moment as their SDK is a bit early stage from what I can tell (it's a 1.0 type thing). Due to time constraints I think I don't have a choice but to migrate to unmanaged, unfortunately. But all good, at least it's possible to do.


  • Staff

    In some ways, this is why Unmanaged WP exists. Plugins etc are built with many assumptions and there's a lot of legacy stuff which can't be changed overnight and time is of the essence... I think we have to figure out in the other thread how to remove the negative connatations of this "unmanaged" word from the package name 🙂 But let's discuss the future of these two WP apps in the other thread at https://forum.cloudron.io/topic/3322/what-is-the-point-of-wordpress-managed



  • Update: I've had the developer test in the new environment using the Unmanaged version of WordPress app and it's working well now. OCD me though struggles having a mix of managed and unmanaged apps now 😛 lol



  • @d19dotca said in Approved plugin that needs to access /app/code/wp-settings.php:

    Update: I've had the developer test in the new environment using the Unmanaged version of WordPress app and it's working well now. OCD me though struggles having a mix of managed and unmanaged apps now 😛 lol

    I thought the whole point was to get the dev to make it work in the Managed version w/o needing access to wp-settings.php .



  • @robi That was my original intention and I still want that to happen, but... deadlines and all. 🤷 Forced to move forward. At least the code is open-source in WordPress so I can maybe copy it to a managed one again later and run some tests in it before making it live, if I'm able to figure it out myself. I may even end up seeing if @Lonk might be willing to do it for a bit of money down the road if it makes it feasible for me to do so. Though I suppose that's not necessary if it all works just fine right now for the customer and for me. I'm just really more curious than anything what the solution is going to be in the end to make it worked on managed version. The developer tried the solutions presented by @girish and @Lonk but he still couldn't get it to work, so there may possibly be more than just the paths as a problem.



  • @d19dotca understand. easy to leave an instance of it for the dev to play with the Managed version. 😜

    Good luck



  • @d19dotca Oh, I’m heavily invested now in the Cloudron infrastructure and have a decade of Wordpress development which I’d love to use to help people on this platform. If we’re being honest, I’d do it for you for free it it helped your transition to Cloudron easier. I would never not accept money in the pandemic-y economy we’re in. Tho if you don’t have the budget but need this done fast. I’d be willing do it for ya for free; I enjoy the Cloudron community and want to give back when I can and Wordpress is my speciality. ☺️ Lemme know, always feel free to DM.



  • @Lonk aw that’s a very sweet offer. Thanks man! I’d definitely pay you though. We’ll see if we get that far, I’m kind of going to take it as a project to learn from as time permits maybe next week. Problem is to test it was a WeChat Pay transaction which I have no idea how to do for obvious reasons lol so it was the developer testing it all out after I installed it and such. Will be an interesting learning project I think. 🙂



  • @d19dotca Yeah, it’s definitely going to be interesting for ya. If you have any questions at all, seriously, don’t mind pinging me on this thread and I’ll answer to the best of my ability.

    And yeah, I just know what it’s like to have a tight budget and time constraints so I wanted to offer! I’ve been in the position so many times during this pandemic, I’d be remiss to not offer that to ya! ☺

    Make sure to update us and tell us how everything goes.


Log in to reply