List All Plugins Installed on Front End of WordPress Site

Small script for listing out plugins on a WordPress site.

For my website, I wanted to list of the plugins I used.

I use them because they’re good, I like them, and having them on the share page gives them some exposure:

This doesn’t factor in active/inactive, but really for security, you shouldn’t have inactive plugins on your installation.

(Long live shortcodes!)

Troubleshooting xdebug setup on VVV with VS Code

Some tips for troubleshooting setting up xdebug on VVV while using VSCode and Felix Becker’s PHP Debug extension and BrianGilbert_‘s Xdebug Helper for Firefox add-on.

Ensure xdebug is turned on within vvv

You may check xdebug status by taking a peak at your servers http://vvv.test/phpinfo/ page. If not on, via https://github.com/Varying-Vagrant-Vagrants/VVV/wiki/Code-Debugging we can toggle it on by accessing the virtual machine via ssh, then running a command that will turn xdebug on and restart PHP:

$ cd ~/your/location/for/vvv/
$ vagrant ssh
$ /vagrant/config/homebin/xdebug_on

The xdebug_on command is supposed to work without the full path, but I haven’t much luck with that. As a second saver, I store this full path in my text expanded since every time the machine is restarted xdebug being on does not persist and it will need to be manually turned on. A bash_alias entry could be made as well.

Ensure the browser extension is turned on

Yes, simple, but often forgotten.

Ensure you’ve started debugging in VS Code

Again, yes, simple, but often forgotten.

Ensure VVV is up to date

Older versions of vvv have compatibility issues with xdebug and php. Ensure you’re running the latest version of vvv, that vagrant itself is up to date, and that you’re using the latest version of php.

Turn off “Everything” breaks

Sometimes xdebug works while setting it up, VSCode pops up, but it stops on a breakpoint that isn’t the one you specified, it’s a random file from your app. This is an error that was picked up and xdebug stoped on because the default VSCode extension has it specified to break on “everything”. Unselect this in the Debug sidebar:

Check the xdebug profile is correct

Via the debug sidebar (shift+cmd+d), we’ll view our xdebug configuration file. Here’s an example of a WordPress plugin delete-thumbnails and the path I used

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "pathMappings": {
                "/srv/www/vvv-vip/public_html/wp-content/plugins/delete-thumbnails": "${workspaceFolder}"
            },
        }
    ]
}

Two important notes:

  • VVV has two initial paths to get to your sites, /srv/and /vagrant/, the latter is a symbolic link which xdebug does not understand, you must use /srv/
  • Other tutorials may say to use ${workspaceRoot}, this variable is deprecated in favor of ${workspaceFolder}

Try a breakpoint outside of your current script

We usually want our breakpoints on what we’re working on, and we’re frustrated when xdebug doesn’t pick up on the breakpoint, so we dig around our config to check what’s wrong. Let’s first make sure that our desired code is actually running and capable of breakpointing, after all, the code not running might be why we’re firing up xdebug!

Add a breakpoint at the root of your application, somewhere you know runs 100% for sure. In WordPress, this will often be in either WordPress’ /index.php file, or the primary file in your current theme or plugin. For this plugin I’m working on, I checked that the plugin is activated, and I’ve placed a breakpoints on a fake var on the main fire which I know for sure loads:

Is your VSCode the nightly build?

I’ve heard of users being unable to run xdebug while using their beta releases. Best to always use the stable releases.

WordPress Pass PHP Variable and Values to JS Theme or Plugin

The beautiful function wp_localize_script() was built for l11n, however its found as a method for carrying over server-side values into client-side JS.

Your values are now available in your .js file:

console.dir(my_theme_data);

Currently using this in a React theme I’m building for WordPress.

This can also be done with something like:

Every Image URL Filter For WordPress, Front & Back End

I had a project where every single media library image URL needed to be filtered, backend and front end. As far as I’ve found these were the filters for every area:

The myplugin_filter_html_image_urls() function peals out images with regex from areas where it’s not just the URL being sent. This function may require verification of the current domain incase bad practices of using external images is being done.

WordPress Pass Variable Into wp_footer, wp_head, & all Other Actions/ Hooks/Filters

Passing variables into WordPress hooks using an anonymous function I thought was impossible. I always worked around this and rewrote the logic. Today I found out anonymous functions support a use keyword, allowing passing:

So simple and easy. Shaves hours of troubleshooting.

Easiest way to Backup WordPress to S3

I explored and tested a bunch of WordPress plugins for S3 – they’re excellent in their own right, but I was bothered by the bloat & weight on PHP for the backup. Don’t get me wrong, I understand it’s a complex undertaking when you’re creating a backup/restore UI, working off wp-cron, creating many features that benefit lots of people, etc. But I didn’t need any of that – I just need my server backed up without dealing with anything.

Quick search of  Github lead me to a beautiful shell script that uses wp-cli and awscli to preform the backups. Here’s the kicker: it takes less than 40 lines of code. I modified it a bit for my needs and it works better than I thought possible:

Amazing. Runs with sh backup.sh thrown into crontab. Amazing.