$data -> view_data not occurring
Closed this issue · 4 comments
There are actually a few issues occurring here at once. Thought I had it sorted out, but just noticed issues remain.
Upon activation of the plugin, the podsviews table never gets created yet the underlying pods_view function and other associated functions continue to visually function. But PODS_AJAX_VIEW_DEBUG indicates no caching actually occurs.
Manually creating the table throws server-side errors saying view_data cannot be NULL.
Allowing view_data to be NULL allows the plugin to visually function once more, yet DEBUG continues to indicate NOT CACHED. Viewing the podsviews database table confirms that the rest of the data does get stored, rows being created for every time it runs.
I originally assumed that because $data is optional, thus allowing NULL, that changing it to allow NULL would make the plugin work. But I've run out of time today to continue figuring out why no data is actually being stored. My guess is there's a slight shortcoming between the existing pods_view function and pods_ajax_view, the former not passing data to the latter.
I'd love to see this get resolved considering the data being rendered in my current project is 3rd-party GTFS API data and calls to the vendor's endpoints take no less than 1200ms each time (DNS and other considerations accounted for). And I'd love to continue keeping everything within the Pods ecosystem!
Awesome testing results, thanks! Will get this resolved as soon as I'm on my next free weekend. Not anticipating that for another few weeks at least though :(
Forgot to leave env deets...
Staging server, stack setup and maintained by ServerPilot, metal by Linode. Ubuntu 16.04, Apache 2.4.27, PHP 7.1.8 fpm-fcgi
Relevant stuff:
Pods 2.7b2
MySQL 5.7.19 mysqli
key_buffer_size 16777216
max_allowed_packet 16777216
max_connections 151
query_cache_limit 1048576
query_cache_size 16777216
query_cache_type OFF
WP 4.8.1
WP_DEBUG true
WP_DEBUG_DISPLAY true
WP_DEBUG_LOG true
SCRIPT_DEBUG true
WP_CACHE false
CONCATENATE_SCRIPTS false
COMPRESS_SCRIPTS false
COMPRESS_CSS false
@sc0ttkclark Anything I can do to move this forward? If you have anything specific in mind, any places I should focus on within the codebase, any external considerations I'm not aware of, definitely let me know and I'll do what I can. Thanks!
Closing after our debug session last night earned multiple sighs of relief as we resolved everything :)