Category Archives: WordPress

Using DevKinsta with Git

Over the years I’ve used a lot of different tools for local development. Like many other developers, I’m often looking for a better option. I finally found that with DevKinsta.

For Laravel development, I mostly use Valet, but for WordPress development I lean towards using more robust tools such as Local. The benefit is they have a lot of built-in tools (e.g. Mailhog and Adminer) and they make it easy to sync the production database and media files to your local machine (side note: syncing production database isn’t a good idea if your database is large or you have sensitive customer data in it).

I used Local for the last couple years. I was happy with it, but my main site is hosted on Kinsta, so I wasn’t able to take full advantage of its features. Fortunately, Kinsta recently released their own local development tool, DevKinsta.

After an initial test run, DevKinsta looked promising, but there was one catch—I needed to make sure I could use version control (Github in my case) with it. DevKinsta allows you to push changes to your Kinsta Staging environment, but there isn’t any sort of built-in way to handle version control.

Below are the steps I took to add git to my DevKinsta setup. These steps assume that you are using a Mac and keep the entire WordPress install under version control.

  1. Install DevKinsta. If it’s not already installed, you’ll also need to install Docker.
  2. If your site is hosted with Kinsta, open DevKinsta and select “Import from Kinsta.” Depending on the size of your database and media library, this process might take a while.
  3. Once the local site is up and running, you can find the site’s WordPress files in: /Users/USERNAME/DevKinsta/public/SITE
  4. The next step is to clone your WordPress repository from GitHub. Select the DevKinsta/public/ folder as the destination. You’ll now have two sites in the public folder.
  5. Within the ../DevKinsta/public folder, rename the original folder to something like SITE-old
  6. Rename the git folder to the original folder’s name: SITE
  7. Copy the wp-config.php file from SITE-old and paste it into SITE
  8. Copy the wp-content/uploads folder from SITE-old and paste it into the property folder in SITE
  9. Since you changed the path of the local git repo, make sure git can locate it (this is easy with Github Desktop)

That’s it! From there you can follow your normal local development and deployment process.

If you only have version control setup for a specific plugin or theme, you can follow the steps above, but instead of renaming the entire site, navigate to ../DevKinsta/public/wp-content/ and delete or rename the specific plugin/theme you’re working on. There’s also the option of symlinking the plugin/theme if you want to store them elsewhere.

Overall, I’m happy with DevKinsta. I usually avoid Docker based solutions, but I’m glad I gave DevKinsta a try.

If you’re interested to learn more about Kinsta, my full review is here.

DevKinsta: Your Local WordPress Development Suite

This post contains affiliate links, but as a regular web developer, it is my honest review of Kinsta and DevKinsta.

Shared Hosting + WordPress Notifications + Google Apps

I help a family member run a website for a small business and we recently discovered that the contact form notification emails were not being delivered. The contact submissions were in the Feedback section of the dashboard, but the notification emails were not being delivered to the email address on the form.

Background Information

Domain Registrar: Namecheap
Web host: Namecheap
cPanel Version: 11.40.1 (build 13)
DNS: Namecheap hosting servers
Email: Google Apps
Contact Form: Jetpack
Contact email: Generic Gmail account

Initial Findings

  • If I changed the contact email address to one of the domain’s existing Google App email addresses, the contact form notifications were delivered
  • If I added a new 0 priority MX record of mail.domain.com, the notifications were delivered to any email address (but this breaks the Google Apps email)
  • I looked in the webmail account for the the standard WordPress notification email address (wordpress@domain.com) and found 60+ emails with the this subject:

    Mail failure – rejected by local scanning code

    The body of the emails contained the following:

    A message that you sent was rejected by the local scanning code that
    checks incoming messages on this system. The following error was given:
    “Relaying not permitted”

I spent a couple hours playing around with the WP-Mail-SMTP plugin, Google App settings, cPanel settings and nothing was helping.

My initial thought was that the MX record shouldn’t affect outgoing email, but I was wrong. Finally, I found a Namecheap support page which explained the problem:

..to send emails from our server, domain should be added to it and have MX records pointed to the server where this domain is hosted.

To summarize: Email generated by the server will not be sent unless the domain is added to the hosting account AND the MX records point to the same location.

The fix:

  • Create a subdomain (because the subdomain isn’t setup with Google Apps)
  • Install the WP-Mail-SMTP plugin
  • In order to force outgoing emails to use the subdomain, configure the plugin as is explained on the Namecheap support page

Once I completed the setup, the email notifications were fixed. I had a hosting account on Bluehost for years and I never ran into this issue, so I’m assuming that they don’t have the same limitation on emails. Has anyone else run into this issue with other shared hosts?

WordPress 3.9

I’m really excited about WordPress 3.9, which was released today.

There are so many great additions, especially to the post editor.

This video is shown on the update page and has a great overview of all the changes:

Both Post Status and WP Tavern have great recaps.

Check it out!

WordPress 3.8 Beta 1

WordPress 3.8 Beta 1 dropped today. It looks great. I really love the new Admin Color Schemes options. In order to charge your color scheme, go to Users → Your Profile and select one of the four options.

WordPress 3.8 Midnight Theme

I’m really digging the Midnight scheme.

See the full announcement here.

The final release date is December 12th, so start testing!

WordPress 3.6 – Native Support for Audio

While I was messing around with WordPress 3.6 and audio capabilities, I decided to the test the native support for audio.

Here are a couple things to watch out for:

1. Your host or settings may limit the size of on file uploads. To get around that limitation you can upload the file via FTP. But if you do that the file won’t show up in your Media Library. If this is the case, download the Add From Server plugin. This plugin adds a link in the Media Library which allows you to add file from your server to the Media Library. From there, it’s easy to embed in your post.

An alternative is to use FTP and then wrap the link to the file in audio shortcode. Here’s an example:

[audio mp3="https://www.kmarsden.com/wp-content/uploads/2013/08/Trojans.mp3"]

2. Get rid of the spaces in your file names. The media player won’t work if the song/video has spaces in the name.

3. Not all browsers will support the mp3 embed. See the Codex for fallback methods.

4. The width of the audio player is set to 100%. You can change this by setting a smaller width in your child theme’s style.css. This is what I did:

.mejs-container {
max-width: 400px;
}

Just don’t go much lower than 200px;