Add Social Media Feeds to your WordPress Website with Feed Them Social Plugin

Feed them Social is a WordPress plugin which enables social media feeds to be displayed on your WordPress website.

Developed by SlickRemix the plugin supports feeds for:

  • Facebook
  • Twitter
  • Pinterest
  • YouTube
  • Instagram

Feeds are added by selecting the social media option from the menu and creating a shortcode for addition to the website.

As would be expecting the layout for each of the social media options is similar with a dialogue for the fetching of the token at the top. Below there are the settings particular to the feed which is being configured.

Having accepted to provide SlickRemix access to your social media its possible at a later date to revoke this permission. the method of doing this is specific to each of the social media websites.

WordPress shortcodes can be included either within the body text of a post or page, or by incorporation within the theme’s php files.

Adding Social media links

Details on adding each of the supported social media sites.

Facebook

From the left menu click on the Facebook Options link

At the top of the page click on the button “Login and get my Access Token.

This will take you to Facebook, I found an initial popup window stating that SlickRemix will receive your name and profile picture.

The next page is an option to allow SlickRemix to manage my pages. If you chose to disallow this then an access token won’t be generated.

Finally there’s a message that the access token is being received and back to the website.

Back on the website the page previously selected is shown together with its ID reference.

Click on this page reference to transfer the details into the PageId and Access token boxes above.

From the options below make your choices and click on the Save all button at the bottom.

Follow the link to the settings page to generate your shortcode.

Instagram

The Instagram layout is similar to Facebook, described above.

Click on the button to proceed.

On the Instagram website a screen is shown which confirms that Feed Them Social by SlickRemix is requesting to do the following:

  • Access your basic information: your media & profile info
  • Access public content: media & profile info of public users

Buttons are present below to either cancel or Authorise. Click on Authorise.

Note below the box there is confirmation that the apps access can be revoked at any time by clicking on revoke in the access section.

Back at the WordPress website the Instagram ID and Access token Required fields are now populated.

Make your choices from the Follow Button Options and click on Save all Changes.

Visit the Settings Page to collect your shortcode for use.

Incorporation the Shortcode

Shortcodes are used to render the feed. Its a way to tell WordPress what plugin code to incorporate, together with a number of options.

Generating Shortcode

The shortcode for each of the feeds, which have had a reference generated, is made on the settings page.

At the top of this page there is a dropdown list of the different supported feeds. Select the one which you wish to generate the shortcode for from the list.

The displayed content changes to reflect the options available.

Note if you haven’t configured the selected feed yet a link is included to its options page.

Work your way through the options and click on the button Generate shortcode at the bottom.

Using the Shortcode

Shortcodes can simply be pasted within the body text of pages and posts.

You may find having a private test page is a good way to experiment with your feed settings.

Once you are happy with the options then add the feed into the page, widget or use it within the php code used for your theme.


PHP Fatal error: include_path=’.:/usr/share/php:/usr/share/pear’

A fresh install and an installation of WordPress via the Debian apt package management gave the error

PHP Fatal error: include_path='.:/usr/share/php:/usr/share/pear'

On a development computer I chose to install WordPress via the package manager as opposed to creating Apache site directories.

With MySQL and Apache installed WordPress is added by executing, at the command prompt

apt-get install wordpress.

However, when I first navigated to the website at localhost/wordress/ rather than seeing the start of the me WordPress website creation sequence I had a blank white screen, the so called white screen of death!

Debug reporting can be enabled within the file wp-config.php, located in the root of the website. Here’s the 3 debug options, as disabled:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

The packaged Debian version relocates this to the directory

/etc/wordpress

Editing the file config-localhost.php I enabled debug logging setting my chosen options to true.

Still with a blank screen shown I chose to look at the Apache error log.

/var/log/apache2/error.log

using

tail -f /var/log/apache2/error.log

The last few lines of the log file are:

