AEG-wiz

You’re welcome, newbie357 ??
I do think it’s important to remember though that these are free resources you are using. That doesn’t excuse shoddy work, but it does mean that developers have generously put their time and talent to use without charge, so that others may build websites without advanced skills, knowledge, or investment. It can be hard to keep up with support requests, and the developer may just not be able to respond immediately.

You might be better served by choosing a WordPress theme that explicitly supports WooCommerce. There are many of them out there, and it should address the kind of conflicts you are experiencing with thumbnails. Raindrops simply wasn’t tested for use with WooCommerce. That doesn’t mean you can’t use it, but with any theme that hasn’t taken WooCommerce support into consideration specifically, there may be minor issues such as this one you’ve encountered – really, through no fault of the developer.

Well, it’s your theme: Raindrops that is adding the second image. The theme developer has defined a function called ‘raindrops_fallback_title’ which inserts the extra thumbnail. Specifically, if I comment out code line 4064 in the functions.php file, the additional image goes away. But that’s just a quick hack to identify where the problem ends (not where it begins), and commenting that line out would impact other areas on your website besides just the Shop page.

It doesn’t sound like you are familiar with code, so the gist of it is, there isn’t a simple checkbox fix for this issue. You’re best bet is to contact the developer for the Raindrops theme and see if they can point you to the right way to override that functionality.

newbie357, it looks like the theme (or maybe a plugin) you are using tries to automatically add a thumbnail next to the title. The top image you are seeing on each product in your Shop page is put there by WooCommerce. But that bottom image is being inserted by a theme template or plugin script. See how it’s a bit blurry? That’s because it’s taking the Featured Image for the product and creating a small thumbnail image to sit beside the product title.

If you look at the HTML for each product a normal WooCommerce product title just looks like:
<h3>Monthly Membership Coupon</h3>

Whereas yours has extra elements inserted:

<h3>
    <span class="h2-thumb">
        <img width="48" height="48" src="https://www.ourcarebooks.com/wp-content/uploads/2015/08/Free-1-Month-Membership-Special-150x150.jpg" class="attachment-48x48 wp-post-image" alt="" style="vertical-align:middle;">
    </span>
    <span class="entry-title-text">Monthly Membership Coupon</span>
</h3>

I’d check your theme’s content templates and/or functions.php file to see if you can find a place where an h2-thumb class is being added to post titles. I hope that helps to point you in the right direction!

I didn’t run into quite the same issue as you venicedesign, but someone was trying to login to my admin account and subsequently locked the credentials. I just wanted to add that the lock is stored with metakey: theme_my_login_security in the usermeta table of your wordpress database.

If you do a search for that key, you should be able to address the issue manually in the future. (For instance, I left the metadata there and just changed the “is_locked” boolean in the serialized array from 1 to 0.)

Take a look at the preview link button in the publish metabox on the edit screen, how does it look?

Ah, now that brings the issue to something interesting I noticed yesterday while testing:
Right-click ‘open in new tab’ on the preview button opens the permalink structure link (and also does not work – even for logged in users). While just normally clicking on the preview button, directs the preview to the non-permalink URL. If I rollover the button or inspect its properties, it is permalink. But apparently there is some sort of javascript attached that rewrites that on the click event.

Did you tested the dev version? Still a problem?

Yes, I did test it. What you see above are the results of that test. I still get rewritten links. Perhaps it is because of the custom post type. If all I have to do is add the p parameter back onto the link, then it isn’t such a big deal. I was having issues with that approach yesterday, but that shortcut seems to be working again with the new code you provided.

Here’s an example of my permalink structure:

Custom Post Type: portfolio (rewritten to ‘directory’)
https://wp.mydomain.com/?p={post_id}&post_type=portfolio
gets rewritten to:
https://wp.mydomain.com/directory/{post_name}/

Preview link provided by plugin:
https://wp.mydomain.com/directory/{post_name}/?preview=1&_ppp={nonce} DOES NOT WORK FOR PUBLIC PREVIEW

