scmsteve
Forum Replies Created
-
I think this may be a false report by JetPack as digging into it further I see this, but it seems <=2.0 not 3.0.1…
https://wpscan.com/vulnerability/b8fd8563-d513-470b-a60d-272fd1e8cf14/
Forum: Plugins
In reply to: [WP-Memory-Usage] v2.2.0 lost a lot of values?Thank you so much! While it is true you can have too much data, in this case it was some of these other values that helped troubleshoot my poor performance so hopefully they will help others as well! Your inclusion of an AI prompt is fantastic also!
Forum: Plugins
In reply to: [WP-Memory-Usage] v2.2.0 lost a lot of values?Thanks, just FYI, here is a snapshot of the prior version compared to the new version so you can see what I meant by values are missing, there is not nearly as much information in the Diagnose tab. And, by the way, THANK YOU, it pointed out a few things I didn’t think of and after tuning (see below, opcache 99.89% hit rate) the site is much more performant.
We have determined that it is, well, sort of normal. ALthough I don’t know why it wasn’t happening before, but that doesn’t really matter I guess… But yes, the bottom line is that after the User Menu plugin had removed all of the menu items due to restrictions Blocksy took that blank menu and using the standard WordPress behavior it generated the menu of all top level pages. They said this is the defined behavior if you use a menu that is not defined or has no entries. So to fix it, since all the menu items we needed were filtered for logged in users only we just added a “Log In” entry so that other users had an entry in that menu.
Once I dug in a little bit deeper it gets interesting… Blocksy must be the agent that is “collapsing” the menus on the page into the Hamburger menu on mobile or in a small browser window. If the window is large enough so that all the menus are “expanded” or “full size” then there is no problem, it is only when collapsed into the hamburger menu.
We have a menu that has all choices marked via your plugin as available only for logged in users. This works fine on a normal page view. The problem is that if this menu is active and your plugin is active then when Blocksy builds (?) the hamburger/mobile menu it adds a weird “site map” kind of menu with options for all/many (?) pages on our site.
Today I figured that it might be because the menu it was trying to use had no choices so I added a “Log In” option to this secondary menu so that it would have a choice for users who aren’t logged in and now the hamburger/mobile menu that is constructed works fine. If not logged in you see the Log In choice, if you are logged in you see the other choices in that menu, and the “site map” menu is gone.
I am pushing this back to Blocksy, it has to be deteremined who is or how the hamburger/mobile menu is constructed. They thought it was your plugin, but I think what happened is that if your plugin wasn’t active then the test for those menu items (logged in only) didn’t exist so there wasn’t an empty menu. Let me see what they have to say about this.
From what I gather it is because things are being loaded too early, as it says, so I edited the main plugin file “remove-dashboard-access.php”.
I wrapped the initialization bits into a function and call that upon init instead of when the plugin is loaded:
function rda_do_init() {
// Load options instance
if ( class_exists( 'RDA_Options' ) ) {
$load = new RDA_Options;
// Set up options array on activation.
register_activation_hook( __FILE__, array( $load, 'activate' ) );
// Run it
if ( class_exists( 'RDA_Remove_Access' ) ) {
$access = new RDA_Remove_Access( $load->capability(), $load->settings );
}
}
}
add_action('init', 'rda_do_init', 10);It looks like the bbPress code in your plugin is only calling C4WP_Captcha_Class::verify() but is never looking at the test used elsewhere {is_user_logged_in() && C4WP_Hide_Captcha::c4wp_hide_for_logged_in_user_or_role()} so perhaps that is why it fails in this case??
Hi @dvankooten – Thanks for providing the information so I could hot-patch our installed version and it does seem to work. Looking forward to the updated version, and I really do appreciate your time to resolve this. UPDATE: I see you have already pushed out the new version, thank you for being so fast to resolve this!!
I believe the code is in the ‘additional_checkout_fields()’ from woocommerce/includes/class-wc-emails.php.
It is hooked in the _construct() for that class:
add_action( 'woocommerce_email_customer_details', array( $this, 'additional_checkout_fields' ), 30, 3 );
Maybe we could deregister that in a custom bit of code? But there may well be other cases where we would want/need other additional fields output. I guess the question is how/why MC4WP is storing it in a metadata that WooCommerce thinks needs to be output, right? Or deregister that and replicate the code but filter out the MC4WP metadata? But seems that would be in danger of getting out of date as their class changes in the future.You could just place an order and observe the email, the plugin I mentioned doesn’t do anything special it just lets you see the emails after the fact.
I see where WooCommerce is inserting this data based on order metadata. Test like so:
I can see where WooCommerce, in the email logic, is doing the "additional information" block. It gets two types of fields
use Automattic\WooCommerce\Blocks\Package;
use Automattic\WooCommerce\Blocks\Domain\Services\CheckoutFields;
$checkout_fields = Package::container()->get( CheckoutFields::class );
$cf = $checkout_fields->get_order_additional_fields_with_values( $order, 'contact', 'other', 'view' );
$of = $checkout_fields->get_order_additional_fields_with_values( $order, 'order', 'other', 'view' );It is the “order” additional fields that are outputting this, and it is becuase of the “_wc_other/_mc4wp/optin” metadata on the order.
Is this a new piece of metadata, or has WooCommerce just started including it in emails recently? Is there a way to disable it?
Clearly security is not a priorty.
Forum: Plugins
In reply to: [TI WooCommerce Wishlist] Another vulnerability@templateinvaders Would you PLEASE address the status of this plugin? Getting no response to any inquiry but yet seeing occasional bits of activity here is puzzling. Also, there was a user-submitted (required) patch for product bundle compatibility but you didn’t include that in 2.9.1? What is going on???
Forum: Plugins
In reply to: [Event Tickets and Registration] Slow queryOoops. Looks like our team changed form using this ticket module to WooCommerce Bookings. This query seems to be coming from there, so false alarm. Sorry! Not much to go on when jsut viewing the slow query log. 🙂
Forum: Plugins
In reply to: [Event Tickets and Registration] Slow queryLooking at the most recent time this happened, it seems to have conincided with a new order being placed. Is there perhaps a hook being called on order completion or the thank you page looking to see if the order contains a ticket? This order did not. But it seems it would really slow down the order checkout/confirmation process to have this long running query in there.