Applications


The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

Recently, we were trying to update a WordPress installation that was running under apache in a CentOS 7. When we would press the lovely blue button to update WordPress we would get the following error:

The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

Installation Failed

At first we thought it was an issue with the privileges on the folder, so we did the following steps to fix the issue:

Find which user is controlling apache server:

We executed the following command to get the name of the local user that was handling the apache web server:

ps -ef | grep apache;

From which, we got the following results:

apache 7289 8523 1 10:35 ? 00:00:03 /usr/sbin/httpd -DFOREGROUND
apache 7293 8523 0 10:35 ? 00:00:02 /usr/sbin/httpd -DFOREGROUND
apache 7316 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7317 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7335 8523 1 10:35 ? 00:00:03 /usr/sbin/httpd -DFOREGROUND
apache 7347 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7348 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7349 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
apache 7350 8523 0 10:35 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND
apache 7351 8523 0 10:35 ? 00:00:01 /usr/sbin/httpd -DFOREGROUND
root 8071 7978 0 10:40 pts/1 00:00:00 grep --color=auto apache

The first column is the name of the user, so we found out that apache local user is the user executing the apache web server.

Repair all file and folder access rights:

After getting the above information we proceeded to update the access rights in our WordPress installation folder (/var/www/example.com)

find /var/www/example.com -type d -exec chmod 755 '{}' \;
find /var/www/example.com -type f -exec chmod 644 '{}' \;
chown -R apache:apache /var/www/example.com;

To our disappointment, nothing changed and we would still get the same error. Luckily enough we had another ace in our sleeve!

Checking the security context of each file and folder:

We executed the following command (ls -Z) to get the security context of the files and folders in the installation folder of WordPress:

ls -Z /var/www/example.com;

Where we got the following results:

drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 api
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 favicon.ico
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 index.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 license.txt
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 readme.html
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 r-file.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wordfence-waf.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-activate.php
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-admin
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-blog-header.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-comments-post.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-config.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-config-sample.php
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 wp-content
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-cron.php
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-includes
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-links-opml.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-load.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-login.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-mail.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-settings.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-signup.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 wp-trackback.php
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 xmlrpc.php

What we got from this result: all files and folders marked with the httpd_sys_content_t are not directly editable by the apache web server even though the user has the rights to do so as it is a security step by SELinux.

httpd_sys_content_t
Use this type for static web content, such as .html files used by a static website. Files labeled with this type are accessible (read only) to httpd and scripts executed by httpd. By default, files and directories labeled with this type cannot be written to or modified by httpd or other processes. Note that by default, files created in or copied into /var/www/html/ are labeled with the httpd_sys_content_t type.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/managing_confined_services/sect-managing_confined_services-the_apache_http_server-types

The simple solution

We just changed the security context for the folders and files to httpd_sys_rw_content_t which allows apache web server to edit the files:

httpd_sys_rw_content_t
Files labeled with this type can be written to by scripts labeled with the httpd_sys_script_exec_t type, but cannot be modified by scripts labeled with any other type. You must use the httpd_sys_rw_content_t type to label files that will be read from and written to by scripts labeled with the httpd_sys_script_exec_t type.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/managing_confined_services/sect-managing_confined_services-the_apache_http_server-types
chcon -R --type httpd_sys_rw_content_t /var/www/example.com;

After this command finished, we updated WordPress as normal!

(In case you want to change the security context back to the original just execute chcon with httpd_sys_content_t as parameter on the folders and files you want to operate as read-only).

Advertisements

Safari: ‘a.getTime’ is undefined

Recently, we were working with Google Charts at which we were presenting data from a timeline with some processing.
Our JavaScript code was formatted as follows to create Date objects:

$value = "2020-03-19 23:45:00";
var dateStrFormat = new Date($value);

The above code worked fine on Firefox and Chrome but it failed on Safari with the error:
a.getTime is not a function. (In 'a.getTime()', 'a.getTime' is undefined)
After some investigation we found that Safari does not support a Date() constructor that contains time as well so we had to change the code to the following block:

