Tag Archives: wordpress

GoDaddy WP 4.7.3 Upgrade Gotcha

It’s been a fun time trying to get everything updated and to where I want it to be on my website.  Just recently I did a post about some housekeeping I’ve been doing on my website along with outstanding items.  One of the things that has come up was updating to the latest version of WP (4.7.3) as I was currently on 4.7.2.  I tried to do it as soon as it was available within WordPress itself, but this kept failing and so I awaited until it was available through the dashboard on my GoDaddy Windows (Plesk) hosting.

I thought fantastic, I’ll click the button and wala!  But no, for another domain it did work right off the hop, but for dwcryan.com no such luck.  I was getting the following error:

Error: Update failed: Non-zero exit status returned by script. Output stream: ‘ (Error code 1)’. Error stream: ‘ (Error code 1)’.

So the Googling started and I came across a Plesk support article on the error I was experiencing.  The advice was to either comment out the error_log line or to set it equal to syslog.  In my hosting I do not have access to the PHP.ini file which meant I could not do this; however, for each domain in my hosting there is a .user.ini file within the corresponding directory root.  By placing the following line at the bottom of that file (on a new line) I was able to successfully update my WordPress installation through the Plesk 12.0 Applications Dashboard:

error_log = syslog

Plugin Update Took My Site Down

My site was down for a while on Friday because during my lunch break I decided to update my site.  The update that took down my site was HugeIT Portfolio plugin.  I do not believe it was due to the plugin itself but do to the update process getting interrupted, confronting visitors to the site with a “500 Internal Server Error”.

In order to fix my site when a plugin takes it down I do the following, if I’m unable to login and disable the plugin:

  • Rename the plugins directory to, i.e. disabled_plugins
  • Create a directory called plugins
  • Log in to the site (all plugins should appear disabled)
  • Delete the plugins directory
  • Rename the disabled_plugins directory back to plugins
  • Go to view your plugins, they should all appear as disabled
  • Enable them one by one, checking your site until you find the offender (if you don’t know), if you do then enable all but the offending one
  • Delete the offending plug

What you decide to do next is up to you.  You can either install it again and reconfigure or find a replacement.  I tried to install it again; however, that created another instance of it.  With the plugin now appearing twice I thought it best to delete them both as the plugin directory in the plugins folder was only their once.  This cleans up the plugin folder.

I was able to install the HugeIT Portfolio plugin again; however, upon activation my site was taken down again.  so I had to rename the folder that particular plugin (portfolio-gallery) in order to gain access to my site again.  I am  now going to delete that plugin and be back on the hunt for a means of setting up a portfolio on my site.  I was using Aeolus – Creative Portfolio before; however, activating that one again now I remember why I had switched in the first place.  It doesn’t work well with my theme, or at least that’s my guess, as all the text becomes really tiny and makes the site unusable.

Upgrade to WordPress 4.0 Failed through GoDaddy

WordPress & Godaddy

I got myself into an interesting predicament today.  I was in going to show my mom how to update the church website and saw that there was an update to WordPress 4.0 showing in the GoDaddy console.  I decided to do the update and then that is when things went sideways.

Upon the update finishing I went to the website site only to see a 500 Internal server error message, shown below:

I knew this was not a good sign, and preceded to investigate and my first thought after some Googling was to manually upload WordPress 4.0 files (all of them except the wp-content folder & wp-config file), so I downloaded the zip and preceded to do so.  Once this didn’t fix my issue and the site is for someone else I wanted to rectify the problem as quickly as I could so I contacted GoDaddy support.  Thanks to the patience of Spencer D. and his technical contact we were able to get to the bottom of things.

The first step was to create a web.config file (back up any current one, or in my case where you deleted it, create a new one) that contains the following:

<?xml version="1.0"
        <httpErrors errorMode="Detailed"

In my case I am using the IIS 8 Plesk version; however, you should be able to find the correct version for you in this GoDaddy’s Help article if you are using GoDaddy Windows hosting.

You upload this to the root folder for your particular domain and in my specific case this led to me receiving the following when I navigated to the website, stlukesdryden.com, after waiting for a bit:

All-in-One Event Calendar: require(G:\PleskVhosts\dwcryan.com\stlukesdryden.com\wp-content\plugins\all-in-one-event-calendar\vendor\lessphp\lessc.inc.php): failed to open stream: No such file or directory @ G:\PleskVhosts\dwcryan.com\stlukesdryden.com\wp-content\plugins\all-in-one-event-calendar\lib\bootstrap\loader.php:88 #2
All-in-One Event Calendar: require(G:\PleskVhosts\dwcryan.com\stlukesdryden.com\wp-content\plugins\all-in-one-event-calendar\vendor\lessphp\lessc.inc.php): failed to open stream: No such file or directory @ G:\PleskVhosts\dwcryan.com\stlukesdryden.com\wp-content\plugins\all-in-one-event-calendar\lib\bootstrap\loader.php:88 #2
PHP Fatal error: require(): Failed opening required ‘G:\PleskVhosts\dwcryan.com\stlukesdryden.com\wp-content\plugins\all-in-one-event-calendar\vendor\lessphp\lessc.inc.php’ (include_path=’.;.\includes;.\pear’) in G:\PleskVhosts\dwcryan.com\stlukesdryden.com\wp-content\plugins\all-in-one-event-calendar\lib\bootstrap\loader.php on line 88

I now knew that an error in the All-in-One Event Calendar was causing my site to not be displayed.  In order to disable the failing plugin you can apparently either rename the plugin folder located in ../wp-content/plugins or (the way I did it) you can access your database through PhpMyAdmin and search the wp_options table for active_plugins.  I then saw this for the active_plugins option:

32       active_plugins       a:4:{i:0;s:55:”all-in-one-event-calendar/all-in-on…       yes

Editing this row, and focusing on the options_value column you want to delete the plugin information for the message you saw when navigating to your site earlier in this post, which in my case is All-in-One Event Calendar, in bold below:


It is important to delete the entire contents from the i to the ; (semicolon) for the plugin in question.  Once I had done this I was able to access my website homepage, though not the login screen (which I rectified by copying over the wp-login.php file, it wasn’t allowing me to copy earlier, because as I later realized I had the page, giving me the error, open in my browser), but no other pages on the site.  I was able to solve the broken links/pages in the same fashion as when I broke them with my publish, you can find it at the bottom of this post.

Worth noting is that Spencer mentioned my WordPress installation was indeed at version 4.0, which jives with what the GoDaddy console under ‘Manage My Web Applications’ states and when I access the WordPress Dashboard for my site it states I am running WordPress 4.0 too, so I’m hoping all is good now.  Well, that is except the Event Page is blank as I have to get the event calendar plugin working, which involves getting the latest version installed.

This process took longer than expected and I felt it was worth blogging about.  Will make sure I have a fair bit of free time on my hands before attempting to upgrade WordPress on this domain.

Subdomain within Main Domain Folder

Well, today I was doing some experimenting and investigating how I could get my Tracker application published to a subdomain through automation instead of manually copying the files every time.  It’s only an MVC template right now but I wanted to be able to test that the default functionality was going to work with my web hosting, prior to proceeding.  Things were going pretty good until I realized that publishing my application broke my WordPress site.  By broke what I mean is that critical files and settings got overwritten causing my site navigation menu to get messed up as well as links to pages not working (404 errors) and only my home page could be displayed.

I hypothesized the cause of the overwrite to be due to the subdomain folder being contained within the root folder for my website instead of up one level so I deleted the subdomain and the folder it was using.  I then recreated it so its root folder is at the same level as my main sites root folder.  Apparently trying to organize your subdomains within your root domain folder is not a good idea.

I was then able to follow the steps again to publish a web application, which I outline here.

I took the opportunity of my site already being broken to install the latest WordPress update.

Since my incorrect publish broke my custom links I determined how to fix this was from my WordPress dashboard you go to Settings -> Permalinks and switch the option to Default and save your changes.  Then you switch it back to your custom selection and save the changes again.  Prior to discovering this not even deleting the pages permanently and recreating them removed the 404 error for me.