$_LW->read() in Private Module - No Results

Developing with LiveWhale
1

Hello,

Another seemingly incomprehensible issue. I have a client private widget with the following calls in a onOutput() handler:

<?php // added to style snippet
$data_type = 'groups';
$args = ['paginate' => 999];
$groups = $_LW->read($data_type, $args);
$groups = (isset($groups['results'])) ? $groups['results'] : $groups; // if args are used, then given in "results"

<?php // added to style snippet
$profile_type_name = 'Catalog Sections';
$data_type = 'profiles';
$args= ['type'=>$profile_type_name, 'paginate' => 999];
$profiles = $_LW->read($data_type, $args);
$profiles = (isset($profiles['results'])) ? $profiles['results'] : $profiles;  // if args are used, then given in "results"

What I’ve been able to determine:

  • The Registrar and I have been working on the content this module affects for a few weeks now, and this issue appears to have manifested today.

    • The primary symptom is that the affected data types are unable to save: the read results are used to populate a required field, and when empty, the field/profile refuses to save.

  • I have not worked with this module for at least a year, until today. I cannot see how any other work could have affected this.

  • The initial identical code on the development site is working as intended. (2.20.1 vrs. 2.20.2)

  • I have determined that the issue is that the apparently valid $_LW->read call is returning NULL or a similar empty result.

  • I confirmed that $_LW is available by surrounding the $_LW->read call with successful $_LW->logDebug calls.

  • I have attempted to simplify the call, such as removing the 'paginate' argument or removing the $args parameter from the $_LW->read call: no change.

  • I looked at other instances of $_LW->read in our client code. There are two public modules as well as a number of include PHP files, each appearing to work as intended.

Lingering questions:

  • What may have caused this module to stop receiving data from its $_LW->read calls?

  • Why might is the issue only affect a private module specifically?

Potential next steps:

  • Another section of the module uses $_LW->dbo->query to pull data that $_LW->read isn’t defined to access (custom database table for courses). I may attempt to use query for the groups and profiles, if I can figure out the details.

  • I could try to do the minor upgrade to 2.20.2. Not sure what it would do to help, but it’s also unlikely to hurt.

Any input or suggestions are welcome.

Thanks,
Nick

2

And of course the second I finish all that, I notice a message about multiple installation errors and warnings on production. These seem potentially relevant: “unable to refer back to itself via local request.”

Installation Errors

  • Issue: LiveWhale unable to refer back to itself via local request to www.beloit.edu.
    Suggestion: LiveWhale needs to routinely make an HTTP(s) request to itself from the localhost in order to perform various tasks. However, LiveWhale was unable to refer back to itself at https://www.beloit.edu/livewhale/. (If you have recently updated your DNS, this may be a temporary issue.)
  • Issue: A 404 page is not being used by Apache.
    Suggestion: Add the following directive to your root /.htaccess: ErrorDocument 404 /_ingredients/templates/details/404.php and ensure that this page exists.
  • Issue: LiveWhale sync exec calls are not working.
    Suggestion: Internally spawned tasks by the CMS appear to not be running. Please contact LiveWhale support staff about this issue.
  • Issue: LiveWhale async exec calls are not working.
    Suggestion: Internally spawned tasks by the CMS appear to not be running. Please contact LiveWhale support staff about this issue.
  • Issue: Could not connect to web node: x.y.z.148 via https
    Suggestion: LiveWhale must be able to reach all web nodes via HTTP or HTTPS.

Warnings

  • Issue: Apache-based htaccess authentication is not available on this system.
    Suggestion: Ensure that your Apache installation specifies “AllowOverride AuthConfig” or “AllowOverride All” to enable per-dir htaccess authentication. This is not a LiveWhale requirement. If you choose to leave this feature off, directory authentication from within LiveWhale will simply not be offered to end users.
3

Hi Nick,

Ah! In short, yes, the ->read endpoint leverages the JSON API behind the scenes, so sync/async errors like you’re seeing in diagnostics could definitely have an adverse effect on that kind of custom code.

I’ll flag this for the hosting team on our end – in the future, for anyone else who runs into those kinds of hosting-related diagnostics errors, feel free to reach out via the Request Help Form to get the attention of our hosting team.

4

Hello Karl,

Thanks for the confirmation of causality. Knowing why something is behaving the way it is some relief.

Shortly before your reply, I noticed the issues and diagnostics page returned to normal: “Everything looks A-OK!” Not sure if you all resolved it, or if it worked itself out, but I appreciate the attention either way.

Thanks,
Nick

5

Strange – but glad it’s working! Please reach out if the hosting issues return, thanks.

1 Like