var dateStr = "2020-03-19";
var dateStrFormat = new Date(dateStr);
var hourStr = "23";
var minutesStr = "45";
dateStrFormat.setHours(hourStr, minutesStr);

The above works on all browsers!


WordPress: How to disable a plugin on all pages except for a specific one

A few days ago we were struggling to find a way to limit the amount of plugins that load at any point on a WordPress website. We noticed that several plugins enqueue their scripts and their styles in all requests to the website even if they are actually used on a single page only. This issue was important to address as it was making the whole server slower by giving it extra requests from the client that would never provide any actual benefit to the user.

Initially, we tried to selectively enable those plugins on their respective pages but we did not get it right and things would load out of order and break. Instead of following the ‘enable when needed‘ methodology we decided to follow the ‘disable unless needed‘ methodology which seemed simpler at the time.

Our changes involved in adding the following code in the functions.php file of our child theme.

//Register a filter at the correct event
add_filter( 'option_active_plugins', 'bf_plugin_control' );

function bf_plugin_control($plugins) {
  // If we are in the admin area do not touch anything
  if (is_admin()) {
    return $plugins;
  }
  
  // Check if we are at the expected page, if not remove the plugin from the active plugins list
  if(is_page("csv-to-kml-cell-site-map") === FALSE){ 
    // Finding the plugin in the active plugins list
    $key = array_search( 'csv-kml/index.php' , $plugins );
    if ( false !== $key ) {
      // Removing the plugin and dequeuing its scripts
      unset( $plugins[$key] );
      wp_dequeue_script( 'bf_csv_kml_script' );
    }
  }

  if(is_page("random-password-generator") === FALSE){ 
    $key = array_search( 'bytefreaks-password-generator/passwordGenerator.php' , $plugins );
    if ( false !== $key ) {
      unset( $plugins[$key] );
    }
  }
  
  if(is_page("xml-tree-visualizer") === FALSE){ 
    $key = array_search( 'xmltree/xml-tree.php' , $plugins );
    if ( false !== $key ) {
      unset( $plugins[$key] );
      wp_dequeue_script( 'bf_xml_namespace' );
      wp_dequeue_style( 'bf_xml_namespace' );
    }
  }

  return $plugins;
}

One day, we will clean the above code to make it tidy and reusable.. one day, that day is not today.

What the code above does is the following:

  • Using is_admin it checks if the Dashboard or the administration panel is attempting to be displayed, in that case it does not do any changes.
  • With is_page, it will additionally check if the parameter is for one of the pages specified and thus disable the plugin if the check fails.
  • PHP command array_search, will see if our plugin file is expected to be executed (all files in $plugins are the plugin files that are expected to be executed) .
  • wp_dequeue_script and wp_dequeue_style remove the previously enqueued scripts and styles of the plugin as long as you know the handles (or namespaces of the enqueued items).
    To get the handles (namespaces) we went through the plugin codes and found all instances of wp_enqueue_script and wp_enqueue_style.
    Please note that several small plugins do not have additional items in queue so no further action is needed.


Starting XAMPP with port 80 on Windows 10 Professional

Recently we were asked to have a look at a XAMPP installation on a Windows 10 Professional machine which would not start while giving the following error:

Problem detected!
Port 80 in use by "Unable to open process" with PID 4!
Apache WILL NOT start without the configured ports free!
You need to uninstall/disable/reconfigure the blocking application
or reconfigure Apache and the Control Panel to listen on a different port

The culprit of this problem was a module of the IIS (Internet Information Services for Windows Server) that is named World Wide Web Publishing Service (WWW service or W3SVC service). Apparently, the W3SVC was hoarding port 80 even though IIS was not executing. To provide a quick solution, we decided to stop the W3SVC and get over this difficulty in a jiffy.

As you can see in the following video, to stop the World Wide Web Publishing Service (WWW service or W3SVC service) we performed the next steps:

  1. Clicked on the Start button
  2. Typed in the word services, which showed the Services link which we clicked to start the windows services  manager
  3. Then, we scrolled down in the Services window until we found the World Wide Web Publishing Service
  4. Finally, we right clicked on it and selected Stop.

After that, XAMPP was able to start Apache on port 80 with no issues.