Tag: Development

  • How to Upload a Plugin to WP.org Plugin Repository using SVN?

    How to Upload a Plugin to WP.org Plugin Repository using SVN?

    You should submit the plugin zip file on the https://wordpress.org/plugins/developers/add/ to get approval from the WordPress.org Plugin team. You should be logged in to WordPress.org when submitting to the WordPress.org Plugin repository. When developing a WordPress Plugin, You should follow all best practices mentioned in WordPress Plugin Development HandBook.

    The Plugin Review Team may contact you on your email. The Plugin Review Team would come with either rejection or approval. If the Plugin Review Team comes to your email with approval, They will give you SVN checkout URL in the reply email address.

    Would you please follow the below steps to upload the plugin in WordPress.org Plugin Repository?

    Add changes to trunk

    • Make a folder (directory) plugin-slug in your Local computer.
    • Open a terminal in the plugin-slug folder and run the command: svn co https://plugins.svn.wordpress.org/plugin-slug
    • Then, You should copy paste your all plugin files and folders in the plugin-slug/trunk folder.
    • After putting all plugin files and folders in the plugin-slug/trunk folder, You must tell the SVN that I want to add these files and folders in repository changes. It is equivalent to staging in git. We should run the command in the terminal: svn add --force trunk/* --auto-props --parents --depth infinity -q or svn add . –force
    • For svn deleting removed files, Please run the command svn status | grep '^!' | awk '{print $2}' | xargs svn delete from command line.
    • After you add all changed files and folders in staging, We should run the command: svn ci -m 'trunked 5.2.4 version: Introduced settings' It is need to add commit message. Here, The senetence “trunked 5.2.4 version: Introduced settings” is commit message.
    • Run command `svn up` to make changed in WP.org Plugin Repository.

    Tagging New Version:

    • To tag your version, You should copy all files and folder of trunk. For it, We should run the command in the terminal: svn cp trunk tags/5.2.4
    • Then run the command in the terminal to stage tags/5.2.4/* changes: svn add --force tags/5.2.4/* --auto-props --parents --depth infinity -q
    • Run the command to commit tagged version: svn ci -m "tagging version 5.2.4"
    • Run command svn up to make changed in WP.org Plugin Repository.

    More information is on https://thewpx.com/wordpress-svn-repository/.

  • get_home_path() vs ABSPATH and get_home_url() vs get_site_url() in WordPress

    Many WordPress developers are often confusing between get_home_path() and ABSPATH. Same way, They are confused between get_home_url() and get_site_url(). Both codes give the same result in normal WordPress installation. But both codes give different results in a special WordPress installation site where WordPress core files located at a different place than web site’s root folder.

    Here, I am going to explain what is difference between get_home_path() and ABSPATH by taking an example. To understand it I have made a demo WordPress site in which I have made a different WordPress code sub-directory in subfolder /wordpress. To understand how to move WordPress code into a different sub-directory you should follow the steps described in https://wordpress.org/support/article/giving-wordpress-its-own-directory/#method-ii-with-url-change. I have given a different WordPress sub-directory to my WordPress site. I have used Method 2 described in the given link.

    I have added below code in the wp-content/mu-plugins/test.php file:

    <?php
    add_action( 'admin_init', function() {
    
        echo 'Home Path: '.get_home_path();
        echo '<br>';
        echo 'ABSPATH: '.ABSPATH;
    
        echo '<br><br>';
    
        echo 'Home URL: '.get_home_url();
        echo '<br>';
        echo 'Site URL: '.get_site_url();
        
    
        die;
    } );

    The output of the script is as below:

    Home Path: //Users/prashant/Local Sites/wpsepdir/app/public/
    ABSPATH: /Users/prashant/Local Sites/wpsepdir/app/public/wordpress/
    
    
    Home URL: http://wpsepdir.local
    Site URL: http://wpsepdir.local/wordpress

    The get_home_path() gives root path of WordPress site. The `ABSPATH` gives the path of subdirectory where WordPress codes reside.

    The get_home_path() gives the URL where the user can visit the site. The get_site_url() gives URL where the WordPress codes reside.

    Here, Home word refers to site’s home. The Home is root folder of the site. Whereas site and ABSPATH refers to WordPress subdirectory where WordPress core code exists.

  • WordPress Code Debugging – Part 1

    Being a developer, We are spending a lot of time in debugging besides writing code. If we can debug with speed, We can be more productive in our development. In this article, I would like to show you debugging tips and tricks.

    Error-free code

    We are generally debugging when we produce erroneous code. First, we should take care that we should not produce any buggy code. If we write an error-free code, We will not face a question of debugging.

    There are three ways to prevent bugs:

    1. Follows coding standards
    2. Use simple expressive variable/function names
    3. Write single-purpose short functions

    To write the error-free code, I personally insist to follow any coding standard. I personally prefer WordPress code standards. To check whether we are following code standard perfectly, We should use code standard checking tools. I personally use PHP Code Sniffer with WordPress Coding standard. The coding standard generates the consistent formation of the code.

    Try to use simple and fully qualified function names. Instead of naming $p, We should make the function name $post. The $post name suggests that it holds the post object.

    Break/Divide a code into more functions instead of writing all code in a single function. A Function should be written single purpose, and It should be as short as possible. An error can’t be hidden in a short function. An error can be hidden in a lengthy function code.

    Code Linting

    Break/Divide a code into more functions instead of writing all code in a single function. A Function should be written single purpose, and It should be as short as possible. An error can’t be hidden in a short function. An error can be hidden in a lengthy function code.

    Advanced debugging with breakpoint

    Do advanced debugging by using the breakpoint with the XDebug and Integrated Development Environment IDE Editor like VSCode. A Breakpoint pauses the execution and allows to inspect the code. For how to use XDdebug with the VSCode, Please visit the https://github.com/felixfbecker/vscode-php-debug

    VSCode with Xdebug breakpoint

    When control comes to the breakpoint, the execution pauses and allows us to inspect the code. We can do advanced debugging with breakpoint using the chrome dev tool. For how to use breakpoint with the chrome dev tool, Please visit the https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints

    WP-Config constants

    When you are developing in WordPress, Please make sure that below the constant value set in the root/wp-config.php file.

    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', __DIR__ . '/wp-content/prashant-11072021-FDFDFRGFDDFD.log' );
    define( 'WP_DEBUG_DISPLAY', true );

    If the above-mentioned constants are not set and you write any buggy code, You can not see any error.

    WordPress plugin for debugging

    1. Query Monitor: Monitor SQL Queries, Query load time and AJAX request
    2. Debug Bar: Adds a debug menu to the admin bar that shows query, cache, and other helpful debugging information.
    3. Log Deprecated Notices: Logs the usage of deprecated files, functions, and function arguments
    4. User Switching: allows you to quickly swap between user accounts in WordPress at the click of a button