Divi Post Settings Plugin IV – Testing and Fixing bugs (working with Ajax), Finishing and Commenting

Hi everyone, today we are online with our fourth post of Divi Post Settings Plugin series. This post should be, according to our original project, the last one, giving the Perfect step (did you remember the four P’s we have followed from start to now?).

However – that’s the beauty of being live – our project will have other three extra posts, but about what they will concern we will see more at the end of this one.

Now, let’s get started with our Testing, Finishing and Commenting steps together with fixing one bug we have found.

TESTING

So we finished our plugin, it seems to work properly in its essential functions and we are the happiest in the world. But, wait. We have to test it as best we can before to launch it on the market or on the WordPress repository itself and by testing almost always unfortunately we will find something going wrong.

So we have to test (the word itself says) every possible function, feature and option we have created and in our case we will see immediately there’s a little bug just after we activate our plugin.

Our info notice, indeed, appears properly informing the user he have to go to the Theme Customizer in order to set his preferences; however, if we leave the page or reload it and also if we click on dimiss button, we still continue seeing the notice, pretty annoying!

FIXING OUR BUG

Ok. What we want to get is the notice appears just after activation but we don’t want it shows again after leaving the page or reloaded it or even better after we click on dismiss button. We can achieve this result in many ways but we propose here only two methods, the first one really easy and the second one more complex but also more efficient.

Method 1 (with Options)

For fixing the issue with this method we will simply add an option row in the database right before the notice showing and then just after it we change our option value; then we will show the notice only if the option value is the first we add, otherwise no notice will be shown, either if the user reload the page or leave it or click on dismiss button.

Method 2 (with Ajax)

Method 1 works properly and has the great advantage of requiring just a couple of code lines within an existing function (that one that shows the notice when the plugin is activated!); however, what if we want the notice doesn’t disappear on refreshing/leaving the page but only if the user clicks on dismiss? In this case we need a more robust solution.

We will use Ajax to do it, so before we go ahead let’s give a quick look at what Ajax is:

AJAX stands for Asyinchronous Javascript And Xml and consists essentially of three steps:

1) a request is created with Javascript when an event occurs;
2) the request is sent to the server that process it and sends back the response
3) the response is read by Javascript again and the action is performed

It can sound a bit complicated and in a way it is but for what concerns us we just have to understand that thanks to Ajax we can link an event like the click on dismiss button to a server side action like the creation of a database user option.

Then we just have to check if the user option has a certain value to check if the dismiss button was clicked or not, and if it was simply don’t show more the notice itself.

This is the idea that lay behind, but let’s give a look at real code we have to add. So first of all we have to create our js file in which we’ll write the javascript code(in our case we have created a ‘js’ folder and inside it we add a ‘idivi-ajax.js’ file); then we add a function in our main plugin file in order to enqueue the ajax script:

After that we have to edit a little our ‘idivi_user_info’ function adding the $user_id variable in order to get the current user id and another variable ($idivi_dismiss) that retrieves the user option “idivi-dismiss”; then we wrap our notice code in an ‘if’ statement that checks if the value of $idivi_dismiss is not equal to ‘dismissed’.

We pass then to the creation of another function in our main plugin file, the ajax function. Here we verify that is set a nonce; if it isn’t simply die, otherwise the code runs, we retrieve the current user id and then simply update the user option we have created before assigning the ‘dismissed’ value to the option.

Finally we hook the function with add_action in a particular hook that always have to start with ‘wp_ajax_’ followed by the action name, in our case ‘idivi_dismiss’. So when an Ajax request is sent and the action name of the request is ‘idivi_dismiss’ this function will be executed.

We talked about the Ajax file, so the last thing we have to do is set properly this file with the Ajax code itself. In short what we are doing here is set the event ( the click on dismiss button in our case ) that will trigger our function ( note the ‘action’ name that is identical to our second part of the ‘wp_ajax_’ hook in the php function ).

All done. We can now go to testing again our plugin. We will activate it and the notice will be properly shown, reloading or leaving the page the notice is still present at the top of the page but if we click on dismiss button it desappears and it doesn’t show anymore even if we reload or change page.

That’s fine, but… wait. If we deactivate our plugin now and re-activate it our notice doesn’t show at all. So we have to fix this little issue also. We simply add a function that triggers when the plugin is deactivated thanks to the ‘register_deactivation_hook’; this function will update the user option to ‘ ‘ (empty). Re-testing for the last time and now all should work properly. Done!

FINISHING AND COMMENTING

The plugin is really at good point. However, we want to be just more orderly, we search in the code for finish it, save spaces, align braces and so on.

And finally we will comment every function we added so that if another developer or yourself will make some changes to the code in the future will be really easier to do it.

LET’S CONTINUE…

Ok, our plugin is really live and completed. However, we will write other three posts on it; in the next one we will reorganize all our code in a OOP approach using php Classes, then we will add an extra feature to our plugin and in the last post of this series we will see how to submit our plugin to the WordPress repository.

Stay Tuned!