Forum Replies Created
-
Posts
-
Hello – thanks for getting back to me. I do have debug logging turned on – the log was filling up with multiple instances of the notice:
[23-May-2017 15:07:03 UTC] PHP Notice: [site]\wp-content\plugins\event-tickets-plus\src\Tribe\Commerce\WPEC\Main.php is deprecated since version 4.4.8 with no alternative available. Event Tickets Plus will discontinue support for WP E-Commerce in an upcoming release. in [site]\wp-includes\functions.php on line 3961
That file ( …\WPEC\Main.php ) has a ‘depreciated’ status, I don’t know how to disable it without making things worse. It fires a couple of times every time a page is loaded (front end or dashboard).
I’ve also discovered that if I deactivate WooCommerce while Event Tickets Plus is activated, the site fails completely with the following error:
[24-May-2017 08:57:20 UTC] PHP Fatal error: Call to undefined function WC() in [site]\wp-content\plugins\event-tickets-plus\src\Tribe\Commerce\WooCommerce\Main.php on line 243
If my own plugin is off but the Modern Tribe plugins and WooCommerce are on, the only error message I get is the one about WPEC – but obviously I need to be able to check conflicts between my plugin and yours independently of WooCommerce…
Trying to put that last reply back together:
It looks like both the online (php 5.4) and offline (php 5.6) versions were having problems with ETP 4.5.5 – the offline version was set to log but not display errors, so I missed it first time round.
Trying out ETP 4.5.6, that error is resolved, but a new set of errors – notices rather than warnings – are occurring, mostly of the form:
[20-Apr-2017 11:12:28 UTC] PHP Notice: id was called incorrectly. Product properties should not be accessed directly. Backtrace: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/twentysixteen/page.php’), get_template_part, locate_template, load_template, require(‘/themes/twentysixteen/template-parts/content-page.php’), the_content, apply_filters(‘the_content’), WP_Hook->apply_filters, call_user_func_array, do_shortcode, preg_replace_callback, do_shortcode_tag, call_user_func, WC_Shortcodes::cart, WC_Shortcodes::shortcode_wrapper, call_user_func, WC_Shortcode_Cart::output, do_action(‘woocommerce_check_cart_items’), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, Tribe__Tickets_Plus__Commerce__WooCommerce__Global_Stock->cart_check_stock, Tribe__Tickets_Plus__Commerce__WooCommerce__Global_Stock->cart_get_global_stock_quantities, WC_Abstract_Legacy_Product->__get, wc_doing_it_wrong Please see [link to WP codex]Debugging in WordPress in /[…]/wp-includes/functions.php on line 4137
Again, these errors are appearing on both servers.
However the errors seem to occur less consistently, and I’m not sure if it’s being caused by event tickets created before the WooCommerce 3.0 update, or if it’s due to event tickets with/without stock limits – I can test this further, but won’t have a chance to do this until next week.
Turning off the display of error messages does clean up the front end, and the purchasing process appears fine to the user – however, I don’t want to implement this on our live site when it’s still causing errors in the back end.
Okay, tried the 4.5.6 versions, and now get a different set of errors 🙂
I also realised that the offline version was throwing the same error – because that was set to log instead of display errors, I’d missed it – apologies for the confusion.
Setting both sites to log instead of display errors does clear up the front end, but I don’t really want to implement it on the back end when it’s still throwing errors.
The new errors start appearing when I add a ticket to the cart, and are mostly of the form:
[20-Apr-2017 11:12:28 UTC] PHP Notice: id was called incorrectly. Product properties should not be accessed directly. Backtrace: require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/twentysixteen/page.php’), get_template_part, locate_template, load_template, require(‘/themes/twentysixteen/template-parts/content-page.php’), the_content, apply_filters(‘the_content’), WP_Hook->apply_filters, call_user_func_array, do_shortcode, preg_replace_callback, do_shortcode_tag, call_user_func, WC_Shortcodes::cart, WC_Shortcodes::shortcode_wrapper, call_user_func, WC_Shortcode_Cart::output, do_action(‘woocommerce_check_cart_items’), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, Tribe__Tickets_Plus__Commerce__WooCommerce__Global_Stock->cart_check_stock, Tribe__Tickets_Plus__Commerce__WooCommerce__Global_Stock->cart_get_global_stock_quantities, WC_Abstract_Legacy_Product->__get, wc_doing_it_wrong Please see Debugging in Word in /[…]/wp-includes/functions.php on line 4137
They don’t seem to be appearing consistently – it’s possible that it’s only affect event tickets created before WooCommerce version 3? Or that it’s only affecting tickets with limited stock? I can do a few more tests with new events to check if you like, but won’t have time to do this until next week.
Hi Andras – I did a quick test on a local offline server that’s running php 5.6, and the error didn’t occur.
I’ve just noticed the next update is available – I’ll try that and get back to you.
Hi Andras,
We’re not using that extension; I’d tried the WooCommerce checkout process with a simple product (I assume you mean that rather than single) and it worked okay, and tested it with a virtual product just now without any errors.
We’re on shared hosting, so I’m not able to change the PHP version.
Our testing site seems to have coped with that update okay (as a disclaimer, it doesn’t currently have any upcoming events entered)
We’re also seeing this issue on our testing server, which is running XAMPP (on a Windows 7 desktop 🙂 – PHP 5.6.15 & Apache 2.4.17
When the Events Calendar & Event Tickets were updated, start getting fatal error messages saying either ‘Allowed memory size of 134217728 bytes exhausted’ or ‘Call to undefined method Tribe__Settings_Manager’. The Events Calendar Pro and Event Tickets Plus were deactivated while those updates were being done. Site seems fine after reverting to the 4.3.5 versions.
Thanks for getting back to me. I apologise for any confusion – I added the supplementary question because I saw it as an alternative solution for the display issue I’m trying to resolve – if sticky events displayed at the top of other listings, then the issue of long-term events displaying above daily events could be worked around by marking single-day events as sticky. I have now upvoted that feature request.
I thought it worth asking in case there was something straightforward that could be implemented – I will have a look at the templates and get back to you if I get stuck.
Thanks for clarifying all that.
I’ve removed the rogue recurring event, and the calendar month view does now display, although it’s still sluggish – I’ll look at cleaning up the database further, and will let you know if we have any further problems with the month view.
Thanks for your help!
Hello Brook, thanks for your prompt response.
We’ve over 15,000 entries in the wp_posts table – I suspect quite a lot of these will be post revisions, and I will have a look at cleaning up that table.
WRT the recurring events – I realised that there’s one recurring event that has a far greater number of recurring events than it should. This occurred when I ran the previous version of your ‘recurring event bug fix’ plugin – I unpublished the event, so they’re sitting in the drafts, and had assumed that they wouldn’t affect the front end. I then, admittedly, forgot about it :/ (It did have an end date, and the dates have all passed)
Before I start the new recurring event fix plugin, can I check a few things about the way ECPro deals with recurring events? We don’t have any recurring events that are open-ended – our events get added (for the most part) triannually for our Spring, Summer and Autumn/Winter programmes, so even events that are long-running are added in batches. None of the events (barring the one that flaked out after the attempt to fix it!) have more than about a dozen instances. I had assumed that once the events were generated and could be seen in the dashboard event listing, there wouldn’t be an issue with the calendar having to generate content when it was viewed?
We also quite often have exceptions and/or events that are pulled out of the recurring event series – again, I’d assumed that once the events were generated, and pulled out of the series, the calendar would see them as regular events?
I’m also slightly concerned about the “Clean up recurring events after” setting – does this apply to recurring events with date limits? We like to keep past events on the website so we have a record of them – why should past events (recurring or otherwise) have any impact on the current and upcoming event views? (beyond the obvious one of the post table being large).
Hi Andras – sorry for the delay in getting back to you, I’ve been out of the office.
When we initially saw the problem, the timezone settings weren’t enabled in ECPro, but the other settings were the same; with the settings above, the problem does occur on new events with similar date/time settings.
I’ve not had a chance to go through checking for theme/plugin conflicts as it’s a live site – I wasn’t able to reproduce the problem on our test site, so can’t check for conflicts there. I will check for plugin conflicts when I have a chance, and let you know what I find.
I exported the events from our live site using WP’s built-in exporter, which produces an XML file, and used the WP importer plugin rather than the events calendar import feature, which I’ll freely admit I hadn’t taken in – so that may be the source of the error. The XML file includes attendee data, so I’m leery of sharing it – and as it’s not your own import feature that’s caused the problem, you may (understandably) not consider it part of your support remit. Let me know if you’re still able to look into it – otherwise I’m happy to let it stand, as we’re not like to have to bulk import events onto our live site.
(I might raise a feature request for a CSV export facility, if there isn’t one already – the CSV import is fine for importing from a different system, but not, as it stands, from another WP site…)