adding ‘p’ parameter back:
https://wp.mydomain.com/directory/{post_name}/?preview=1&_ppp={nonce}&p={post_id}
automatically redirects to:
https://wp.mydomain.com/?p={post_id}&post_type=portfolio&preview=1&_ppp={nonce} THIS LINK DOES WORK FOR PUBLIC PREVIEW

Hi Dominik.

I was a bit confused by your earlier post made 2 days ago, but if I am reading it correctly you are saying that the preview links are not expected to be rewritten as permalinks, based on your code logic. I downloaded the zip you provided above, and tested the links again.

I am seeing the following behavior: My preview links get rewritten with the permalink structure with preview=1&_ppp={nonce} appended. If I add the p={post_id} parameter back onto the URL it works fine for public preview (NB: adding the p parameter to the permalink structure and submitting it to the browser then redirects the URL back to it’s non-mod_rewrite state). But as provided, the preview link does not work.

This is some improvement over testing problems I encountered yesterday, but so far it appears that the ‘p’ parameter is always converted into the permalink structure instead.

Also, I am not using the plugin you mentioned above – nor anything similar. I did disable all plugins earlier in my testing without impact on Public Post Preview.

I have to say I also agree that some expiration choices in the GUI would be highly preferrable. A drop down that defaults to 24hrs but also offers 1week, 1month, 1year and never would be ideal to me. Followed below by a date showing me when the link will or did expire.

It’s the idea that a check box is enabled but my link has actually expired (and there’s no indication of when it expired or whether it’s still valid) that’s a very confusing user experience for me. “Preview Link” is “enabled” but it may not be valid – that’s just counterintuitive for me.

I personally will use the plugin not to expire the previews (so I’ve applied the filter). But it would be nice to be able to decide on a post by post basis.

That being said, I do understand that most will appreciate the security of an expiring link. 24hrs is pretty short though. I don’t feel I can depend on people to respond that quickly. So I made mine non-expiring and I added a column in my tables to show me where I had enabled links so that I could disable them when I was done — now that I think of it, I haven’t tested if that does invalidate the link. I’ll have to check.

For anyone looking into the same problem, I’ve just discovered that I don’t have to remove the permalink structure, I can just append the &p=[post_id] directly to the preview link provided for success. Works for my permalink structure anyhow which is fairly simple /%postname%/.

Dominik: one way that you may be able to help fix this in future releases is by adding the preview_post_link and/or preview_page_link filters to your get_preview_link method.

An example from /wp-includes/meta-boxes.php : post_submit_meta_box() is as follows…

$preview_link = get_permalink( $post->ID );
	if ( is_ssl() )
		$preview_link = str_replace( 'https://', 'https://', $preview_link );
	$preview_link = esc_url( apply_filters( 'preview_post_link', add_query_arg( 'preview', 'true', $preview_link ) ) );

That is the code used for the preview button in the submit/publish metabox on the edit post page. With that filter in place in your plugin, those of us affected could hook into it and add the required p var.

Hope that’s a helpful start.

Hi Dominik.

I’m noticing the same thing. Since you haven’t yet received a response from mike, I can at least provide you with my settings:

using W3 Total Cache and just the ‘post name’ permalink setting (/%postname%/)

I haven’t messed around yet with disabling things to test it out. But I can confirm that a preview link that isn’t using mod_rewrite (i.e., manually changing the provided preview URL to the querystring vars instead) works fine, while the permalink structure does not.

This of course refers only to users who are not logged in, since all logged in users on my site have permissions to view previews for the post_types in question (this is a custom post_type I’m working with so far, by the way — though I assume it would be no different for ‘post’). Also potentially pertinent: the post_type uses a rewrite value too, though it is not visible in the post or preview permalinks, it is provided in the ‘register_post_type’ call.

I’ll be looking into a hook to rewrite the permalinks without the mod_rewrites if you aren’t able to find a fix. Perhaps ‘preview_post_link’ depending on what your code does.

Thank you!