PHP Warning: require_once(/etc/wordpress/config-localhost.php): failed to open stream: Permission denied in /usr/share/wordpress/wp-config.php on line 19
PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19
PHP Warning: require_once(/etc/wordpress/config-localhost.php): failed to open stream: Permission denied in /usr/share/wordpress/wp-config.php on line 19
PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19

The error suggested that Pear was not installed.

To check to see if pear was installed at command prompt I typed pear

neil@abc:/home/neil# pear
bash: pear: command not found

I then installed pear using

apt-get install php-pear

Giving the following:

Suggested packages:
  php5-dev
The following NEW packages will be installed:
  php-pear
0 upgraded, 1 newly installed, 0 to remove and 107 not upgraded.
Need to get 264 kB of archives.
After this operation, 2,108 kB of additional disk space will be used.
Get:1 http://mirror.ox.ac.uk/debian testing/main amd64 php-pear all 5.6.16+dfsg-2 [264 kB]
Fetched 264 kB in 0s (625 kB/s)  
Selecting previously unselected package php-pear.
(Reading database ... 218176 files and directories currently installed.)
Preparing to unpack .../php-pear_5.6.16+dfsg-2_all.deb ...
Unpacking php-pear (5.6.16+dfsg-2) ...
Setting up php-pear (5.6.16+dfsg-2) ..

A restart of Apache

service apache2 reload

To my disappointment – no effect it still showed the error

Tue Dec 22 13:57:38.596887 2015] [:error] [pid 24889] [client ::1:41744] PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-localhost.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/share/wordpress/wp-config.php on line 19

I considered the permissions of the file in the directory /etc/wordpress, assigning to it the apache permissions

chown www-data:www-data /etc/wordpress/config-localhost.php

Once more I revisited the website at /localhost/wordpress

Success! I was now getting the WordPress installation.

Hide Admin Messages from Subscribers

Do you want all your WordPress logged in users to see your system messages?

Messages declaring pending plugin updates, a WordPress core update, or a notification from a plugin, all visible to any logged in user.

Lets keep the info given to registered users of your website to a minimum. We don’t wish to tell them about the status of the website.

There are a couple of areas to target:

  • Admin notifications
  • The notification bar

WordPress provides hooks to actions covering both of these areas.

By checking the capabilities of the user we can determine whether we wish to show the info.

The restriction uses actions and filters added to the file functions.php in the theme.

Admin Notifications

Perhaps the most important.

Checking to see whether the user is able to update the core first, this function determines whether to show admin notifications.

function show_update_notice_admin_only()
{
    if (!current_user_can('update_core')) {
        remove_action( 'admin_notices', 'update_nag', 3 );
    }
}
add_action( 'admin_head', 'show_update_notice_admin_only', 1 );

Notification Bar

At the top of the page there is the notification bar. Lots of content on this bar we don’t want non-admin users viewing.

So can we hide it ? – Yes, using filters.

This time we are testing to see if the user is unable to perform a couple of actions.

The first test is the management of options.  If the user is unable to do so then hide the admin notification bar.

Similarly the second test checks whether the user can update posts. If this isn’t possible then again the admin notification bar is hidden.

// show admin bar only for admins
if (!current_user_can('manage_options')) {
	add_filter('show_admin_bar', '__return_false');
}
// show admin bar only for admins and editors
if (!current_user_can('edit_posts')) {
	add_filter('show_admin_bar', '__return_false');
}

WooCommerce Cross-Sell and Upsell Products

Upsell and Cross-sell products are used in WooCommerce to increase product sales.

When do these two lists of products get shown?

Let’s begin by adding some products of each type to a product.

On the Product data section there are a number of tabs running vertically at the left with the associated configuration options in the remainder of the page.

WooCommerce Cross Sell and Upsell products: linked products

Click on the tab linked products to show the upsell and cross sell options.

Linked products are added by typing a few letters from the product name and making a selection from the resulting list.

WooCommerce Cross Sell and Upsell products: adding upsell product

In the screenshot above the upsell product of Chantenay Carrots is being added.

Upsell

Upsell products are shown when viewing a single product’s detail, its description, images, price and attributes

