Luis Godinho

Well following up my last comment, and as stated by @roccocontillo, I confirm that multiple other WordPress media folder plugins in the repository, which target the same features like HappyFiles, have the same limitation (up to 10 folders). They are all still listed.

I found out as well that plugins like Jetpack and Yoast SEO, to just mention some of the most popular plugins, all infringe the same guideline:

“Plugins may not contain functionality that is restricted or locked, only to be made available by payment or upgrade.”

For example, Jetpack locks the feature of adding the tracking id of Google Analytics needed to generate the script inside the website. It’s locked with a green button saying “upgrade”. Although Google Analytics is a service, the feature of adding the tracking id on a text field inside the WP dashboard which automatically generates the script tag on the frontend is code in the Jetpack plugin and it is locked by one upgrade. This is a direct infringement of the guideline 5, copied above.

Yoast has the same kind of infringement with the feature called “Multiple Keyphrases”.

So, unless plugins’ team will start shutting down the entire repository, they are being completely unfair here, and by persisting in this decision while keeping all these cases listed, I can only assume they are acting on bad faith.

Also for discussion, what trialware is?
According to dictionary.com it defines as “computer software that can be used free of charge for a limited evaluation period”. Not the case here.

If the plugins’ review team applies this specific “trialware” rule to all the repo plugins, with the same strictness applied here, I’d guess most of them need to be closed immediately.

Guidelines were made to protect the WP community, they should serve the community, including the plugins’ developers. In this specific case, the HappyFiles plugin, a 5-star plugin, states from day one that it is a 10-folders plugin. If people want more than that, there are other solutions in the market.

Shutting down HappyFiles leaves 3000+ active users without any other solution, without automatic updates, without security patches. In the end, no one wins.

I hope the review team reconsiders.

Thank you!

Hello,

I found out the issue.
The issue is on the The Newsletter Plugin, plugin.php file, method:

/**
     * Returns the Newsletter dedicated page URL or an alternative URL if that page if not
     * configured or not available.
     *
     * @staticvar string $url
     * @return string
     */
    function get_newsletter_page_url($language = '') {

        $page = $this->get_newsletter_page();

        if (!$page || $page->post_status !== 'publish') {
            return $this->build_action_url('m');
        }
        $newsletter_page_url = get_permalink($page->ID);

        if ($language && $newsletter_page_url) {
            if (class_exists('SitePress')) {
                $newsletter_page_url = apply_filters('wpml_permalink', $newsletter_page_url, $language, true);
            }
	        if ( function_exists( 'pll_get_post' ) ) {
                $translated_page = get_permalink( pll_get_post( $page->ID ), $language );
		        if ( $translated_page ) {
			        $newsletter_page_url = $translated_page;
		        }
	        }
        }

        return $newsletter_page_url;
    }

This line (1267)
$translated_page = get_permalink( pll_get_post( $page->ID ), $language );

has the parenthesis on the wrong place. Should be:

$translated_page = get_permalink( pll_get_post( $page->ID, $language ) );

Please fix it!
Btw, thank you for the excellent plugin!

The plugin mentioned was causing a conflict with the jQuery autocomplete library also used by Polylang. If you want to trace the conflict on your website I suggest start deactivating the other plugins you may have installed, one by one, to find out which one is causing the conflict.

update

I found the plugin CMB2 custom field “post_search_ajax” was causing this bad behaviour.

I’m running WP 5.3.2 and Polylang v 2.6.10 and I also noticed the same issue.

When editing a post and trying to add a translated version of the same post using the language metabox (sidebar), I start typing the title of that translated version (e.g. “test” ) and I got a console JS error:

VM1788:1 Uncaught SyntaxError: Unexpected token < in JSON at position 0

This is the request sent to the server:
https://…/wp-admin/post.php?post=3077&action=edit&query=test

Same here:

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; WP_Import has a deprecated constructor in wp-content/plugins/wordpress-importer/wordpress-importer.php on line 38

Thank you!

Thank you for the information. Since the JS script is very simple on the Select All Terms plugin I am wondering if the other plugin is not introducing an error that prevents other scripts to work.

Hi

Thanks for your feedback.
The idea of this plugin is to be simple and ready to use. It alters the way the WP core search works by extending it.

Hi

Sorry for the late answer.
Did you manage to exclude the pages from the search ? Do you still need help ?

Sorry for the late answer..
How is the custom field defined?
Are you using some kind of plugin like ACF to define the custom field ?

I am having the same!

Ok. I could replicate the issue when searching tags. Unfortunately it seems it happens when I enable a specific plugin “The Events Calendar” but it might happen with others. I’ve made a ‘protection’ on geeSearch to avoid this error.

release 1.4.2