PHP Notices
-
Hello,
I’ve been running your plugin for awhile now and have been noticing my debug log being filled with a couple of PHP notices. I’m reporting them here so that they may be fixed in a future version of this plugin:
Undefined index: current_section in constant-contact-woocommerce/src/View/Admin/WooTab.php on line 240 Undefined index: id in constant-contact-woocommerce/src/View/Admin/WooTab.php on line 309
-
Howdy @howdy_mcgee 😀
I will get these logged so we can investigate getting them handled for you. Thank for the feedback.
Hello,
Any updates on this? I just had to remove a 14MB error log because of these notices 🙁
This issue is not resolved.
Hi,
I’m not presently managing to recreate these notices specifically, but I definitely believe they are happening in your case right now. We’re not denying it.
That said, I know that the content in question for those lines are passed through a lot of various places, and for some reason it’s not having the indexes like expected.
Let me check with the team and I’ll hopefully get back to you soon.
I also am trying to debug the issue. If I were to guess based on my logs it has something to do with requests from the REST API. Accompanied with these errors I have references to
Undefined index: id in /woocommerce/packages/woocommerce-rest-api/src/Controllers/Version2/class-wc-rest-setting-options-v2-controller.php on line 341Which would explain why it can’t access the
$current_screenglobal. I haven’t figured out why the object would be missing theidproperty though when it’s clearly given a default at the top of the class definition.I tried to run a
debug_backtrace()on the issue but it looks like my server simply can’t handle it. I run into a memory issue.Unsure if you have a dev copy of the site that may or may not be having the same errors show up, but I wonder if they’d still be there with just WooCommerce core and our plugin as the only other Woo-based extension. Curious if something from a different plugin is having effects here.
Alright after some digging this _may_ be the cause.
LN 309 loops through some settings fields. Specifically there’s a conditional that says:
$field['option_key'] = $field['option_key'] ?? $field['id'];IF
option_keyexists, use it.
ELSE use theid.Printing the fields gives me a fairly large array which can be tracked back. One of the items in
get_customer_data_settings()method of the same file ( LN 492 roughly ) neither has anoption_keyorid. Specifically for the 2nd index:> Start marketing to your customers…
I think by giving that an empty ID will fix the
Undefined index: idissue but there may be more settings that neither have a key or id.Still looking into the
current_sectionissue.In terms of the
get_customer_data_settings()method, the Import contacts title part DOES have an id value specified, but the “Start your marketing…” one does not. Both are title field types.I’m curious if throwing in some random value would suppress that for you. If you’re willing to try and see if it does, we can then most definitely get that fixed up ahead of a new release, on top of some parts we’re already looking at to help with this topic.
Regarding current section, I’m betting that since this is all relating to making use of the REST API aspect, that global may just not be getting set, while the filter is still getting used.
Hello,
Thanks for the reply, that’s exactly what I did yesterday. Adding an
idto the “Start your marketing” subarray seems to have solved that issue. I’m still fiddling with thecurrent_sectionto see what I can discern but I agree that it’s likely a REST issue. I’m testing against the REST portion now and will let you know tomorrow!Just kidding about letting you know tomorrow 🙂
Testing against
defined( 'REST_REQUEST' )makes it clear that it is a REST issue. I’m not sure how your team wants to handle it but a possible solution:$section = null; if( defined( 'REST_REQUEST' ) ) { $section = 'REST'; // Maybe there's a way to get the requested rest route? } else if( isset( $GLOBALS['current_section'] ) ) { $section = $GLOBALS['current_section']; } return apply_filters( 'woocommerce_get_settings_' . $this->id, $settings, $section );I believe we’re eying just doing a bit better in checking for a value, in order to suppress that notice during REST requests. It’s a setting and filter that’s more for the WP admin anyway, but obviously parts crept through.
Thanks for helping dig in and debug, we appreciate all the extra eyes and help.
The topic ‘PHP Notices’ is closed to new replies.