tornevall

After a long investigation I’ve seen a few things that could affect the outcome of my problem. My intentions is not to reopen this case, but inform others with similar problems only.

In my platform, the only thing I did have installed was WooCommerce and the only plugin we are developing for WooCommerce. Until 6.6.0 the problem was not there either. No cache and no other plugins was active at all. At first I believed that the problem was that related to my ip-network as I work locally (with two ipv6- and two ipv4-interfaces there’s a lot of jumps between the interfaces).

With round robin set up in this format, cookies could be involved for when the outgoing ip addresses are switching, the cookie control also kills the session. This was never entirely confirmed; but the session in fact started to live a bit longer when I only used one ip address at the time. But it was still just about a few seconds longer.

The second thing I actually did, was the most lazy thing I could come up with. Reinstall chrome instead of the site (based on incognito suggestions): The problems then seems to have disappeared since then, with only one strange condition. The problem partially came back for a couple of sessions when I cleaned up all cookies for the browser session and tried to start over with a “new” guest customer. By hard cleaning up all data for the site involved – not only a hard F5, but also really cleaning up the entire cache (included local storages) the problems again was gone.

The problem itself remains unsolved, but something seem to happen with the session itself from time to time (and may eventually be related to WordPress rather than Woocommerce – this is also unclear) when “bad” data remains intact even after a hard reload.

Yes, during tests woocommerce has been the only enabled plugin, without any caching, together with one other plugin that I’ve been working with for a long time (without changing any part that handles session related code).

Currently I’m trying to figure out what makes the session invalid, together with the plugin we’re developing. We usually don’t handle sessions at all from the gateway plugin we’re testing (mostly since it tend to break others), and instead we let woocommerce handle those parts. The problems also seem to escalate in the most recent versions of woocommerce, but I can’t find out why. I tried some theories yesterday, but that did just slightly help to keep the session alive a bit longer. I’m not sure what can possible invalidate a session, when it’s only handled from woocommerce.

Also, there’s no indication from error logs that code are breaking either.

• This reply was modified 2 years, 5 months ago by tornevall.

An interesting update from me:

I was going to investigate the problem further in the code, just to point out some kind of direction for your developers, of where the problem might have occurred – but after the revert I did and further “reupgrades” to 6.2.0 again seems to have fixed the problem for 6.2.0 entirely by itself.

I’m not sure what kind of glitch that may have caused this problem but for the moment it looks gone.

Got it!

Here’s a new one, saved as jpeg instead: https://snipboard.io/tlPX63.jpg

Edit: I’ve already tested most of what’s mentioned here. Besides, this happens in admin so the themes should not be very involved in the problem.

• This reply was modified 2 years, 9 months ago by tornevall.

We’ve been unable to reproduce the error itself locally. However, we’ve seen the problem “live” so the release that has been released this morning, should hopefully solve this issue.

Sidenote: Unfortunately is the current, as it seems, only workaround to do this in MutipleDomain.php – after this, it works again:

(Where also the wp-admin check is removed. This problem also stops, when trying to login directly via wp-login.php)

public function replaceDomain($url)
    {
        /*if (!$this->shouldReplaceDomain()) {
            return $url;
        }*/

        if (array_key_exists($this->domain, $this->domains)) {
            $domain = $this->getDomainFromUrl($url);
            $url = str_replace($domain, $this->domain, $url);
        }
        return $url;
    }

• This reply was modified 5 years, 9 months ago by tornevall.

As a developer for a gateway in WooCommerce, I’ve tried running WP5 and Gutenberg, with a minimalistic configuration (only a few plugins activated) and succeeded to reproduce the error by doing very little with the test instance (actually nothing). Currently I run this test instance with PHP 7.2

However, it is without King Composer.

This is what I get from the copied error from the editor (I haven’t tested to create new products yet, since my target is to make the gateway work for WP5 and WC3.5.x-releases):

