caraffande

@pranayachaudhary

we do show clearly in the plugin description that an OptinMonster account is required to use the plugin

Sorry, but you (your firm, your boss, or whomever) can’t get away so easily!
You say only that an account is required! NOT that IT IS A PAID ACCOUNT!
Sorry but it’s clearly dishonest!
Furthermore, WordPress official plugin repository policy states VERY CLEARLY that you CANNOT SELL your product thru it!
If you plan to sell ANY PRO OR OTHERWISE paid version you must do it on your site!
You cannot deceipt people into believing that, since your plugin is in the OFFICIAL WP PLUGIN REPO, then it is (at least partially) free!!!
It’s only foul trick to funnel people to your website!

Well,
I need to set up an LMS in italian, therefore I have two options right now:
1) Search for another LMS plugin/theme which is already translated
2) Translate Learnpress in italian.
What do you think about the second option? I could help with the translation: I’m italian mother tongue. What’s your opinion about that?

@mnohtm
Hi, Mnohtm. I can answer, even if I’m not the author of the plugin. The plugin works quit well. If you have ffmpeg installed and available for general use in your server, then you’re ok. You don’t have to do any further step. With ffmpeg available, the configuration page of the plugin will show-up with an additional tab, exactly the “FFMPEG” tab. There you have plenty of options for generating thumbs.
If you don’t see that Tab, then may be the ffmpeg libraries are not accessible from the web server env path.

That’s ok.
I’ll manage to do that by myself.
Thanks for all your work, Kyle

It works, thanks, but what about adding an overlay image in the thumb only? Is it possible?

Thanks, I’ll give it a try

P.S.: I’ve also added this in the constructor

        add_action( 'rest_api_init', function () {
            register_rest_route( 'dornaweb/v1', '/email-verify/link/send', array(
                   'methods' => 'POST',
                   'callback' => function ($request) {
                       $user_login = sanitize_text_field($request->get_param('email'));

                       if ( empty( $user_login) )
                       {
                           return ['ok' => false];
                       }

                       $user = get_user_by( 'email', trim( $user_login ) );
                       if ( empty( $user ) )
                       {
                           return ['ok' => false];
                       }

                       $this->send_verification_link( $user->ID );

                       // Success
                       return ['ok' => true];
                   }
                )
            );
        });

Yes, Amin, could be. The trick of the low priority could be another way to achieve the same result as my commenting out the exit(); line.
In my case, however, I need a little more. I’d need a way to disable redirects completely.
Actually I’m registering new users ONLY via AJAX (and REST-API). Any redirect (if any at all) must be handled client-side. The PHP script must NOT send any other header (such as ‘redirect’) since the response to the AJAX call, with all the relevant headers, needs to be constructed within the end-point’s callback.
Any (potentially) redirecting header (like 30X) is very likely to trigger an error in the client, at least in Angular implementation.
A quick but clean fix would be, for instance, that no redirect is actually performed (no ‘redirect’ header is sent) if the “Redirect” field in the plugin’s settings is left empty. Or, maybe, redirect if and only if we’re not DOING_AJAX or DOING_REST_API.
In any case, thanks again for your job!

Thank you very much for your detailed answer.
I’ve followed your hint. I’ve error_log’d the $_POST superglobal. You’re right. It’s empty.
In any case thank you for your effort. At the moment, I’ll go the “main’s plugin file” way, hoping to have some other hint from you and/or the community in the future.

This is the fix

class ujic_Widget extends WP_Widget {

   protected $plugin_slug = 'uji-countdown';

   /**
     * Uji Countdown Init
     *
     * @since   2.0
     *
     * @var     string
     */
//   public function ujic_Widget() {  // <--- Replace this...
   public function __construct() { // <--- with this, and...
      $widget_ops = array(
          'classname' => 'uji_Widget',
          'description' => 'Uji Countdown widget.'
      );
//      $this->WP_Widget( 'uji_Widget', 'Uji Countdown', $widget_ops ); // <--- this...
      parent::__construct( 'uji_Widget', 'Uji Countdown', $widget_ops ); // <--- with this.

      //actions
      add_action( 'plugins_loaded', array( &$this, 'load_textdomain' ) );
      add_action( 'admin_enqueue_scripts', array( &$this, 'admin_widgets_scripts_styles' ) );
   }

Same problem for me, with the added burden that this deprecation warning is breaking the AJAX functionality of my plugin if WP_DEBUG is set to TRUE

I’ve tested further. The problem seems to be an admin-ajax time-out related problem.
I’ve disabled the ‘heartbeat’ script using this

public function on_init() {
		wp_deregister_script('heartbeat');
	}

	public function __construct()
	{
		add_action('init', array( $this, 'on_init'));

and now my ajax script awaits longer. But the problem now is the autosave.
When the autosave event is fired, the connection timeouts and my script is gone once again.
Apparently, each admin-ajax call made (by WP) while my script is running, breaks my script. How can I keep the two “worlds”, WP ajax calls and my plugin’s ones, separated?