Tag Archives: WordPress

HeidiSQL+pLink+putty=Joy

Logo for HeidiSQL, a slick GUI front-end for mySQL

After manually changing a hundred blog posts imported with another theme from “published” to “draft”, I figured it was time to actually look at my WordPress database, since we may wish to do some global link updates,  once we get all of the media imported from another blog.  One of the best tools for this on Windows is the wonderful HeidiSQL program.

My Ubuntu server which hosts mySQL wants an SSL connection to accomplish this, so SSL must be used with HeidiSQL. This is done by using a intermediate program called plink which sits between HeidiSQL and Putty (the terminal program for accessing the Linux command line).

I found an explanation of how to use pLink with HeidiSQL.  However, if you can reach the command line using Putty and an SSL connection on port 22,  then you don’t have to do the first part of the instructions, because you already have the server’s certificate installed on your machine. It was cool to be able to verify this in the Windows registry by looking at the registry key.  And then, I was in.

heidisqlscreen

 

 

Advertisements

Install Ubuntu 16.04 on VirtualBox

The following is a step-by-step run through for installing Ubuntu 16.04 server as a virtual machine running under a Windows 10 host.  Two prerequisites:

Prepare the VirtualBox VM:

Click on “New” to create a new virtual machine: You’ll get this initial screen to choose the operating system you wish to install and choose a name for the your VM.

Ubuntu Install1.jpg

The next screen asks what you want to RAM memory. The recommended memory size is 768MB,  but I’ve had decent luck by boosting this to 4 gigs, (on my 8 gig Windows 10 workstation.).

UbuntuInstallMemory.jpg

Accept the next suggestion to create a virtual hard disk. The default 8GB is fine, because VirtualBox will expand this if necessary.

UbuntuHD.jpg

Accept the default next screen, to choose the file type.

VirtualHardDisk.jpg

… and accept the default “dynamically allocated”

DiskFixedSize.jpg

 

Finally you can choose the file size:

FileSize.jpg

In this case,  I chose 16 gigabytes.

Once you have completed the screens above, you need to change two other parameters before starting the actual installation:

Under Settings,  change the networking connection to “bridged adapter”

NetworkSettings.jpg

Under storage, point the little CD image to your .iso file.

StorageSettins.jpg

 

Install Ubuntu 16.04

At this point you are ready to start the VM, and go through installing Ubuntu from the .iso file.  This is the standard Ubuntu installation from here on out… run from a  console command line interface. Terminal.jpg

After making your keyboard and language selections, there are several prompts for additional information:

Choose a HostName: UBSandbox

Choose an initial account: larryk

Choose a login name for this account: larryk

Choose a password: mypassword

Encrypt your  home directory?  No

Set your time zone. Setup will suggest your local timezone and then ask
Is this time zone correct?   Yes

Partitioning Method:  Choose “Use Entire Disk”,  don’t worry about LVN

Select Disk to partition…. choose the defaults.

Write changes to disk? Yes

At this point the files are copied to the disk, and the installation continues ore or less on its own for five minutes or so,  then you’ll see a question about the use of an http proxy. This relates to the configuration for the package manager which is used to update the operating system. You can probably ignore this unless you know you are in a corporate environment that uses an http proxy server.

Proxy.jpg

The next screen asks you about updating. I would answer this with the default “no automatic updates”. .

Updates.jpg

Finally there is a screen that allows you to select additional software packages to be installed. I would include the LAMP server, and the OpenSSH server.  LAMP will be the usual Linux+Apache web server + PHP + mySQL

install.jpg

But wait! There’s more!   You will be asked for a password for the  mySQL database. Ignore this at your peril…and choose the same password as you used for your user account at the beginning of your installation.

mysqlpassword.jpg

At this point the installation will run for a few minutes and then …

Will this ever end?   Accept the default ‘Yes” to install the GRUB boot loader.

grubboot.jpg

And then….  we’re done.

alldone.jpg

At this point, you should have a working web server that is running an IP address on your network.  To figure out that address. run ifconfig from the VM console.  In our case we’re at 192.168.219.213

