jpowersdev

Hi @clifhaley,

It looks like the form is just too wide for that spot. Even though it’s “inline”, it’s wrapping to the next line.

You can fix that by using flexbox. Here’s an example that only applies to screens above 650px (it looks fine below that):

@media(min-width: 651px){
	{
		.yikes-mailchimp-form-inline {
			display: flex;
			align-items: flex-end; // to account for the labels.
		}
	}
}

I only checked the page you sent me, so you’ll need to make sure there aren’t other forms that this interferes with. If you have to make it more specific, you can change the selector like this:

#dime-newsletter-1.yikes-mailchimp-form-inline

Let me know if that helps,
Jon

Hi @visionsub,

So the >= symbol that you’re using here is a Unicode symbol, it’s not regular ASCII text. You can try using the HTML entity version of that symbol, which is ≥

It looks like it works on some of your pages and not on others, so it might be a browser issue as well.

Let me know how it goes,
Jon

Hi @danidub,

I’m starting to think this is an encoding issue. The byte lengths of these strings in the serialized data are not what my computer or these external unserialize tools expect them to be, and that could be down to the encoding. If the old site is using a different encoding (ISO and not UTF-8), it would still work on the old server but not the new one.

For example, the content of the first tab is listed as having a byte length s:810, but on my local machine (where I am using UTF-8), the byte count is actually 793. Making that change fixes that error, but then the next content block breaks.

If you have SSH access to the server, you can confirm this by running the locale command and checking the LANG= part at the beginning. If this is in fact your problem, you’re going to need to do some sort of conversion during the export process. Fortunately, woocomm has an easily extendable export tool. If you look here, the add_export_data function provides an opportunity to modify the data before it prints to the spreadsheet.

You should just be able to modify the encoding of the string and return it. Knowing how to do that requires knowing the original encoding. Alternatively, you can use that function to convert the data from serialized data to something like JSON, which does not store byte length. If you wind up going in that direction, this knowledge base article will help you set up the import part of that process.

Good luck, and let me know how it goes.
Jon

Hi @danidub,

So in the example you sent, your site is treating the entire block of serialized data as a string because it’s not properly formatted data. It seems like the problem here is the export process, not the import process.

If you look in the database on the original site and check the meta for the example you are using, does the meta value line up with what you see in the export spreadsheet? If not, does running that value through the serialized data tool display any errors?

Let me know what you find,
Jon

Hi @jessie1,

If you have a caching plugin, it’s worth trying to clear it. There’s a chance the markup for an empty list of tabs is still cached.

Assuming that isn’t the problem, there is likely a conflict with one of the other plugins on your site. Do you have any other plugins that modify the WooCommerce tabs or any other part of the Edit Product page in your site admin?

Jon

Hi @ekswk,

It doesn’t look like you’re using our plugin, but your theme has this smooth-scroll js file which is interfering with the WooCommerce default scrolling behavior.

Jon