adelval

Avada 5.2 and Woocommerce 3.1.1, both up to date.

The problem I suppose is that I had the ‘Auto-sort’ option checked. But unchecking it and adding the orderby option for queries for other post types seemed too complex to be worth the trouble in my case. I’m mostly interested in ordering Avada portfolio items, and modifying those templates looked somewhat daunting.

Then I realized that Avada provides the filter fusion_portfolio_query_args to do just that, but by then I had already installed another ordering plugin.

Since Avada does recommend your plugin for ordering post types, you might want to ask them to include this in their documentation. Not sure whether they provide similar filters for other post types.

An alternative would be to somehow allow the Auto-sort option to be overriden for certain post types (in my case that would be products)

Thanks anyway

In case it is useful to somebody, I was also unable to save with an “internal server error” just today with version 2.0.11. The debug.log said it was an error with exceeding the memory limit in gettext.php. I increased the memory limit in wp-config.php, problem solved.

Done ??
And thanks for your speed with incorporating suggestions!

yep, fine with me, thanks!

álvaro

Oh, and it was 3 lines added, not just a one-liner ??

As said, I’d be thankful if you can include this (or similar) in the plugin. (The option name is a bit verbose, but I thought it was better to be explicit. Choose your name anyway)

Hi Johan,

Here it is (tested with your just released version 2.7.9):

function custom_post_widget_shortcode( $atts ) {
	extract( shortcode_atts( array(
		'id' => '',
		'slug' => '',
		'class' => 'content_block',
		'suppress_content_filters' => '0'
	), $atts ) );

	if ( $slug ) {
		$block = get_page_by_path( $slug, OBJECT, 'content_block' );
		if ( $block ) {
			$id = $block->ID;
		}
	}

	$content = "";

	if( $id != "" ) {
		$args = array(
			'post__in' => array( $id ),
			'post_type' => 'content_block',
		);

		$content_post = get_posts( $args );

		foreach( $content_post as $post ) :
			$content .= '<div class="'. esc_attr($class) .'" id="custom_post_widget-' . $id . '">';
			if ('0' == $suppress_content_filters) {
				$content .= apply_filters( 'the_content', $post->post_content);
			} else { $content .= $post->post_content; }
			$content .= '</div>';
		endforeach;
	}
	return $content;
}

Default usage is unchanged (i.e. previous usages of the shortcodes apply the_content filters as usual). To suppress the filters, use e.g. [content_block id=6636 suppress_content_filters="1"].

I had a similar problem with the addthis social plugin. After trying a number of proposed solutions (and as the poster above, not wanting to remove content filters altogether), the only one that worked for me was a simple style rule:

.widget_custom_post_widget .addthis_toolbox {
	display: none;
}

I mention this because 3 years after the addthis guys probably first heard about this problem (that’s the date of the link above) they haven’t done anything about it, and even they have recently removed some filters (addthis_post_exclude). Restoring these filters didn’t help with Custom Post Widgets, and neither did enabling custom fields in the plugin to add the addthis_exclude postmeta.

You might consider adding this simple solution to the FAQ.

Hi Marcin,

Could you please contact me at alvarodelval1 @ gmail . com about this post https://wpml.org/forums/topic/urgent-eta/

I tried to contact Jeff from Jigoshop but the address I have doesn’t work.

Thanks

Alvaro

This problem –which as pointed out by ReactorShop is not specific to buddypress– was driving me crazy, since it shows different behavior depending on whether you are logged in or not, the browser, and, in my experience, even on whether you are developing locally or in the production server. (E.g. it worked fine when logged in as admin in various browsers, but when not logged in you would get an insecure ajax url; but Chrome would let it pass, with an easy to miss console warning, while Firefox would block it).

But in the end the solution was simple.

Somewhere in my theme I have:

wp_enqueue_script('my-script', get_stylesheet_directory_uri().'/js/my-script.js',array('jquery'),false,true);
wp_localize_script('my-script','ajax',array('ajaxurl' => secure_ajax_url()));

where:

function secure_ajax_url() {
	$ajax_url = admin_url('admin-ajax.php','https');
	return str_replace('https://', 'https://', $ajax_url);
}

This outputs in the footer of the page:

<script type='text/javascript'>
/* <![CDATA[ */
var ajax = {"ajaxurl":"https:\/\/www.example.com\/wp-admin\/admin-ajax.php"};
/* ]]> */
</script>

Then in my-script.js I simply use ajax.ajaxurl as the url for ajax calls.

Hi kissiemeijer,

You say:
“I’m under the impression you think (after reading your first post) nested shortcodes are fairly easy. It’s not. How would WordPress differentiate between the nested structure you want and the nested structures other users want?”

Also:

“core developers choose speed using regular expressions over parsing text for opening and closing shortcode tags (slow).”

—

First, for the other posters, it’s mathematically impossible to handle nesting structures with regular expressions. So if WP insists on using regexes for this, the problem of nested shortcodes will always be there.

Second, parsing nested shortcodes is a matter of parsing a tree (in the CS sense), which can be done for example with a simple depth-first search. It’s pretty easy to do, I had to do it recently for a job interview. Browsers parse trees from strings all the time with the DOM.

Third, I doubt that regexes are more efficient than parsing a tree with depth first search. The latter is O(n), linear in the size of the string, the former is what? With all the needed restarts over the string when some partial matching fails… For example, here https://stackoverflow.com/questions/21669/complexity-of-regex-substitution it is said that the overall complexity is O(2^m + n), where m is the size of the regex, n the size of the string.

Finally, yes, nested shortcodes could be fairly easy with the right approach. A tree (or a forest) of shortcodes (i.e. one or more nested structrues of shortcodes) is either well-formed or not, just as xml is well-formed or not. It’s not at all a matter of “what users want”. And even if not well-formed, it seems pretty easy to handle it (just close any tag that should have been closed before reaching the closing of the parent’s -or some ancestor’s- tag). Regexes are simply not the right approach.

Cheers.

AdV

Hi Karly,

I checked, and the price filter does work with WooCommerce 2.0.x.

Would you consider upgrading? Unless you have a lot of custom code that depends on WC 1.6, upgrading is a fairly smooth process.

Do backup your database before upgrading if you decide to do it.

If upgrading is a problem, I’ll try to look into the problem with WC 1.6

Alvaro

Hi,

We do recommend upgrading to WooCommerce 2.x, though also try to keep backwards compatibility. Nevertheless, can you tell me what exactly is not working? In the page you link to, the only thing I see is that there’s a handbag without a price, is that the problem?

Also can you provide the information requested in the Getting Help section of https://wpml.org/documentation/related-projects/woocommerce-multilingual/? In particular, what version of the WPML plugins are you using, what is your default language, and what are your currency settings.

Alvaro

Hi,

From the docs at https://wpml.org/documentation/related-projects/woocommerce-multilingual/#translating-products:

Important notice #1: The synchronization is always relative to the original product , i.e. the product created in your site’s default language. Edits of any of the synchronized properties in the translated versions will be lost upon saving, because they are recopied from the original.

Does this help?

If you want us to test your site it’s better if you post it in our technical forum https://wpml.org/forums/forum/english-support/ where we have a procedure set up so that you can give us your access details safely. (Please make sure to tag the post with ‘woocommerce’ so that we don’t miss it).

Another thing: When you say ‘text based attributes’ do you mean ‘custom product attributes’ or (global) ‘Product->Attributes’ with ‘text’ instead of ‘select’?. We haven’t really tested the latter, and in fact I’m now checking a WooCommerce only (no WPML) test site and frankly I don’t know how they work. It turns out that they can be defined as taxonomies, you can add terms (i.e attribute values), etc. but then those terms do not show up in edit-product.

If you mean, custom product attributes, they should be copied over to the translated product just fine. In the backend you’ll see the values in the original language always, but they are translated in the front end.

More details in the documentation, that has had a major upgrade with this release.

Regards

Alvaro

WooCommerce Multilingual 2.0, compatible with Woocommerce 2.0.x has been released.
blogpost: https://wpml.org/2013/03/woocommerce-multilingual-2-0-released/
get it: https://www.ads-software.com/extend/plugins/woocommerce-multilingual/

In other words, a product appears in a store if its translation for that language is “published” (a product and its translated product are actually two different posts of custom type ‘product’). You can put a product on and off the store for a given language simply by changing its status between published and draft, which you can do with quick edit from the product list.