TypeError: Cannot read property ‘length’ of undefined
at i (https://wp5-wc.localhost/wp-includes/js/dist/date.min.js?ver=5.0-alpha-43815:1:3777)
at d (https://wp5-wc.localhost/wp-includes/js/dist/date.min.js?ver=5.0-alpha-43815:1:4419)
at https://wp5-wc.localhost/wp-includes/js/dist/editor.min.js?ver=5.0-alpha-43815:55:210644
at Ug (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:90:242)
at Vg (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:92:379)
at Kf (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:118:136)
at Lf (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:118:472)
at jc (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:127:342)
at aa (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:126:505)
at ta (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:124:298)
at Object.enqueueSetState (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react-dom.min.js?ver=5.0-alpha-43815:182:24)
at r.p.setState (https://wp5-wc.localhost/wp-includes/js/dist/vendor/react.min.js?ver=5.0-alpha-43815:19:302)
at https://wp5-wc.localhost/wp-includes/js/dist/data.min.js?ver=5.0-alpha-43815:1:15755
at https://wp5-wc.localhost/wp-includes/js/dist/data.min.js?ver=5.0-alpha-43815:1:6094
at Array.forEach (<anonymous>)
at https://wp5-wc.localhost/wp-includes/js/dist/data.min.js?ver=5.0-alpha-43815:1:6067
at b (https://wp5-wc.localhost/wp-includes/js/dist/data.min.js?ver=5.0-alpha-43815:1:21395)
at https://wp5-wc.localhost/wp-includes/js/dist/data.min.js?ver=5.0-alpha-43815:1:5647
at https://wp5-wc.localhost/wp-includes/js/dist/data.min.js?ver=5.0-alpha-43815:1:13943
at https://wp5-wc.localhost/wp-includes/js/dist/redux-routine.min.js?ver=5.0-alpha-43815:1:9095
at dispatch (https://wp5-wc.localhost/wp-includes/js/dist/data.min.js?ver=5.0-alpha-43815:1:23855)
at https://wp5-wc.localhost/wp-includes/js/dist/redux-routine.min.js?ver=5.0-alpha-43815:1:8676
at https://wp5-wc.localhost/wp-includes/js/dist/redux-routine.min.js?ver=5.0-alpha-43815:1:3965
at Array.some (<anonymous>)
at r (https://wp5-wc.localhost/wp-includes/js/dist/redux-routine.min.js?ver=5.0-alpha-43815:1:3941)
at https://wp5-wc.localhost/wp-includes/js/dist/redux-routine.min.js?ver=5.0-alpha-43815:1:3894

• This reply was modified 6 years, 1 month ago by tornevall.

Good to know is that this warning just arrives on the “WordPress updates”-page and never in the list of installed plugins (when clicking on the update button there, especially). I just discovered this and I realize that this may lead to upgraded plugins with unsupported third party plugins active.

I’ve seen a behaviour where Facebook sometimes don’t fetch and cache the site properly, so instead of a header image, nothing shows up at all. I don’t know if the described issue here is the same, but I have solved it by rescraping the site via Facebook debug tools, and then update the post again. Doing this feels like a bit unnecessary.

It sometimes looks like the post is not published in full until after Facebook robots actually scanned the site, but that’s something I have’nt confirmed. Besides, if the post is not published, there should not be any preview text either to fetch.

However, I don’t think this plugin can stay on the deprecated graph versions for long. My own failover for a few weeks ago was based on a setting in the plugin, where I used to use the link-api instead of the newer feed. But sooner or later, I guess that will break too, unless it’s not updated.

Sounds interesting. We’ll keep this issue available in our JIRA tracker for a while, so if you manage to find out which parts it could be that triggers this we’d be happy to get your feedback on it. However, if this issue is more bound to what version of PHP that runs, it might be a quite small problem too, since it then might be fixable by upgrade. I’ll also keep the segfault environment, just in case, if we can figure out something else that triggers this.

Thanks!

I initiated the installation earlier today, and now I’ve run the first tests in the environment. Surprisingly, the plugin started – and worked as it should. However, I only run the standard plugins right now (the plugin, woocommerce 3.1.2, and nothing more than this). Do you have more plugins installed, in case there’s conflicts between other plugins and ours that might need a fix?

I’ve found some notices about undefined indexes that should probably be suppressed, so I’ll check as soon as I can if this has been fixed in the current develop version, or if we should dispatch a new version for this only. There was a few new notices, that I did not recognize from before (“session_start(): Cannot send session cache limiter – headers already sent”). During the installation of wordpress I also noticed some other errors (A 30 sec timeout that came out from nowhere, before the plugins was installed).

The docker environment – how is it with memory limits and such? Right now, I run on a machine that has 32 gig of ram. I have experienced out of memory issues on a few platforms before, that runs wordpress on 4 gig or less. The worst I’ve ever seen, was when I installed a VPS via CloudVPS and OpenStack, where nothing worked as soon as the memory limit was exceeded. There was some kind of memory leak that made the webserver consume more and more memory, for each reload of the page that was done and when the server went out of memory it crashed completely.

Sure, it would be very interesting to see what’s causing this ??

Besides from this and the stackexchange-thread I’ve created a smaller local issue at https://resursbankplugins.atlassian.net/browse/WOO-180 too, to make followups.

I’ve just installed my first docker environment and managed to install a similar docker container with nginx and php-fpm7 (unfortunately it was PHP 7.1 and not PHP 7.0). In the current state I was unable to reproduce this error, and the unittest that was run with EComPHP (which is the library that handles the SoapClient in this case) also managed to run without errors.

I’m using a simpler image from https://hub.docker.com/r/richarvey/nginx-php-fpm/ and I guess that version does not reflect your environment very good ??

The SOAP part of the plugin is, in the current public version, based on a older version of wsdl2phpgenerator and the wsdl-files can be found under the PLUGIN_PATH/rbwsdl. All functions are the passed through a library called EComPHP (stored under the PLUGIN_PATH/classes directory). This way to handle the web services became a bit obsolete and we’re working on a newer version that don’t need to go through a bunch of wsdl-stubs. It’s in develop-mode right now but can, if you want to test that version too, be downloaded from git at https://bitbucket.org/resursbankplugins/resurs-bank-payment-gateway-for-woocommerce/src/8f5a099e10480b5f4842bbe3f8d83530a9f97477/?at=develop%2F2.1.0

One other question is also quite interesting to look at: Did you manage to configure the plugin? If you did, which of the flows did you choose? Resurs Checkout is mostly based on rest-services, rather than SOAP, so if there is an environment issue here, that might work better while testing? However, it’s still quite weird that the segfault occurs, even if you’re not going through the store.

When browsing around, does it usually happen somewhere on the way through the checkout or other pages that does not have much to do with the store/cart?

There is a branch, called fixes/2.3-2.3.1-unbreak, but I haven’t had enough time yet, to look at the other issues.

Currently it only contains the oauth issue, reported here ??