Open rolandksmith opened 2 years ago
Further testing ... snippets reading a pod (fetching records one by one from a pod) are timing out. Snippets getting one record are seem to be working.
By setting the time limit to 0, some of the snippets are working ... those that read records and display them. Any snippet doing serious processing is hitting the Apache time out and returning a 503 error.
Thanks for testing the Pods 2.8.8 pre-release out @rolandksmith
I'm looking into this to see what might be causing it. We have another fix that is now available (sent on Slack) for this release which may resolve the issue. If it doesn't resolve it, then I'll need to better understand what snippets you are having trouble with.
What snippets are you referring to?
In my situation I would get the dreaded critical error when the Block editor was trying to open pages with multiple Pods list blocks - pulling in roughly 200 items in lists of 4-6 per block arranged in columns. Some were accompanied by the WP helpful email but many weren't. Those that did have the email refered to the following
An error of type E_ERROR was caused in line 1471 of the file /home/icais/public_html/program/wp-content/plugins/pods/src/Pods/Whatsit.php. Error message: Maximum execution time of 60 seconds exceeded
An error of type E_ERROR was caused in line 95 of the file /home/icais/public_html/program/wp-content/plugins/pods/src/Pods/Whatsit/Storage/Collection.php. Error message: Maximum execution time of 60 seconds exceeded
I did get this one also that wasn't connected to the Pods/Whatsit - and interestingly, I wasn't using that plugin at the time. An error of type E_ERROR was caused in line 4458 of the file /home/icais/public_html/program/wp-content/plugins/admin-menu-editor/includes/menu-editor-core.php. Error message: Maximum execution time of 60 seconds exceeded
I was getting serious CPU faults even after having my server double the CPU limit. I was able to get around it by editing with the classic editor and using cut and paste to break a larger page into smaller sections. In the screenshot below, the lull in activity was me taking a break between commenting in the support slack and then I downloaded and installed 2.8.8. The last spike with fault (4 faults according to cPanel) was after installing 2.8.8 and attempting to open the pages that were crashing. The last un faulty section is with 2.8.5 running and opening those same troublesome pages in the block editor.
I will add that I was getting 500 time outs simply trying to edit the individual post type (in my case conference events). I had to be very careful to only edit one at a time. No more "open in new tab" to edit several.
I'm still looking into this, I haven't been able to reproduce the issue yet.
I've improved things in the latest version of Pods 2.8.8, be sure to retest on that. https://github.com/pods-framework/pods/archive/refs/heads/release/2.8.8.zip
Scott, last week was a very hectic and full week and there was no time available to do any testing with 2.8.8.1. Things have settled down to a dull roar, so we installed 2.8.8.1 this morning and did enough testing for us to decide to stay with 2.8.8.1 going forward (and install future releases as they happen).
We were having three issues. Here's my status on each of them:
We were having in 2.8.5 an issue with a paragraph text field. If an equal sign (=) was present in a paragraph text field, doing a pods->save() of that record caused the save to fail and the system to return a 500 error. That no longer happens in 2.8.8.1.
We were having an issue with duplicating a pod in pods->admin where some fields would be missing from the duplicated pod. In 2.8.8.1 all the fields seem to be there, but when I edit the duplicated pod, no fields are displayed: [image: Screen Shot 2021-12-13 at 7.41.06 AM.png]
However, when I click on the pod name itself, all the records from the original pod are there (this is a new behavior and I like it!!!) and all the fields are there. I can't edit the pod in pods->admin. So, in this case one issue seems to have been resolved and a new issue introduced.
Finally, we were having issues with system timeouts when running scripts
that processed larger amounts of pods data. There were six php functions
that would timeout every time on v2.8.7 and 2.8.8 but would run to
completion correctly in 2.8.5. 2.8.8.1 mostly solves the problem. Every
function runs significantly longer in 2.8.8.1 than in 2.8.5. Most of the
scripts now fail because of the default 30 second PHP time limit (not just
the six that failed before). We have to put in an
"ini_set('max_execution_time',
That puts us in a position where 2.8.8.1 works sufficiently well ... However, the timeout issue is still a significant concern for me. As you'll see in the information below, we're processing what is in reality a trivial amount of data. If the pods framework is struggling to handle this amount of data, we'll soon be unable to use this capability and will have to transition to native MySQL tables.
A little background of what we're doing with the pods framework:
The CW Academy teaches Morse Code to amateur radio operators (aka ham radio operators) around the world. CW Academy offers four levels of classes: beginner level classes, basic level classes, intermediate level classes, and advanced level classes. These classes are offered free of charge three times a year; January thru February, May through June, and September through October. Each session is called a "semester". The classes are eight weeks long. Around a thousand students sign up to take one of the four levels of classes and some eighty to ninety advisors volunteer to teach these classes. A number of advisors sign up to teach more than one class in a semester, so there are a hundred or more classes offered.
We have developed scripts for students and advisors to register, scripts to update or delete student and advisor information, scripts to manage the classes and class catalog, scripts to verify students are registered for the appropriate level of classes, scripts to report the student, advisor, and advisor class information in a variety of ways, etc. The major scripts include matching students to classes and managing the makeup of classes as some students drop out, others have to have a different schedule, or personal or family situations intervene.
The six main pods are An advisor pod with the information about each advisor volunteer for the upcoming or current semester (usually has around ninety to a hundred records) An advisor_class pod with information about each class an advisor is making available in the upcoming or current semester (usually has a hundred to a hundred ten records) A student pod with information about each student and their class choices for the upcoming or current semester (usually has around a thousand records) A past_advisor pod with information about all advisors in past semesters (currently has about five hundred records, increases at the end of each semester) past_advisorClass pod with information about each past class, which students were in each class, and the final status of the student (currently has about 600 records, increases at the end of each semester) A past_student pod with information about each student in each past semester (currently has 4,600 records, increases at the end of each semester)
The data goes back to Jan/Feb 2020.
Thanks and Merry Christmas! -- Roland Smith K7OJL Cell: (435) 849-1946
On Mon, Dec 6, 2021 at 9:16 PM Scott Kingsley Clark < @.***> wrote:
I've improved things in the latest version of Pods 2.8.8, be sure to retest on that. https://github.com/pods-framework/pods/archive/refs/heads/release/2.8.8.zip
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pods-framework/pods/issues/6349#issuecomment-987553106, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABM3S4AWM6DQIYWTKLXCA6DUPWDBDANCNFSM5JJ6FTEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
More improvements have been made for Pods 2.8.9 which may have resolved the remaining concerns here. After it is released, we can revisit whether this issue can be closed.
Roland Smith K7OJL Cell: (435) 849-1946
On Thu, Jan 27, 2022 at 12:01 AM Scott Kingsley Clark < @.***> wrote:
More improvements have been made for Pods 2.8.9 which may have resolved the remaining concerns here. After it is released, we can revisit whether this issue can be closed.
— Reply to this email directly, view it on GitHub https://github.com/pods-framework/pods/issues/6349#issuecomment-1022904905, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABM3S4DJZBHZYW3OYRCBYK3UYDUT5ANCNFSM5JJ6FTEQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Description
All snippets are timing out after auto-install of 2.8.8
SITE IS COMPLETELY DOWN
Timeouts are either explicit or a 503 error. Screen shots below
Version
2.8.8
Testing Instructions
No response
Screenshots / Screencast
<img width="713" alt="Screen Shot 2021-12-03 at 8 09 59 AM" src="https://user-images.githubusercontent.com/5880176/144627588-058c74ca-35f8-403a-8f85-d39b704c82ee.png"
Possible Workaround
No response
Site Health Information
Pods Package