ifconfig.jpg

Looks promising.  Now,  we can open a web browser from our Windows workstation (or any other machine on the network, and we should see the Apache web server home screen.

Screenshot_111816_125839_PM.jpg

We’re ready install WordPress.  Before doing that however, you might create a snapshot* of the current state of the VM.  This means we will always have a backup of the current machine that we can fall back to as we’re experimenting with installing things. If you haven’t already installed Ubuntu three or four times, you can always delete the whole VM and reinstall if you want to start from square 1.

 

*I know….this is for a future blog post.

Install WordPress Using VirtualBox Part 2

Because WordPress is such a popular program, there are tons of resources available. After searching for installing WordPress on Ubuntu Server … I found this page.  I followed all of the instructions, with the two exceptions:

  • I did not configure a static IP address for the sandbox server.
  • I prefaced all commands with sudo.

 Once this was accomplished,  I ended up with the default installation page at:

192.168.219.212/wordpress/

wordpress_install

The first page that comes up is a page which asks for information which will will be written to the wp-config file.   Note that all of the parameters are identical to the ones that were used when setting up the mySQL database in the initial step.

wpsetup

The next page asks for the WordPress site name, and a login password.

wpinstall2

About 30 seconds later, you should see a message that WordPress was installed, and that you can now log in with the name and password that you just created in the last screen.  Do that and the familiar WordPress dashboard will come up.  Hooray!

wpdashboard

Install WordPress Using VirtualBox Part 1

Now that we’re WordPress experts,  I’m looking to get an instance of WordPress up and running to be able to experiment.  I’ve been trying this using VirtualBox on Windows 10.  I wanted to create a virtual web server using the latest Ubuntu server 16.04.

  1. Download the .iso file from Ubuntu
  2. Create a new virtual machine, “Ubuntu Server 16.04” within VirtuaBox. I gave it 4 gigs of RAM (half of the physical RAM in my workstation), and excepted all defaults for disk size, etc. The only difference afterwards is to change the Network Adapter from NAT to Bridged.virtualbox1

    3. Install Ubuntu. 
    During the Ubuntu installation, choose the option to install a LAMP server. This includes mySQL, the Apache web server, and the PHP language.

linux_install

4. Once Ubuntu is installed, the server will reboot. You will probably see that there are updates available.  So, to get these run the following commands:

sudo apt-get update
sudo apt-get upgrade

5. Figure out your local IP address:

ifconfig

If this address isn’t on your own subnet, then you can change the network specifications for the VM in VirtualBox from NAT to Bridged Adapter, then reboot the VM.

If all is well so far, you should see the Apache default home page when you type in the ip address into your browser.

apachedefault

At this point, we have a working web server running on our virtual machine.  Now we can actually install WordPress.  My first instinct for this was to use the apt-get method to install the files.

sudo apt-get install wordpress

This appeared to work but didn’t yield a running installation. So after searching I used these instructions to get to get a running WordPress installation.

 

Progress with MailClark, Slack, FileMaker, WordPress

Somemotor-1381998_1280times you just have a week where you are grinding away at things, and nothing particularly new or spectacular happens, and no new revelations are on the horizon. This was one of those weeks.

MailClark and Slack

The MailClark experiment is moving into its third week. As I hoped, it  appears to be working well as an application for low-volume  email customer support. In another couple of weeks, I will introduce this to the rest of the customer support team, so that more than one of us can respond to emails and questions sent in to our help address.

FileMaker CRM

Our FileMaker CRM is taking shape. I have built the basic tables, and am working on the data entry screens. I’ve hosted it on a new Mac Mini with an SSD drive using FileMaker Server. This is the first time I’ve ever used an SSD up close and personal (all Linodes are SSD based), and I’m impressed with the speed.

FileMaker has been steadily improving the web client of the application called WebDirect. This is an effective implementation of the regular FileMaker desktop interface, but rendered in HTML5 and CSS for a web browser, which eliminates the need to install the FileMaker software client on your desktop workstation.  My thought is that we will provide access to the CRM via a virtual private networking connection rather than allowing direct access through our firewall.

Similar to FileMaker Go, the FileMaker client that runs on iPhones and iPads, I  expect to build dedicated data entry screens for the web clients. This means that each platform gets its  own screens….desktop,  iDevice, and web.  The startup script for the application will contain a CASE statement which determines which platform you are connecting with, and point you to the correct screen.

So far the data design and use cases appear to be pretty accurate and for the most part remain unchanged. One thing I have done is add a “reference” section. This will provide a front-end for the National Center for Educational Statistics database of public and private schools.

WordPress and Apache

I spent a couple days faffing about with my Apache / WordPress installation, trying to figure out what what slowing down our blog. It turns out to be hidden in plain sight, and here is one explanation.

 

Troubleshoot Apache with mod_status

We are having a bit of a contretemps with one our of Linode blog hosts. This host is running Ubuntu Linux 12X  LTS and WordPress, and seems to be having fits of high CPU utilization. One way to see into the web hosting process is to examine the Apache mod_status page.

Mod_status is an Apache module which prints statistics about the Apache application. By default the page will be accessible using the the suffix of /server-status on your root web site URL. http://mysite.com/server-status. However, by default this is restricted to a request from a browser at the 127.0.0.1 address.

If you log into the console, you can attempt to see the status by running the following:

apachectl status

or if you aren’t logged in as root,

sudo apachectl status

This returns the status page.

Screenshot_071516_011101_PM

If you are attempting to access this from a browser on another workstation via http://mysite.com/server-status, you get a 403 message:

Screenshot_071516_110946_AM

The first thing is to find where this restriction is located. It is going to be in one of the Apache configuration files. These are located within /etc/apache2. If the status module is enabled, there will be a status.conf file that can be edited.

sudo nano  /etc/apache2/mods-enabled/status.conf

Screenshot_071516_112041_AM

Edit the lines after the <Location /server-status> line, per the instructions. After editing mine looked like:

<Location /server-status>
   SetHandler server-status
   #Require local 
   Require ip 192.168.xxx.0/24
</Location>

where “xxx” is your local subnet.  In the above example, I’m accessing the server from inside the firewall from a workstation located on the same subnet as the Apache server. (In reality, I’m actually accessing a server running within a VirtualBox virtual machine, located on my Windows machine. )

Once these changes are made you have to restart Apache.

service apache2 restart

 

If this is successful,  you get a page similar to the character-based page, but nicely formatted in html. Since the data is similar, however, if there is any issue trying to get at the statistics, probably the character-based method at the console is the first thing to try.

Screenshot_071516_011525_PM

Ah…but what if you get a page, but it isn’t a status page?  This is the problem we have with our WordPress site, and it has to do with which page is served as the default. http://myblog.com/server-status  returns the default page from the blog rather than the server-status page.  Stay tuned for that fix.

Tech Friday: Debugging the WordPress White Screen of Death

motor-1381998_1280Problem: I attempted to change a password for a user of the WordPress web site. I got into the administrator’s dashboard, choose “Users”, found the person’s entry, changed their password, clicked on “save changes” and Poof! I get a blank screen.

 

It turns out there is a name for such screens, and the name is called the WordPress White Screen of Death, or WSOD.

There are a ton of possible causes for this, but many of them relate to a problem with PHP code located someplace  within WordPress, or within WordPress plugins. Since the WSOD is just that…it doesn’t show any kind of detailed error message, one approach to finding the problem is to enable error checking and display at the PHP level. This is a quick entry in the WordPress wp-config.php file located in the root WordPress directory.  Here’s the file as it shows up in FileZilla.

WP_Config

And here is the contents of the file as displayed in Notepad++

WP_DEBUG

The trick is simply to change false to true to enable the display of error codes.  And sure enough,  once I did that and retried the password change operation I saw the following message:

Fatal error: Call to undefined function curl_init() in /var/www/html/wordpress/wp-content/plugins/gmail-smtp/class.phpmaileroauthgoogle.php on line 171

This was an indication that a plugin which I had added was causing the error. Once I removed the plugin, I could change my user’s password without problems and the WSOD was banished, at least for now.