Simon Kane
Forum Replies Created
-
Forum: Plugins
In reply to: [User Switching] No switch_user capability (possible post 5.5 update issue)The actual capability name is “switch_users” — with an S on the end.
For some reason, this capability is needed for my Woo “Shop Manager”s in order to access certain customer types, even though they have edit_users – but the Shop Managers also can not edit customers (which are cloned from Customer), so it is probably the same issue as that.
Having not seen the obscure FAQ entry, I was trying to use the switch-to-user capability – of which I do not understand why two – what is the difference ????? argh.
Forum: Plugins
In reply to: [Login as User] CRITICAL – plugin broken as of Woo 4.6.0FYI: Similar plugin “User Switching” is working.
It’s just not as friendly as yours (no banner)
There are MANY business models that require post-shipment order activity.
Not everything is “gimme money, we’ll mail you crap’.These include (there are many more):
1. B2B with payment after-the-fact (eg. invoicing net 30).
2. Post-shipment installation support (here’s your stuff – we’ll call you).
3. Post-shipment upsells.All of them require status OTHER than “completed” after all shipment(s) are made. Some of them require multiple order statuses between shipped and complete – but that’s not your problem, and is handled by other plugins and business activities.
The problem is that you have hard-coded ‘complete’ because of your narrow view of how people use WooCommerce.
All that’s needed to totally solve this issue is to NOT trigger all the actions that setting status=complete does. This involves adding one option and using it in place of the hard-coded ‘complete’ constant in 2-3 places in your code. The option should use a drop-down list of values populated from the wc_get_order_statuses() function call. Obviously the default value of the option would be ‘complete’.
Forum: Plugins
In reply to: [Media Sync] Enhancements?Howdy!
Great! And before I forget, huge kudos for your extensive error checking code. Everyone should do this sort of thing, but it seems to be a lost art to “modern developers”.
I have looked at filters vs. actions, and I think this fits better as a filter – which, while I don’t need it, allows for more control over the call to wp_update_attachment_metadata. Return an empty array and that indicates the filter handled it already. Could be useful for more complex handling where the user needs the metadata to be created before they can do other things, or even just add their own metadata to the returned array.
If I am unclear with the above, it should be obvious when I send you the code – which will hit MediaSync.class.php at line 766. Fortunately, the wp_update_attachment_metadata call which follows is the last thing that function does, so it won’t require conditional code – just an early exit (return).
I hope to have the code written and tested this weekend.
We’ll discuss what I’m talking about with the other enhancement a bit later, as this one is the pressing need for the client project I’m on.
I have the same need.
I think you are seeing “shipped” because you have “renamed complete to shipped” ??
In any event, the plugin has status ‘complete’ (wc-complete) HARD-CODED.
One solution would be to treat the “add shipping” new status checkbox to act more like the partially shipped checkbox – with the new status being a user-specified value instead of HARD-CODED. Alternatively, implement a filter to catch it – that filter could also be used for ‘partially-shipped’, thereby giving the user even more flexibility and control. However, the latter would not provide proper text in the “add shipping” meta-boxes, so a combination would be best.
In my case, I have a custom status (from a different plugin) of fully-shipped. This is useful because it does not trigger actions/filters that are tied to “new-status is complete” when such is not desired.
Forum: Reviews
In reply to: [Media Sync] It doesn’t Sync mediaDid you remember to uncheck “Dry Run”?
Forum: Plugins
In reply to: [WooCommerce] /wp-json/wc-analytics/ causing server issuesOK – I’ve got a thread open to the plugin developer with what appears to be an ACTUAL solution. Not a perfect one, but it sure seems to KILL THE BLOAT.
Hopefully the plugin dev will add the bit of code needed to keep this wc-analytics monstrosity from eating our servers.
https://wordpress.org/support/topic/plugin-breaks-woocommerce-payments/#post-13522012
ARRGGHH.
The snippet to kill the wc-analytics endpoint as posted above has a stray bang (!) in front of the fnmatch – remove it.The original snippet is set to keep ONLY the prefixed items while we want to keep all BUT the prefix.
Sorry about that chief!
Forum: Plugins
In reply to: [WooCommerce] /wp-json/wc-analytics/ causing server issuesI found a plugin that kills a bunch of WP/Woo BLOAT.
I found that it does not support keeping Woo Payments running while getting rid of the BLOAT. I’ve hacked some stuff in that might let it work – but I can’t be sure at this point. I’ve sent info to the plugin developer, and maybe his expertise can smooth it out. The plugin is: Plugin: Disable WooCommerce Bloat
But the REAL solution is to provide wp-admin control over the BLOAT.
SO – if all my above checks out from an independent test, I would suggest adding support for Woo Payments like for the Marketing Hub, and add the REST endpoint killer shown above as a new quick option – that may be useful across the board.
OK, one more step through the swamp.
Kill the REST endpoints. Ya, they’ll probably still get called – but should yield a 404 and not eat the server. I am see the the call that (I think) triggers the REST happening, but I m not seeing any delay in response – and it was a solid 60+ seconds every time before).
HUGE shout out to:
https://wpreset.com/remove-default-wordpress-rest-api-routes-endpoints/
for the code below.
Throw this in somewhere (I have it in my theme/functions.php// —————————————————————————
// Kill the wc-analytics REST endpointsadd_filter( ‘rest_endpoints’, ‘kill_wc_analytics_endpoints’ );
function kill_wc_analytics_endpoints( $endpoints ) {
$prefix = ‘wc-analytics’;foreach ( $endpoints as $endpoint => $details ) {
if ( !fnmatch( ‘/’ . $prefix . ‘/*’, $endpoint, FNM_CASEFOLD ) ) {
unset( $endpoints[$endpoint] );
}
}return $endpoints;
}Well, I think “Payments” works like “Marketing Hub”.
I found:
plugins/woocommerce/packages/woocommerce-admin/includes/includes/feature-config.php
……
function wc_admin_get_feature_config() {
return array(
‘activity-panels’ => true,
‘analytics’ => true,
‘analytics-dashboard’ => true,
‘analytics-dashboard/customizable’ => true,
‘coupons’ => true,
‘devdocs’ => false,
‘marketing’ => true,
‘onboarding’ => true,
‘remote-inbox-notifications’ => false,
‘shipping-label-banner’ => true,
‘store-alerts’ => true,
‘unminified-js’ => false,
‘wcpay’ => true,
‘homescreen’ => true,
);
}
……I hacked your lovely plugin to hard-code add (jeez – I’m just testing LOL)
code to the marketing disable code: function disable_features( $features ) {
……
$analytics = array_search(‘analytics’, $features);
unset( $features[$analytics] );
$analytics = array_search(‘analytics-dashboard’, $features);
unset( $features[$analytics] );
$analytics = array_search(‘analytics-dashboard/customizable’, $features);
unset( $features[$analytics] );
$marketing = array_search(‘marketing’, $features);
unset( $features[$marketing] );
return $features;
……
When “WooCommerce Admin” is re-enabled, Payments comes back and seems A-OK on front-end, payments section, and dashboaard.Unfortunately, the blasted wc-analytics background tasks still trigger. 🙁 🙁
Forum: Plugins
In reply to: [WooCommerce] Disable (slow) WooCommerce AnalyticsProblem STILL EXISTS out here in the real world.
Forum: Plugins
In reply to: [WooCommerce] /wp-json/wc-analytics/ causing server issuesI have nothing to import – and also don’t see how this would help. If you have some insight, that’d be great.
Also – anybody else have a solution?
Yes, it is now working for me.
Maybe you should have an actual QA environment and testing protocol instead of using “development”. :/