ioclaudio

Hi,

thank you for your answer.

I’ve solved. the problem was that the archive page of the content type was in conflict with the static page with the same name. Since I chosed not to use archive pages I’ve disabled them using the option

'has_archive' ? ? => false

in post type definition.

Claudio

@ravindra107 yes I could, but in this way they would be separate installations, I’d like to share the code but not the database. For example Drupal multisite allows this configuration.

It seems that this instead works:

if( ! function_exists( 'dli_get_content' ) ) {
	function dli_get_content( $slug, $content_type ) {
		$args = array(
			'name'        => $slug,
			'post_type'   => $content_type,
			'post_status' => array( 'publish', 'draft' ),
			'numberposts' => 1,
		);
		$posts = get_posts( $args );
		return $posts ? $posts[0] : null;
	}
}

You have to pass post_status, but I remember that before this code was working also without passing this parameter.

However it is not right that it returns the first object when it doesn’t find anything. Probably this is a bug.

Claudio

Hi,

this is the full function I’m using:

if( ! function_exists( 'dli_get_content' ) ) {
	function dli_get_content( $slug, $content_type ) {
		$args = array(
			'post_name'   => $slug,
			'post_type'   => $content_type,
			'numberposts' => 1,
		);
		$posts = get_posts( $args );
		return $posts ? $posts[0] : null;
	}
}

I call this function in this way:

$page_check = dli_get_content( $post_name, EVENT_POST_TYPE );

It doesn’t work either using ‘name’ or ‘post_name’ as parameter of the array.

Sorry, I don’t understand what do you need exactly.

Claudio

• This reply was modified 10 months ago by ioclaudio.
• This reply was modified 10 months ago by ioclaudio.

Hi @threadi thank you for your tips.

It seems a smart alternative, but I’m not sure I’ve understood well.

Do you add the same filter:

add_filter( ‘pluginname_add_settings’, array( $this, ‘add_settings’ ) );

to many classes, isnt’it?

But where do you call the apply_filters function ?

Thank you very much

Claudio B.

It was a snippet of code injected using the plugin WPCode.

It was added with an account that probably had a weak password.

cld

• This reply was modified 11 months, 1 week ago by ioclaudio.

yes

It is a custom theme that we have into a private repository and it was modified two years ago last time.

The copy on the compromised site is the same on the repository.

Thank you for your help, I’m reading these documents.

I have just a curiosity.

Using a new brand container and a new WordPress core and replacing the plugins with the original version taken from the official repository, I still have this problem of the redirect.

That is, only when you visit the site the first time it redirects you to a malicious site.

So I wonder how they managed to “dirty” the site and where does the malicious code reside? Any ideas on where to look?

Thank you very much

cld

• This reply was modified 11 months, 2 weeks ago by ioclaudio.

Yes, thank you, I’ve seen it but it seems a project not longer maintained

This can be marked as solved.

After looking the code of other plugins I’ve solved in this way:

(function () {
  "use strict";

....
  const title = settings.title || "";
.....


  const Block_Gateway = {
    name: settings.id,
    label: wpElement.createElement(() =>
      wpElement.createElement(
        "span",
        null,
        wpElement.createElement("img", {
          src: icon,
          alt: title,
        }),
        "  " + title
      )
    ),

...
  wcBlockRegistry.registerPaymentMethod(Block_Gateway);
})();

• This reply was modified 1 year, 1 month ago by ioclaudio.

no, thank you, I’ve solved the problem

cld

I’ve seen that the problem is that “starting with WooCommerce version 8.3, the Cart and Checkout Blocks are the default for new installations“.
So there are two way to solve the problem.

1. The first is to add the checkout block.
2. The second is to edit the page: Page->Checkout and disable the blocks in the checkout page.

Here some references to this issue:

• https://woo.com/document/cart-checkout-blocks-status
• https://www.ads-software.com/support/topic/custom-payment-gateway-is-no-longer-listed-in-checkout/

I think that it is a problem related to the fact that my plugin doesn’t support blocks. Does WooCommerce’s new checkout page use blocks? But I don’t understand why the plugin works with old sites updated to the last version of WooCommerce. Is there a way to disable blocks?