Posted: June 5, 2018 at 7:28 pm
I’m trying to resolve an issue that I just noticed for our site. I haven’t been receiving any ADMIN nor USER Registration emails. When I try to Generate the Messages and Send Now, it gives me the following error:
Incoming data for the Gateways data handler must have an EE_Transaction object as the value for the first array index. EE_Messages_Gateways_incoming_data – __construct – 36
We found the above error can happen if there is some form of garbage collection running on the site just as the messages attempt to generate. It basically breaks the message queue data and those messages are then unable to generate.
We added some code which should prevent that from happening, however, if you were using an older version of EE when the messages broke the code added can’t fix them from the queue, the need to be retriggered.
Are you using the latest version of Event Espresso currently?
Yes, I’m using the latest version of EE now. There were some extreme problem with the last update. I’m still struggling to ensure everything is working correctly. On May 23, I applied the new EE. Unknown to me, I boarded a flight and two hours later and landed, my entire site was in a havoc state. I had to literally install an old version of EE to repair stuff. Then the site started working BUT I applied the update again yesterday and the same thing occurred.
Messages stuck in the message queue. My grid data aren’t displaying fully. My input boxes aren’t fully displaying correctly in the registration form. So many things. This unfortunately was the worse update for the current version.
Here’s my site: https://ibm-zcouncil.com/
You’re site is currently running 4.9.62.p, so is it broken currently?
Can you provide more details on what was actually broken?
This is unlikely to be from the update itself but we can investigate further.
Which grid data on which page?
If you mean this – https://ibm-zcouncil.com/events/
Then the grid you are referring to is likely from your theme, that’s an archive of EE posts which uses your theme’s
Is this happening now? I can’t see any issues with the registration form inputs, but I don’t have anything to compare it to on your site.
If you let me know what is happening we can help investigate further, right now we don’t have enough info to help.
Thanks for the responses. Here’s some additional details of what I experienced.
When I first upgraded to the current version of EE Version 4.9.62.p on May 22nd, my entire site wasn’t in a disarray. Events weren’t posting properly, files for my theme code had been changed. I had to rebuild the page.php and archive.php files and it got so stressful, I stopped and undid the changes made to those files. I re-installed a previous working version of EE (Version 4.9.46.p) I had, and then EVERYTHING started back working with the exception of the message queue (which I had no idea wasn’t working after the upgrade and re-installation of EE Version 4.9.46.p). Now, for the most part, the site is back operating with most features restored with Version 4.9.62.p. I went on an installed it and as expected, it caused the same problems it did the first time but I had a backup of all the files BUT this time, my archive.php file hadn’t changed and the items that used to display on this page aren’t displaying how they used to. There’s roughly about 30+ events currently open and available but the site is only displaying 10 utilizing the archive.php file.
After the upgrade mentioned before, unbeknownst to be, messages that needed to be sent automatically after a user registered for an event weren’t being sent. It was about 5 days later, I realized I hadn’t gotten any Event Admin emails and I finally saw the message queue with 239 messages waiting to be sent. Unfortunately, when I tried the Generate and Send Now function, it return this error:
Ultimately, I deleted all those messages in the queue and went into every open event and clicked the number of attendees available beside each event and resent all the messages that way which resulted in me receiving about 478 email notifications this morning.
This particular situation as you mentioned is in fact controlled by the archive.php page and none of the code on the page has changed except for today to force the events to appear but it’s only displaying 10 items. With the original code, it displayed it all. It wasn’t until after this upgrade to EE Version 4.9.62.p that the grid started to not work and not show any items. I’m still trying to find a working code to get things going to display EVERYTHING in EE that’s open for registration. If you take a look at our main page, it shows events which don’t appear on the page that’s using the archive.php file. I thought it was something in the code and tried copying and pasting and still no luck to display the items. The codes from the main page and archive.php file are essentially the same. Still not displaying the correct items all the way through.
This is actually a theme feature when I have to manually go into the EE Core and wrap the registration form with a special div we use internally to display the input boxes in the IBM format we require to match our modern UI for input boxes. That’s a easy solve.
This wasn’t the first time this has happen. Before I took over managing the site, there was the previous person who warned me of how sometimes the EE updates aren’t all that good and can crash the side. In his case, he applied an update and the site was so badly filled with bugs from the update to where the site wasn’t used until I came along and started making some code changes and solving things one by one. It took me about 3 weeks to get everything up and going to the current design we have available now.
OK, let’s break some of this down a little:
May I ask what you mean by events weren’t posting properly? Could you not create/update events?
Whilst I’m not saying this didn’t happen on your site, there is no code in EE at all to change your theme’s template files, so whatever changed those files, it was not EE.
Do you mean your themes page.php and archive.php templates were updated by the theme author? If so you should be using a child theme to override the parent template files so your customizations are not being lost when the theme updates. I can see your site is currently using a child theme, but I have no idea what files you are loading from it.
So far everything is ‘events not posting’ and the event grid from your theme not working correct?
It’s reinstalling 4.9.46.p that has broken the message queue.
Ok, so what is different between now, when it’s working with 4.9.62.p and previous?
We can investigate this further once we know what is happening.
Tbh, so far it sounds like EE core files (files within the plugin itself) are being customized on your site, when you update EE those customizations are all lost (because when you update a plugin WP deletes the plugins directory and unpacks the latest version from the zip it downloads)
So it sounds like you had customizations in the previous version that were lost during the update, although right, now I’m just guessing.
Just to note, you could have temporarily disabled the event admin notification email whilst working through this to prevent that:
Event Espresso -> Messages -> Default message templates -> Registration Approved -> Event Admin – http://take.ms/JfCoO
Toggle the switch on that specific message template context to disable it, then toggle it back when the messages were all generated.
Ok, so EE’s core plugin files are being changed and as mentioned those customizations will be lost on each update which means you will run into problems each and every time you update.
If you let me know exactly what you are changing I can check if there is a method to do this via a hook (or request when is added so you don’t need to edit core).
The above change may sound/be trivial, but what else has been changed?
We’ve heard this before and yes we have had issues with updates causing some users problems in the past (we can’t possibly test every possible plugin combination), however, the majority of issues are from 3 things:
Poor plugins doing something totally unexpected because ‘it worked for them’. ‘Firing’ WP core hooks multiple times and/or on pages/requests they just aren’t expected to be run on, is an example of what some plugins do. We simply can’t prevent those issues but will help identify and work through them if we can, even if that simply means we recommend you contact the plugin author and ask them to fix it. We don’t simply put point the finger at another author and say not our problem, but we’ll check it out and see if we can provide snippet to work around it, if not, they need to fix it.
Themes/Plugin incompatibilities, sometimes EE just isn’t going to work with a specific theme/plugin because it works in a way that just isn’t expected. Its rare but can happen.
Customizations not done correctly or customized core files. This could be either poor cusomizations done in a custom plugin hooking into EE or the core plugin files edited without knowing the issues with doing so.
Poor code speak for itself, something just not done correctly or in a fragile manor.
Any plugin’s core files should not be edited, EE has over 900 action hooks and over 1500 filter hooks (thats just from searching the codebase for ‘AHEE’ and ‘FHEE’ which are out prefixes for action/filter hooks), combine that with over 300 template files and you’ve got a huge amount of control over the output. It does NOT cover everything, but theres a lot covered, even more so if you are a developer and we are also open to adding additional hooks to change something if its not available (You can even add your own hook and open a pull request to have it included in core once reviewed which will be much quicker than if we request and add the hook ourselves)
Code changes to what? EE? If so that’s not a good idea for the reasons mentioned above.
I have an update. Everything is back working how it should but I discovered that the following code to display items inline is causing all the problems when added to the function.php in the child file.
I needed to display the address in an inline fashion. For now, it’s displaying multiple lines and if I change the inline parameter to multiline or vice versa, my web pages seem to fuss.
To get everything to display on my grid page using the archive.php file, I had to manually add the following to my function.php file also.
That seemed to resolve that and get everything back working. See results:
Just discovered my buttons are not appearing in the IBM fashion. Would there be a easier way to change the class for the EE buttons to our format for styling?
Unless you are specifically calling that function using
EE calls that function without passing the echo param in all locations, see – http://take.ms/etm8J
Which means that WITHOUT the above change, you must be calling
Looks like the purpose of the above function is to change the order of the address output and obviously make it inline, but you can do both of those without overriding the function itself.
Will display the address inline.
To alter the order of the address we have a filter you can use:
If you post the code you are using for the output I can check it over and advise from there.
pre_get_posts runs on every query, so you probably want to do some additional checks to only affect EE posts, even thogh the above is checking for the main query and an archive it will still affect every other archive (which may or may not be a problem for you), some examples of how to do that are here:
Hmm, I dont think so.
We don’t have a filter to add additional classes to all of the EE buttons currently, I’ll check into this and get back to you shortly.
The support post ‘Message Queuing – 239 Queued For Generating’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.