WooCommerce Cross Sell and Upsell products: view product

In this view we are seeing an individual product with below two sets of products, the upsell products and the related products, based on what we have seen before.

The upsell products are premium versions of the product selected to view. In this instance I’m showing the higher priced purple spouting and kalettes.

Cross-Sell

The list of cross sell products appears when viewing your basket of items.

Having made our product purchases. Click to view the basket.

WooCommerce Cross Sell and Upsell products: view basket

In this view we are seeing the configured cross sell products of carrots and potatoes.

With a cross-sell product we wish to encourage the shop visit to buy something relevant to the items in the basket. I’ve chosen to show more vegetables but a steamer/saucepan to cook the vegetables would also be appropriate.

Reset WordPress Metabox Positions

Viewing a WordPress page, post or custom entry

Having moved the sections around how do I reset.

Reset WordPress metabox positions: view post

The idea is how to restore the edit view of

Whilst developing a recent plugin I had moved the meta box sections around. But, of course, I wanted to see the default. As per a fresh installation.

So how do I reset the layout of the displayed WordPress displayed content area sections?

For this approach you’ll need access to phpMyAdmin via your hosting control panel.

The relevant saved options in the database table wp_usermeta are to be deleted.

Login to phpMyAdmin to begin.

Reset WordPress metabox positions: phpMyAdmin

In the left hand database & table menu click on the database for the WordPress website of interest.

From the top row of tab options click on SQL.

Reset WordPress metabox positions: phpMyAdmin SQL

The content entry box can be used to enter the SQL which will be used to show the specific entries in the wp_usermeta table.

wanted to reset the metabox positions after moving them round

In you PhpMyAdmin query for: (if you have a different database prefix, change that in the query, also change the user_id to yours)

SELECT * 
FROM  wp_usermeta
WHERE  user_id =1
AND  meta_key LIKE 'meta-box%'

Click on Go in the bottom right corner.

Reset WordPress metabox positions: phpMyAdmin SQL usermeta

Look at the meta_key column to determine which plugin, theme, post or whatever the entry is associated with.

Delete those values which are associated with the item which you are looking to reset, and you will get the original order back.

Easy –  I simply deleted the relevant one.

And the user id> Well its a development website on a development computer with the initial user as my admin login. So no problems there with knowing the value.

But this is cumbersome. You need to know the relevant user id. It would be better to use the user name.

This is easier to find and has less chance of making changes to the wrong account.

For this we’ll modify the SQL using a join to combine the two tables of usermeta and users.

SELECT *
FROM wp_usermeta
JOIN wp_users ON wp_usermeta.user_id = wp_users.id
WHERE wp_users.user_nicename ='neil'

As previously change the relevant parts.

In this example we’ll show all items in the usermeta table, as before. The third row shows the join with the users table. With the linkage by the associated user id.

The last line is the restrictive clause, this time using the displayed name of the user.

With a little SQL and the use of phpMyAdmin we are able to delete entries in a WordPress table, resetting the order of the metaboxes from a plugin, page or post.

WordPress Redirect to https

Your WordPress website was running as a traditional unsecured site.

Now to meet the search engine guidelines you have added a certificate and encrypted the website.

But the old unencrypted website address is still accessible.

This isn’t good for SEO with effectively two websites with the same content.

How to redirect the unencrypted traffic to the encrypted website address.

We’ll add the redirect to the .htaccess file found in the root of the website.

Shown below is the default entry in the .htacces file

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

The additional redirect rule to be added is:

RewriteCond %{ENV:HTTPS} !=on
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

And here it is the updated version, with the additional redirect rule added.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{ENV:HTTPS} !=on
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

The content of the .htaccess file may be amended via the hosting control panel or via FTP.

You may wish to take this amendment as a prompt to take a backup of your website files.

An automated WordPress Update has Failed to Complete

Checking a website the morning after a recent WordPress update I found that the update had failed.

At the top of the admin page an error message was showing the message:

An automated WordPress update has failed to complete - please attempt the update again

