• Stay in touch. Sign up for the 9seeds newsletter.
  • Creating a WordPress User when you don’t have an existing admin login to use

    A long time ago we wrote a post on how to insert yourself into WordPress as an admin that has been very popular.

    Just to be clear, this won’t help you hack a WordPress site. You have to have some kind of server level access to make use of any of these, but in our work we often have scenarios where we only have access to a server.

    There are 3 quick ways to create a WordPress user from outside the WordPress dashboard.

    Creating a WordPress user with WP CLI USER CREATE

    My new favorite way is using WP CLI.  These require that WP CLI is installed on the server, but recently WP Engine started rolling out WP-CLI Support to Select Partners for Beta Testing.  It’s not just a WP Engine thing though, a few other hosts provide WP CLI support via shell access and if you’re running on your own server you can install it.  You’re not likely to be able to install this yourself on shared hosting.
    Assuming you got access to WP CLI it’s as easy as SSH’ing into your server, or using the WP Engine portal, and typing

    wp create user name [email protected] --role=administrator

    You can specific a password with –user_pass=”Password!” or let it create a random password for you!



    Create a WordPress user via MySQL

    If you don’t have SSH access and WP CLI already installed the next quickest way is to insert a user via MySQL. Most hosts include PHPMyAdmin so you can just jump into there, select the database you want to insert a user in, paste this code into the SQL page, edit the values and click Go.

    SET @user_login := 'justin_foell';
    SET @user_pass := 'Q9xiHgzZ';
    SET @user_email := '[email protected]';
    INSERT INTO `wp_users` 
    (`user_login`, `user_pass`, `user_email`, `user_registered`) 
    (@user_login, MD5(@user_pass), @user_email, now());
    SELECT @user_id := LAST_INSERT_ID();
    INSERT INTO `wp_usermeta` 
    (`user_id`, `meta_key`, `meta_value`) 
    (@user_id, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}');
    INSERT INTO `wp_usermeta` 
    (`user_id`, `meta_key`, `meta_value`) 
    (@user_id, 'wp_user_level', '10');



    Create a WordPress user via FTP

    This used to be my favorite way because often all I had was FTP access, but these days I use the first two a lot more often.  Still it’s easy, especially if running running MySQL commands scares you.

    Here you simple FTP to root directory of the site you need access to and create a new empty PHP file.  Often I just “duplicate” an existing file and clear it out, that’s fine too.

    Open of the file and insert this code, then change the user/pass/email values and finally visit the file in web browser.  You should delete the file after it runs, or at least give it very unique name.


    Thats it!  3 ways to create a WordPress user when you don’t have dashboard access.

    Extending The Functionality of MemberPress




    There are a number of well established commercial WordPress plugins that provide an almost perfect solution out of the box for our customers. These plugins are big part of what makes WordPress a great and affordable solution for so many websites. Often however, a business needs something “just a little custom”. Where a full custom solution might be tens of thousands of dollars in development, a $100 plugin and a few hours of custom development can deliver a similar highly tailored solution. This recently completed project extending MemberPress is a great example.

    Unique Client Needs

    A client using MemberPress came to us wanting to offer their members the ability to purchase a gift membership for someone else as well as a way to set up and manage a very customized 40 day email drip program.

    Taking Something Good And Making It Better

    We love working with the MemberPress plugin. It’s robust and can meet the needs of many membership sites. However, each business is unique in the services it delivers to it’s customers and sometimes delivering those services requires extending the functionality provided by a plugin.

    Implementing the gift memberships was more challenging than it sounds. The existing coupon functionality in MemberPress assumes that a site administrator would simply create a coupon code for use by many users. We started with this and extended it such that users could purchase a 100% coupon and that coupon could be sent to someone as a gift. The final tweak was to make it so these coupon codes were one-time use only.

    The 40 day drip program took people through a series of daily questions about each day’s lesson. MemberPress tracks progress through the drip program but doesn’t allow users to go back and repeat the program. We created a plugin that allowed users to reset the program to day 1 and wiped out all of their previous answers so they could start the process anew.

    Both add-ons work independently of one another giving the site owner flexibility in which add-on functionality is active at any given time.

    Customized Solutions

    There are countless amazing plugins out there that do a massive range of things for a specific need. When you need something a little different the most affordable solution may be to extend one of those existing plugins to fit your particular need. Contact us. We’ll create the perfect plugin add-on for you!

    Updating WP Chargify: Revisiting a Custom Plugin Built Long Ago


    5 years ago, Jason Glaspey came to us wanting to use Chargify to manage recurring subscriptions for his paid members. At the time there was no plugin available for WordPress to connect with Chargify. Jason hired us to build a custom plugin for his specific needs. He also generously allowed us to make it available for free to all on the WordPress Plugin Directory.

    Over the years Chargify has made lot of changes to their service. While Jason had sponsored the original plugin he moved on and the plugin sat idle for quite a while. Chargify recognized the importance of the plugin being updated and reached out to us to do a complete overhaul.

    We were excited to take on the project. It was great to be given the opportunity to revisit code we wrote so long ago. We were able to update the plugin with all the latest Chargify features as well at the latest best coding practices.

    Chargify was delighted with the results and wrote a nifty post on it where you can read about all the new functionality here.

    Thanks to 9seeds great work on our plugin, using WordPress and Chargify together has never been easier!” ~Britton Gwaltney, Chargify – Director of Sales

    Building custom plugins for hire like this is one our favorite services. If you need a custom plugin developed or just need to streamline a function please contact us! We’ll be happy to help you, too.


    Deploying to SiteGround via git push

    Git push is the best thing for deployments since sliced bread. I don’t know if sliced bread was ever a deployment requirement, but trust me it’s good. I used to work at a company that used a similar stack (svn+rsync) to deploy. I’m glad to see many hosting companies getting on board with git-push. May you never have to use FTP again!

    We have an account at SiteGround, which provides git push, but implemented in a different way than others like WPEngine. If you’re not careful with how you use it, it can lead to some strange results. I’d like to highlight some of the differences, so you don’t get yourself into trouble – especially if you don’t want core WP files to be under version control.

    Navigating SiteGround’s cPanel

    SiteGround uses the classic cPanel interface. To help you navigate, I’ve highlighted the areas of interest:

    cPanel home

    Creating a subdomain

    If you haven’t done so yet, you may want to create a subdomain for your install. We use a single domain at SiteGround and put several WP installs using subdomains for testing purposes. Here’s what the subdomain configuration looks like:

    cPanel subdomain

    If you’re setting up a WP install using your main domain name, you can skip creating a subdomain.

    Creating your WordPress instance at SiteGround

    When you go to add WordPress to your domain through cPanel, you’ll be using a tool called “Softaculous.” Click the big blue Install button to get started:

    cPanel new install

    Select the domain (or subdomain) that you want to turn into a WP install.

    Remember to change:

    • Database name – it will be auto-generated, I tend to choose something that matches the domain or subdomain so it’s easy to remember what it goes with.
    • Table Prefix – I use the normal wp_ – I think changing this has become “security through obscurity” and if you don’t keep your site up to date, this is unlikely to save you from an attack.
    • Admin Username – replace the auto-generated username with something useful, but avoid admin since it is easily targeted by attackers
    • Admin Email – replace the auto-generated one with a real email address for the site administrator.

    When the installation is done, to exit Softaculous and get back to the regular cPanel, just click the My Accounts tab at the top and then click the red Go to cPanel button.

    Creating the git repository at SiteGround

    Click the SG-Git icon on from cPanel. You’ll be brought to a screen where all of your WordPress installations are displayed, and if they don’t have git repositories associated with them, you’ll be given the option to create one. When you click Create Git Repository for your WP install, a dialog will come up with some git information. Record the git clone command, we’ll use it later.

    cPanel git info

    There will also be a SSH key and possibly the passphrase that goes along with it. Rather than using this key and sharing it with all the developers who you want to be able to push to this SiteGround account, I find it easier to add individual keys via cPanel.

    Setting up SSH keys and config

    SiteGround only takes DSA keys for SSH. If you don’t have an id_dsa.pub file in your ~/.ssh directory, you can create one by opening a terminal and running:

    ssh-keygen -t dsa

    Once your DSA key is generated, you can add it to the SiteGround control panel by clicking the SSH/Shell Access icon in cPanel. Copy the contents of your ~/.ssh/id_dsa.pub file and paste it into the text area on SiteGround:

    cPanel ssh key

    Some git clients won’t accept the fact that SiteGround uses a non-standard port for SSH. The way to get around this is to create a ~/.ssh/config file with an entry for SiteGround. If the git clone command SiteGround supplied looks like:

    git clone ssh://[email protected]:18765/home/sguser/public_html/git

    Then your ~/.ssh/config file should contain:

    Host mXX.siteground.biz
            HostName mXX.siteground.biz
            Port 18765
            User sguser

    Replace the Host, HostName, and User values with those from your account. I’ve changed them in this example for security purposes. To test you should be able to:

    ssh mXX.siteground.biz

    Notice you shouldn’t have to supply the username or the port, my ~/.ssh/config takes care of that. If you didn’t add a passphrase to your DSA key, you should be logged into SiteGround without having to supply a passphrase. Press Control-D to log out.

    Now your git endpoint can be simplified for your git client (username and port are removed):


    But don’t clone it just yet!

    How not to push, and what will happen

    The normal Git push workflow (for me) would be to init a git repository on my local system, add an origin of bitbucket.org or github.com and push it there, then add remotes (such as WPEngine production and staging) and proceed to push to those remotes. Instead I added SiteGround as a remote named sg-remote.

    Origin vs. Endpoint

    They key difference between SiteGround and WPEngine is that SiteGround treats their git repository as an origin (where you can pull and push), where WPEngine is a --bare endpoint that you can only push to.

    Since SiteGround is set up as an origin, if you just try to push there (without pulling or cloning from SiteGround first), you’ll likely get a warning like:

    Updates were rejected because the remote contains work that you do not have locally.

    Per git’s recommendation, you might then try to pull:

    git pull sg-staging master

    If your git repository was set up to not track WP core files, you’ll get a warning that:

    error: The following untracked working tree files would be overwritten by merge:

    This is because the core WP files have been added to the SG-git repo, but not your local one. So then if your next move is:

    git push sg-staging master --force

    Several important files will be removed on your WP install at SiteGround: all of wp-admin, wp-config.php, and all other PHP files in the webroot folder. Needless to say, your WordPress instance will no longer function without some serious repair.

    Git push to SiteGround (modified functional workflow)

    Since SiteGround sets up the git repository as an origin, it is better to start your WP project with a git clone from SiteGround, but before doing that, I wanted to clean things up…

    If you don’t want core WP files under version control, the easiest solution is to remove them from version control directly at SiteGround before cloning the repo.

    Since we’ve already got SSH working, from your terminal you can:

    ssh mXX.siteground.biz
    cd /home/sguser/public_html/git
    git rm --cached -r wp-admin/ wp-includes/ *.php *.txt *.html
    git commit -a -m "Removed WP-Core files"

    Again, replace the host (ssh line) and path (cd line) with the values from your git clone command supplied by SiteGround. The ones used here are examples. The git rm --cached command removes the core WP files from revision control, but leaves them on the filesystem, so your installation doesn’t go into a state of disrepair (like above).

    Once that is done, you can clone!

    git clone ssh://mXX.siteground.biz/home/sguser/public_html/git

    SiteGround will be the origin, so let’s edit that (usually bitbucket.org or github.com is the true origin). This will rename it to sg-remote:

    git remote rename origin sg-remote

    Now when you want to push to SiteGround, just do:

    git push sg-remote master

    If you try to push a different branch to SiteGround, the branch will be transferred, but the code won’t be switched to that branch. To get around this you can overwrite SiteGround master by doing:

    git push sg-remote my-branch:master

    Hopefully this gives you some insight into how the SiteGround git deployments work, so you can use them effectively.

    If you’re interesting in learning more about git deployments or how to set up your own git-push-to-deploy, I recommend starting with this article to familiarize yourself with a basic setup:


    Import/Export issues between MySQL 5.1 and 5.5+

    There have been many advances in recent history that make a WordPress developer’s life easier. WordPress itself is already pretty easy as it’s very tolerant of a myriad of hosting environments. To make things easier for local setup, there’s a fantastic product called DesktopServer by ServerPress which will quickly and easily set up a multitude of local WordPress sandboxes to hack on. DesktopServer currently ships with MySQL 5.1 which is A-OK because WordPress requires version 5.0 or greater.

    When setting up a new development environment, we typically use WP Migrate DB Pro (HIGHLY RECOMMENDED!) to download the latest database data from staging or production into our local sandboxes. Other ways work just as well, like exporting from phpMyAdmin (or native mysqldump) and then using interconnect/it Search and Replace. WP Migrate DB Pro is just so easy because it does everything in one step.

    However, a problem reared its head recently while exporting from WPEngine (which currently uses MySQL 5.6) to DesktopServer. [Read more…]