Maxim Akimov

Hello.

We were late in responding to the WP plugin team’s request, which mainly involved some minor changes to the README, and they temporarily closed the plugin.

We’ve already made the requested changes and are now awaiting their response. We expect the plugin to be back within a short time, hopefully within the next one or two days.

no, other changes are not required in this case.
When FS storage is in use, code from the theme folder is used directly.

• This reply was modified 2 weeks, 4 days ago by Maxim Akimov.

We have indeed made the Controller execution logic in 3.9.2 stricter, but it doesn’t affect any valid snippets.

Your PHP controllers look invalid, as :

1. have methods like “get_variables” commented out (the comment seemed to be merged)
2. include the Pro version mention “use …\Pro\Bridge\Views\Custom_View_Data”

Have you ever had a Pro version on this setup?

At this stage, I would recommend you to:

1. back up the “advanced-views’ folder inside your theme
2. update all your “advanced-views/layouts/*/controller.php” files to the valid content (provided below)
3. update the installation to the latest version (you can do this on Staging firstly, if you have it)

After that, it should execute Controllers without any issues.
Valid Controller code:

<?php

declare(strict_types=1);

use Org\Wplake\Advanced_Views\Bridge\Controllers\Layout\Layout_Controller_Base;

return new class extends Layout_Controller_Base {
    /**
     * @return array<string,mixed>
     */
    public function get_variables(): array
    {
        return [
            // "custom_variable" => get_post_meta($this->get_object_id(), "your_field", true),
            // "another_var" => $this->get_custom_arguments()["another"] ?? "",
        ];
    }
    /**
     * @return array<string,mixed>
     */
    public function get_variables_for_validation(): array
    {
        // it\'s better to return dummy data here [ "custom_variable" => "dummy string", ]
        return $this->get_variables();
    }
    /**
     * @return array<string,mixed>
     */
    public function get_ajax_response(): array
	{
	    // $message = $this->get_container()->get(MyClass::class)->myMethod();
		return [
			// "message" => $message,
		];
	}
	/**
     * @return array<string,mixed>
     */
    public function get_rest_api_response(WP_REST_Request $request): array
	{
	    // $input = $request->get_json_params();
	    // $message = $this->get_container()->get(MyClass::class)->myMethod();
		return [
			// "message" => $message,
		];
	}
};

@rpittam closing this topic as the validation issue is sorted. Please re-open if you still experience any issues.

• This reply was modified 1 month ago by Maxim Akimov.

@japgarmaps since June WP.org introduced a plugin-upgrade delay, which they use to perform security reviews. So unfortunately upgrade will only be available in approx. 3 hrs.

But it doesn’t touch new installations. Therefore, as a workaround, you can remove the plugin (without data removal) and install it from the dash plugin search.

Hi @rpittam,

We’ve checked the ACF checkbox usage with a custom Twig template on our side:

1. it works overall, and displays values on the front side.
2. it’s indeed shows a false validation alarm on single-var loops (default markup now uses 2-var loops). We’ll back the single-var support in the upcoming release, hopefully today.

But the thing is that the issue you mentioned happens only for editors during the save process, so it doesn’t affect front displaying at all – otherwise, site guests would see no Layout at all, while admins would see a rendering error message.

I would recommend to review the “but can be disturbed during“-related logic in your template, e.g. print all comparing field values, just to ensure your condition still matches the actual values.

Let me know if you need any further assistance here.