Statements are not being sent to Learning Locker when running cron.

[bryantkelley]

Description

• The plugin is not sending statements to Learning Locker despite having the correct configuration for endpoint and client key/secret from Learning Locker using known-good credentials that work for other applications to send statements. We have tried setting it to send statement automatically and have tried to send statements when cron runs.

• Reversing the changes made in the commit for Ensure correct language code format #197 allowed statements to send. This check is important but maybe it needs to be done a different way?

Version

• v3.14.1 / 2018080302

Actual behaviour

• Running cron in the browser returns "Exception - Call to undefined function src\transformer\utils\mb_ereg_replace() !!!" instead of sending statements..

[garemoko]

mb_ereg_replace is not in php 7.0.0. What version are you using?

See https://stackoverflow.com/questions/39469264/fatal-error-uncaught-error-call-to-undefined-function-ereg-replace-php-7

[bryantkelley]

I think we are using PHP 7.0 on our Ubuntu server running Ubuntu 16.04

[ryasmi]

The mb_ereg_replace is supported in PHP 4 >= 4.2.0, PHP 5, and PHP 7. Our CI tests are actually ran on PHP 5, PHP 7.0, and PHP 7.1 so I'm fairly confident the issue here isn't a lack of support for this function in PHP 7.0.

It seems to me that the issue is more likely related to the unintended namespace that PHP is adding to the function call (see the src\transformer\utils\mb_ereg_replace part in the original comment).

[ryasmi]

I wonder what version of PHP @AndyHubert is using and whether the different version seems to effect the way namespaces are handled, however, I'm unsure how this wouldn't have been picked up in our tests.

[AndyHubert]

I am using PHP 5.6.36.

[ryasmi]

Cool thanks @AndyHubert, useful to know 👍

[ryasmi]

I wonder if #197 is a "red herring" here. Since it was included in v3.3.10 and this issue was seen on v3.14.1, a lot happened between those two releases.

This may be unrelated, but I've received a report that on v3.14.3 statements are sent temporarily via the Cron and then stop sending, I believe this is due to #203 which was included in v3.9.3 (relevant here because it's between v3.3.10 and v3.14.1). My theory is that transformers are failing for some events, in which case the plugin does not delete the events from the "mdl_logstore_xapi_log" table, which leaves the events at the top of the table and the plugin then tries to reprocess them in the next batch. Previously this wouldn't have been an issue, because the plugin pulled all events from the table (they weren't batched).

As a solution to this, I believe we need to insert any failed events into a new table "mdl_logstore_xapi_failed_log" and delete the events from the "mdl_logstore_xapi_log" table. These failed events can then be reported back to us via issues and then when fixed, the events can be moved back into the "mdl_logstore_xapi_log" table and deleted from the "mdl_logstore_xapi_failed_log" table.

[ryasmi]

The changes I described in my previous comment are now in v.3.14.4.

[ryasmi]

Closing due to inactivity.