As per the instruction I clicked on the link to run the update once more.

But that failed too! The message was still showing at the top of the admin screen.

WordPress uses a file in the root of the WordPress installation to determine whether it’s in maintenance mode.

The file named .maintenance is added by the WordPress updater to the root of the WordPress website.

Here’s the scary part. If I delete the file will it cause damage to my WordPress website?

I would allow sufficient time to ensure that WordPress has completed the task which put it into maintenance mode. The update process is reckoned to take not more than 10 minutes, but allow a few more to be sure.

If its an update to the WordPress core files then it will be clear when the task is completed.

As you are searching for reasons for the maintenance mode error message the associated task ought to be complete.

I deleted the file .maintenance from the WordPress root folder.

I clicked on the dashboard link on the admin page, preferring not to click on the update link.

Resolved the failed update notification was gone.

The version of WordPress indicated as installed was the latest one.

WordPress Update – 504 Gateway Time-out

Looking to update WordPress to the latest version, I clicked on update, but after a while I received the following error:

504 Gateway Time-out
The server didn't respond in time.

So what to do?

Sometimes with WordPress updates its worth being patient. I’ve seen errors which when returning to the site have cleared. In this case the same was true. I visited the site direct, public view. All was well, but an update was marked as outstanding. It then went to the admin with the WordPress core update pending.

So I refreshed the browser tab with the with the 504 gateway error. And low and behold all was well the update was completed.

One moment of hesitation – a single update was still being shown in the black top bar. But all was well it was a plugin which needed to be updated, based on the newer version of WordPress.

Option to update to WordPress 4.9–en_GB Missing

On one of my websites the option to update to the local language version is missing.

This is what I’m expecting to see

An updated version of WordPress is available.
You can update to WordPress 4.9–en_GB automatically:
This localised version contains both the translation and various other localisation fixes. You can skip upgrading if you want to keep your current translation.
You can update to WordPress 4.9–en_US automatically:

While your site is being updated, it will be in maintenance mode. As soon as your updates are complete, your site will return to normal.

But for this site I only had the option to do the non-localised language update.

How to install the en-GB version of WordPress?

in the root file wp-config.php I had

//define('WPLANG', '');
define ('WPLANG', 'en-GB');

I found that this is now deprecated. As of WordPress version 4.

To set the locale for the WordPress website the variable $locale is set accordingly within the file wp-config.php, found in the root of the website.

I replaced it with

//define('WPLANG', '');
//define ('WPLANG', 'en-GB');
$locale='en_GB';

and it worked!

Note the change from a hyphen to and underscore.

Further Reading

If you are interested in reading further about wplang and its deprecation these links may interest you.

wplang WordPress forum

wplang in wp-config

wplang deprecation in version 4 notification

Changeset 29630

Disable Login Using Email Address

WordPress allows login by either username or email address.

But, email addresses are more likely to be common knowledge. Or perhaps easier to guess. We tend to keep our email addresses to set patterns.

Its all very well having a fancy obscure username but if the email address associated with the account is easily guessable, all that effort has been wasted.

An email address could be created, just for logging into the website. It could be made obscure and configured to forward emails. But this is looking like a username. Would it not be better to configure WordPress to block logins using email addresses, only allowing logins using a username and password?

A set of random characters, upper case and lower case, together with numbers and symbols can make a good choice for a username, but not a good choice for an email address. Who would be comfortable receiving an email from such an address?

Do you really wish to create a separate obscure email address (a shadow email address) for every registered user – or at least admin user of a WordPress website?

I can explain to my customers the need to have an obscure username to access their website. But to suggest that a second email address should be created for them to use…

So I have another little section of code to be added to the functions.php file included within my theme files.

/*
* Block login by email address
*/
remove_filter( 'authenticate', 'wp_authenticate_email_password', 20 );

There you are the simple solution.

With the above code login to a WordPress website using the account email address is blocked. Access using the likely more easily guessed email address has been stopped.

Now to sell to my customers the idea of using a username as equally obscure as their password!