Anon_

			$query->set('meta_key', 'プラン');
			$query->set( 'orderby', array('meta_value_num' => 'desc', 'date' => 'desc') );

Change to the above code and the SQL that can be retrieved is as follows.
As expected, articles without custom field keys do not seem to be retrieved.

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID
					FROM wp_posts  LEFT JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
					WHERE 1=1  AND ( 
  wp_term_relationships.term_taxonomy_id IN (673)
) AND ( 
  wp_postmeta.meta_key = 'プラン'
) AND ((wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'acf-disabled' 
OR wp_posts.post_status = 'private')))
					GROUP BY wp_posts.ID
					ORDER BY wp_postmeta.meta_value+0 DESC, wp_posts.post_date DESC
					LIMIT 0, 10

Apologies for the inclusion of Japanese.
The word “plan” should be replaced by “plan”.

With the method you have presented, articles that do not have “plan” registered in meta_key will not be retrieved, will they?
Articles that existed before the custom field was created have no custom field registered.

Sorry, the above query, but I posted it once by mistake and have corrected it.

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID
					FROM wp_posts  LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )  LEFT JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id AND mt1.meta_key = 'プラン' )
					WHERE 1=1  AND ( 
  wp_postmeta.meta_key = 'プラン' 
  OR 
  mt1.post_id IS NULL
) AND ((wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'acf-disabled' 
OR wp_posts.post_status = 'private')))
					GROUP BY wp_posts.ID
					ORDER BY CAST(wp_postmeta.meta_value AS CHAR) DESC, CAST(mt1.meta_value AS CHAR) DESC, wp_posts.post_date DESC
					LIMIT 0, 10
				

• This reply was modified 1 year, 9 months ago by Anon_.

Thanks.
I imported it into a site built with Docker and it imported successfully.

https://community.localwp.com/t/413-request-entity-too-large/32052

I have asked questions, but no one seems to be able to answer them.

I changed “Enviroment” to “custom” but the symptoms remain the same.

I changed from Apache to nginx.
No change.

The problem that was occurring with IPN has been resolved.
We confirmed that the status on the woocomerce side changes without having to go back to the site at the time of purchase.
Thanks.

Warning: shell_exec() has been disabled for security reasons in

The above message is displayed.
It seems that access is still not allowed.

I would like to try this in a standard LAMP environment.
Thanks.

The server was Linux and the relevant files existed in /proc/.
I have cpanel installed on this server to manage multiple sites, does this mean that access to this file is controlled?

I understand that it does not work locally.
By the way, it is not working on a Linux server either.

So it is not listed in php.ini.

I understand how refunds work.
Thanks.

It seems that the IPN setting was still the cause of the problem, and the status change on the order is now normal.

One question: When I change the status of an order to canceled from the Woocomerce admin page, is the payment on PayPal automatically canceled?

Sorry for the misunderstanding.
The official plugin is for PayPal payments, not Braintree.

I will try to contact Braintree support.

Thanks.