Chris Baldelomar

I do not have a member account. Can I sign up for one? I’m a theme author reporting a bug with the Lite version I bundle in my themes.

Send me admin access to your site, and I can see what the problem might be:

https://webplantmedia.com/support/

Hi Jeff, I did not quite understand your question. Can you send a link to a page with the problem you are trying to describe?

In terms of coding philosophy, I do not think it is wise for a plugin to change the behavior of an attachment permalink structure for a specific custom post type attachment page. First of all, it is inconsistent with the rest of the permalink structure for other attachments. Second, the WordPress core should handle how attachment permalinks should display, not a plugin. And third, you do not really know how other people are using product attachment pages. I would be wary about generally assuming that they are not used anywhere. People use WordPress and WooCommerce in many different ways.

Thanks for that information. It just broke Jetpack’s image attachment lightbox on old pretty attachment URL’s. WordPress now reads the old pretty attachment URL as a custom link, instead of an attachment URL.

At least I know what the problem is. Thanks for the information and quick response.

For new images that are uploaded, and that are attached to a product, the problem continues:

Recently uploaded and attached product image with ugly permalink.

Recently uploaded and unattached image with pretty permalink.

• This reply was modified 7 years, 1 month ago by Chris Baldelomar.

I did try regenerating thumbnails. I found out after I tested on another site with products: After I updated the WooCommerce plugin, the permalinks changed for the attachment from pretty to ?attachment_id={post_id}. So the bug is not with the update script.

Just to be clear, it was the database update script.

For a theme developer, would your recommend the remove_filter hack, or write my own author bio function. Really, all that needs to be done is for the <p> wrapper to be changed to a <div> element. Is WordPress planning on reversing this change?

Send a support ticket here:

https://angiemakes.com/support/

And I will reply back and you can send me admin access.

Yes, so far, with the hack, my theme import is working as expected. The transient is being deleted when the “appearance_page_pt-one-click-demo-import” is loaded, before the demo import begins.

So this action hook below returns the correct $selected_import value in your environment?

function wporg_ocdi_before_widgets_import( $selected_import ) {
	print_r($selected_import);
}
add_action( 'pt-ocdi/before_widgets_import', 'wporg_ocdi_before_widgets_import' );

By the way, thanks for such a great plugin. You guys also make great themes.

• This reply was modified 7 years, 10 months ago by Chris Baldelomar.

This hack temporarily solves my problem:

function wporg_current_screen( $current_screen ) {
	if ( 'appearance_page_pt-one-click-demo-import' == $current_screen->base ) {
		delete_transient( 'ocdi_importer_data' );
	}
}
add_action( 'current_screen', 'wporg_current_screen' );

• This reply was modified 7 years, 10 months ago by Chris Baldelomar.
• This reply was modified 7 years, 10 months ago by Chris Baldelomar.

If I add this piece of code to my theme files:

delete_transient( 'ocdi_importer_data' );

I get the correct $selected_import value.

Or, if I comment out this line in OneClickDemoImport.php Line 213:

// Is this a new AJAX call to continue the previous import?
// $use_existing_importer_data = $this->use_existing_importer_data();

Then I also get the correct $selected_import value.

It looks fine when testing on OSX and using Firefox. What browser/OS are you testing on?

Send a link to your web page so I can debug the accordion in my browser.