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

[d19dotca]

@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.

[Lonkle]

@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").

[Lonkle]

Or if you want to make it fancier:

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

[girish]

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.

[d19dotca]

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.

[d19dotca]

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.

[Lonkle]

@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. ️

[d19dotca]

@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.

[girish]

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

[d19dotca]

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

[robi]

@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 .

[d19dotca]

@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.

[robi]

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

Good luck

[Lonkle]

@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.

[d19dotca]

@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.

[Lonkle]

@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.

[marcusquinn]

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

WeChat

If your client is open to using Adyen, we have a custom plugin developed for that, which basically opens up many other payment options through one plugin:

• https://www.adyen.com/payment-methods#

[d19dotca]

@marcusquinn I appreciate the suggestion, I'll keep it in mind. I think they're pretty set (too far into it really) on the current provider they chose (it's also a Canadian company so they're supporting local business which is something they like to do when possible), can't see this provider part changing unless this company turns out to be really bad at what they do. haha. Let's hope that doesn't get to that though. I'll keep it in my back pocket in case they run into issues though and want to change providers, then this can be an alternative for them for accepting WeChat and AliPay.

[marcusquinn]

@d19dotca Yup, they cover all sorts of obscure things for all countries, including cash on delivery and other random country-specific popular services. Ebay uses them now. Rates seem pretty fair. Certainly easier than setting them all up individually.