scmsteve

Trying to be helpful, it just occurred to me that maybe short-circuiting could come into play by moving the WHERE clauses around a bit. If I put the test for wp_posts.post_type = ‘tribe_venue’ at the top (under the 1=1), the query when run in a SQL tool goes to about 30s instead of the original 274s. Maybe that helps it avoid doing the LIKE comparisons on all our other post_type records of which there are many.

That is still quite long running in my mind, but better.

Moving the tests for post_status of publish or draft up just below the post_type test didn’t seem to improve things much, but not surprising as there aren’t many “tribe_venue” post types to filter at that point.

I did run those with specifying SQL_NO_CACHE in the query so they should be somewhat accurate timings. Original is about 150s and the rearranged one is about 30s on a test copy of our database here.

Looking at the last condition, it is a global OR so it isn’t tied in to only the post_type of tribe_venue. If I added the test for post_type and post_status inside that OR block as well, the query is almost instant.

I was going to try to change the plugin here to see if it helped in actuality, but I haven’t yet located where you are building that query. ??

After more searching, and finally doing a ‘grep’ through the plugin code base for some keywords I realized that WooCommerce at some point along the way added specific restrictions to anyone with the Shop Manager role so the only roles they could manage were “Customer” and “Subscriber”.

I was able to add a custom plugin (could have put it in functions.php) to filter this list and add the custom ones we wanted to use.

References:

In this article, they say Shop Manager will not be able to edit roles:

https://woocommerce.com/posts/a-guide-to-woocommerce-user-roles-permissions-and-security/

Here is a more detailed article about the security changes made in v3.4.6 and the filter to change it:

https://developer.woocommerce.com/2018/10/11/woocommerce-3-4-6-security-fix-release-notes/

I hope this helps someone else down the road if they run into this roadblock.

Slight correction, the only two roles available are “Customer” and “Subscriber”. Is this related to the use of the WooCommerce Add-On?

The HTML generated output just underneath the header is substantially different, up to the <article>, and after. I just included the part up to the article element.

2.6.3:

<div id="content" class="col-full">
		<section id="main" class="col-left"> 
	<article class="post-950 post type-post status-publish format-standard has-post-thumbnail hentry category-charlotte-mason category-featured category-planning tag-charlotte-mason-method tag-living-books tag-narration tag-short-lessons series-making-the-transition-to-cm">

2.7.1:

<section id="primary" class="site-content">
    <div id="content" role="main">
		<header class="page-header">
			<h1 class="page-title">Series: <span>Making the Transition to CM</span></h1>							<div class="archive-description"><p>Practical ideas and tips to help you make the transition to the Charlotte Mason Method in your home school.</p>
</div>
					</header><!-- .page-header -->
			<div id="pps-taxonomy-series-overview">
				<div class="pps-layout-default pps-columns-1">
<article class="pps-taxonomy-series__post">

I would be happy to share the full HTML privately if you would find it helpful.

The formatting with 2.7.1 does not have the right column of the theme layout, or even the left border, it is as though the content is a 100% width block under the header without accounting for any other theme layout. An image is attached showing a snippet of the page with with images/text pushed far left and text going to the far right.

I then attach an image of how it should look, and how it looks on v2.6.3. I have to downgrade to 2.6.3 and flush caches but then the correct layout appears.

Well, I can’t attach images here. ??

Incorrect:
https://drive.google.com/file/d/1fUTKeg-1jpLsb11B94HXMEpqoLxoPS2r/view?usp=sharing

Correct:
https://drive.google.com/file/d/1m2ri6NcbIfqu8Rstou2fQJPWWw3dIRX1/view?usp=sharing

Yes, it is set to Default here. It was set that way before, the problem is unchanged.

Also seeing this here on our old theme derived from Aaply. We had issues with earlier 2.7 version showing all articles in the sidebar instead of just the series, and now this version which fixes that (I think) has caused the layout issues. It’s a no-win.

Closing out, hope the official update comes quickly.

Correction, 2.8.8 seems to resolve it, but it installed as a separate plugin, I had to manually deactivate the “official” one and activate the 2.8.8-a-1 version.

Does that explain why it changes with page with of Original versus Large or Full Width? It doesn’t make sense that changing a width setting should affect vertical spacing of elements, especially other blocks.

We had this setting disabled, enabling it or disabling it doesn’t change anything.

• This reply was modified 3 years, 5 months ago by scmsteve.

Actually, I mis-read, it is allowing non-shipping items through *if* they are a fee I believe.

I tested with this:

function  my_shipstation_no_shipping_item( $no_ship_not_a_fee, $product, $item ) {     
        if ( 'fee' == $item['type'] ) {
                return true;
        }
}
add_filter( 'woocommerce_shipstation_no_shipping_item', 'my_shipstation_no_shipping_item', 10, 3 );

And it does seem to prevent fee items from being exported which is what we are looking for.

Tested with using the API call as documented on the plugin page to see the results ShipStation would get:

https://testsite.simplycharlottemason.com/?wc-api=wc_shipstation&auth_key=WCSS-3997b8e89f4c6637196deb60260574c4&action=export&start_date=06/22/2021T16:57:00&end_date=06/22/2021T16:59:00

[Note: dates are GMT, time seems to be ignored entirely, and uses pagination]

• This reply was modified 3 years, 7 months ago by scmsteve.

The graveyard of bug fixes. I do consider it a bug when the process would result in a loss of revenue because of incorrect data.

We will continue to pursue an alternate approach to push an update to the ShipStation order via the API if an order change is detected, I was just hoping this would be seen as important enough to implement, but given the other issues we have seen with ShipStation problems it seems the developers already have more than they can handle.

I am not ask you about custom order statuses. The customer support staff only modifies orders that customers contact them about between going to Processing and being shipped.

A custom order status is not an appropriate solution as *most* orders flow through normally, but when changes have to be made the ShipStation integration, as it stands, has no way to accommodate it.

We really need a way to do what I outlined, and that is to allow orders to flow normally, but *IF* a change is made to a WooCommerce order that either refunds and thereby removes an item, or even if the order is changed in some other way after it is synced, this needs to be pushed to ShipStation *immediately* or at least flag the order immediately in ShipStation so the shipping team knows that manual verification is required on this order.

As it is now, if *anything* seems to change on the order in WooCommerce, ShipStation doesn’t know about it and the wrong things will be shipped out. This can get quite expensive.

Thank you, that is helpful, but unfortunately the random (and sometimes long) intervals between automated updates is a big deal, and we can’t have them refreshing the store between every order they want to ship.

With my idea of writing a WordPress/WooCommerce plugin that acts on order status changes, sees if it was already sent to ShipStation, and then simply sending ShipStation an API call to change the order status may be more time effective.

It would be nice if the official plugin did this kind of thing, along with handling taking refunded items out of the order… ??

And as an added reason WHY I need to know… We often have customer support staff trying to help users make last minute changes to their orders, and I need to either write a plugin on WooCommerce to put the ShipStation order on hold via the API, tag it, or both, so that the warehouse staff knows that an order has been modified AFTER it was sent to ShipStation. Otherwise we will have shipments sent out from ShipStation that were perhaps significantly changed on the eCommerce side. We have already seen cases of this and a Google search shows we are not alone.