Taking over a customer’s Godaddy Managed WordPress website we wanted to access their “All-in-one-migration” backup files. The website site wouldn’t let us download them due to permissions issues. We dug around in the account and found the process we needed. Here are the steps.
Go to your GoDaddy Product Page
Next to “Managed WordPress” select “Manage All“.
Select the site you want to use and go to the “Settings” tab.
Under “Production Site“, find SSH/SFTP login and select View or Change. Copy the “Hostname” for use in your FTP program and “Create new login“.
You can also access the files in the “File Browser” in the “Settings” menu.
The “All-in-one-migration” backup files are located in the “wp-content > ai1wm-backups” directory.
We especially like WordPress for blogging, but like other software things break. Our blog suddenly wasn’t displaying correctly. The first place to look is in the Themes section; however, when we logged in “themes” link wasn’t available. Disabling all the plugins didn’t fix the issue.
We started the repair by downloading the latest backup, restoring it, and seeing if it was broken as well. It wasn’t. On the live site we installed the latest version of WordPress again, but that didn’t fix the issue of not being able to view the themes. With the restored version we went through the plugins one by one and we found it.
The issue turned out to be the theme we tried but wasn’t running. It was the “Screenly Cast for WordPress” plugin that was causing the issue. We had the plugin disabled; however the issue wasn’t resolved yet. We discovered when we viewed the site and moved our mouse over the link to get to the WordPress Dashboard we had the link to get to the Themes. It took us to our themes and we could see the Screenly Cast for WordPress theme was now the active theme. We switched it back the theme we were using and this resolved the issue. We now had the Themes link back in the Appearance menu of the Dashboard.
We have used this plugin in the past and had great success with it; however, this past couple of times we have struggled. We got access to a client’s Facebook Page as an “Admin“, so we should be set. We logged into Facebook under our account, went to the clients’s page, and verified we could manage the page. In WordPress we started our “feed“. We clicked on the “Login and Get my Access Token“.
We get the login for our account. We hit “Continue as Esceedie” our Facebook account.
The screen would appear to be working and would return to the “Facebook Access Token” page as before. The plugin instructions said below this “Facebook Access Token” there will be a list of the pages/accounts we have access to and to pick one. We had no accounts showing.
If we left the plugin settings page and came back into the plugin’s feed section, we would see the “Access Token” wasn’t working.
So confused we jumped over to Developers.Facebook.com and started creating a new App to try to get an “Access Token” the only way we knew how to create one. Once we had an access token we used the following URL to verify the Access Token, which did not verify.
This was good because it got it the Page ID, and User Name. We used these two pieces in the “Settings” tab, and then generated the access token. In the App we went to Tools >> Graph API Explorer. We selected the “Meta App” we are working on and added the following “User Page“.
Then generated an Access Token. We copied that Access Token and went to Tools >> Access Token Debugger. Pasted the access token in the debugger. Then Extended the token expiration date.
It took a couple of tries and we ended up getting a green bar to “Create Facebook Feed“.
We clicked on the green bar, and now got the following screen.
Now we pasted the feed shortcode into the page; however, nothing showed on the front end.
We went back to “Feed” settings to generate the access code again, and somehow this caused it to work better. We were notified there was an issue and to remove “slickremix” from the app. Once we did everything was working. Still not exactly sure how to we got it to work.
We have enjoyed the functions and price of Ninja Forms when working in WordPress; however, recently we moved a site from “Development” into “Production” and we got the following error message:
This form is currently undergoing maintenance. Please try again later.
Googling didn’t get us anywhere quick. Even on the Ninja forms website. We got it working quickly again by simply “duplicating” the form in the backend and changing the form number on the front end. Everything was working perfectly again.
We like the DIVI page builder. It makes page building fun unless the module doesn’t do what you want it to, and then you find yourself struggling to figure how to get it to do what you want. We had this same scenario today with the Person Module. We simply wanted to center the image, but there was no way to do it in image settings. We found our answer here.
Open the “Person” module.
Go the “Advanced” tab
Go down to “Custom CSS“.
Click on the “Module Elements” tab
Go down to “Member Image” and add the following: margin-left: auto; margin-right: auto;
We had a customer with an old Joomla 2.5 site that we got upgraded to Joomla 3; however, we wanted to go to Joomla 4 and couldn’t find the “Joomla Update” menu item under the Components menu. We were able to find it here.
Go to Extensions -> Manage -> Update
Hit the Options button in the upper right
On the left side menu you find “Joomla! Update“, and here you can set the “Update Channel“
We suddenly started getting the Joomla4 error page while building a new site in XXAMP. Our first search on the web lead us to fixing the “data” directory in the “C:\xampp\mysql\data”. We used the following article to help get us started. They offer 3 different methods. We didn’t have “Administrator” privileges on the machine, so we started with method 2 and coping the data. At first this got the MYSQL working again.
We couldn’t get into the website via the Administrator so we need to change the configuration file manually to get us some error messages to debug the site. We used this article to change the permissions on the “configuration.php” file to not be “read-only”.
We like using WordPress to build website and blogs, and we always add some kind of Web Access Firewall to keep it semi-safe. We review the access logs in the Web Access Firewall login attempts to block bad IP‘s. We noticed some of the attempts were old & current employee email addresses and names. Some of the passwords the attackers used were passwords we have seen previous employees used.
This is a good reason to enforce strong password policies. There are a ton of plugins to achieve this, and a bunch of them are free. We realized these attackers had some information regarding our company. It was great to see these login attempts thwarted by simple plugin. This is why it is so important to install something to help. We used RSFirewall for WordPress on the site where we discovered these login attempts. It was a reminder to us, and we want to keep you aware.
We discovered an issue on the customer’s website when someone submitted the contact us form. We would get a bounce back saying the auto responder email address was sent not from the website’s domain. Since the first email from the form went to the customer we knew it does work, but just won’t send the second email.
We contacted the developer and said it was SPF, DMARC or something in that realm that was causing the issue. We didn’t want to mess with the customer’s DNS setting, but something needed to be done. In the customer’s SPF record was one “include” already so we looked up how to add the second. It was very straight forward.
With a older website we needed to fix some Fontawesome issues where the icons stopped displaying correctly. We needed to match their old Fontawesome version 4. The template was set to use Fontawesome 4. All of this needed to be set in the CSS. Here is what we needed in our CSS file.