WrenMaxwell

Category: Web Site Hosting

Wren Maxwell provides hosting and management including securing your web site. Our management and maintenance services monitor and protect Wordpress & Joomla sites 24 / 7.

  • WordPress Function add_theme_support( ‘html5’ ) was called incorrectly

    An annoying message appeared yesterday when we migrated a customer website to a new server.

    Notice: Function add_theme_support( ‘html5’ ) was called incorrectly. You need to pass an array of types.

    The site is an older build but seemed to be working in every other respect. So a quick dive into the WordPress documentation for add_theme_support() confirmed that the old theme was using an old format of the add_theme_support function. Checking within the theme files identified the offending line and offered a quick fix.

    // Add HTML5 markup structure
// 20230417 thowden : this format is incorrect. 
//add_theme_support( 'html5' );
// it should call with an array like this:
add_theme_support( 'html5', array( 'comment-list', 'comment-form', 'search-form', 'gallery', 'caption', 'style', 'script' ) );
// end thowden

    The above modification was made and the site runs smoothly again. The actual details of the theme and the specific file are not relevant as this could affect any older WordPress theme install.

  • WordPress wp-admin missing gui

    When moving WordPress sites around on servers and from a staging setup to live, we sometimes get bitten with “wordpress wp-admin missing gui” where the public view of the site is working fine, but the wp-admin areas shows up as plain text or simple html. You may not have seen it before, but plain white background and all the dashboard selections are simple links, like the theme is missing.

    Having gone through this several times in the last 4 or 5 weeks, I have decided I need to document what I tried and what worked in the end for the latest site issue. It could be different things and while I did not make a note the last few times, I’ll come back here in future if something different happens.

    We use CPanel for all our hosting servers and the WordPress Toolkit is installed.

    The task was a simple swap from staging to live which I do on a regular basis, and do it manually, as I have done for numerous years. However this time the dreaded “wordpress wp-admin missing gui” struck!

    Skipping the intervening hour of trying a multitude of settings, I discovered that this site was impacted by one of the WordPress Toolkit security settings. Which one, I do not know, as the final outcome was to revert or reset all the security settings and then enable 1 by 1 waiting to see which one failed, and none did!. Bah humbug.

    The outcome is then likely that somewhere in those settings, as I had copied the site manually into the public_html, had some setting that tied it back to the staging location, and ultimately crashed the theme. I expect that clearing the security settings (Revert) and re-enabling in one hit would have addressed the issue, but as with many things, we try incremental changes. If it happens again, I will try that first.

  • ClamAV Archive.Test.Agent2-9953724-0 False Positive

    Like many others we rely on multiple AntiVirus tools and one of them is the ubiquitous ClamAV on our Linux hosting servers. Earlier today we started being hammered with ClamAV notices of viruses being identified. Some research later and we are confident the ClamAV Archive.Test.Agent2-9953724-0 is a False Positive.

    (quarantined to /home/quarantine/cxsuser/client-account/backup_2022-06-25-0330_Clientaccount_f4f78444ae93-themes.zip.1656132445_1) ClamAV detected virus = [Archive.Test.Agent2-9953724-0]

    Various internet sources confirmed that ClamAV had indeed released an update signature file which included a ‘Test’ signature, namely ‘Archive.Test.Agent2-9953724-0’. A subsequent update, released within 24 hours addressed the false positive and, hopefully, prevents any future signature file from containing Test signatures. 

    # /usr/local/cpanel/3rdparty/bin/freshclam

ClamAV update process started at Sat Jun 25 15:09:55 2022
daily database available for update (local version: 26582, remote version: 26583)
Current database is 1 version behind.
Downloading database patch # 26583...
Testing database: '/usr/local/cpanel/3rdparty/share/clamav/tmp.73d24b3a72/clamav-52f6105711bb0d74294d4d1c535e77c0.tmp-daily.cld' ...
Database test passed.
daily.cld updated (version: 26583, sigs: 1987677, f-level: 90, builder: cmarczewski)
main.cld database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
bytecode.cld database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)

  • You do not have permission to access this document

    A Joomla site has been working fine but is now displaying an error when trying to save new content. The error displays as “You do not have permission to access this document.”

    It is an Apache Web Server error and not a Joomla error. Considering that Joomla has not changed it will be related to server changes or Apache updates.

    We had made a server change to address Apache Security Headers recently. Those changes were working ok with other sites and with the public view of this Joomla site.

    The .htaccess file for the Joomla website was the first thing to check. That revealed we had added some specific headers relating to those security headers back in 2021 to address an different issue.

    #Added 20211201 following Joomla recommendations after upgrade to 3.10.3
<FilesMatch "\.svg$">
  <IfModule mod_headers.c>
      Header always set Content-Security-Policy "script-src 'none'"
  </IfModule>
</FilesMatch>

<IfModule mod_headers.c>
    Header always set X-Content-Type-Options "nosniff"
</IfModule>

    In this case, the .htaccess site specific instructions clashed with the recently modified server instructions.
    Removing the .htaccess specific commands allowed the system to process the new Articles correctly.

    Conclusion

    If you have an error in Joomla “You do not have permission to access this document.” for your Joomla article, it is an Apache error.

    Check your .htaccess and your server configuration for potential Apache issues first.

    Need help with your Joomla or WordPress site? WrenMaxwell provides support and secure website hosting services. Contact Us at any time.

  • WordPress Another update is currently in progress

    Do you see in WordPress “Another update is currently in progress.” when you try to update the WordPress core? If so then you have probably checked all the other sites that advise you to delete a database entry, or use a plugin, or even use the wp-cli command to delete the database entry. In my recent research to resolve this, none of the sites I found actually provided any solution if that database entry does not exist.

    I did end up with a post at WordPress.org: update-wordpress-another-update-is-currently-in-progress-2 and noted that even there the suggested solution was “wp option delete core_updater.lock” which was redundant advice as the original poster of the issue had already stated that the database table (wp_options) did not include that record.

    In order to confirm this, I did install the wp command line utility from https://wp-cli.org/ and ran a couple of commands to check the current option for core_updater.lock, but as evidenced the wp-cli cannot find it either.

    wp option get core_updater.lock
    Error: Could not get 'core_updater.lock' option. Does it exist?

    At this point the short answer is that the wp_options table does not have the record to delete regardless of using a plugin, php-myadmin, or wp-cli. If it ain’t there it cannot be deleted, and yet we still have the issue of “Another update is currently in progress.”

    At this point I am still looking for a solution ( while it would be good to identify the issue, but a work-around will suffice) and have been testing or confirmed:

    • Specific to a site with 5.8.1 installed (I do not think this matters)
    • Trying to update to 5.9.3 (again I do not think it is a version issue)
    • Checked other WP sites on the same server – all ok – says that it is not a server config issue (i.e. its isolated to the site)
    • Ran all other updates for this site – plugins, themes etc. no issue. Only the core update fails / errors.
    • Tested swap of PHP (Multi-PHP Manager) version just to see if something triggered a clean-up – no change
    • Checked back on the dev site for the same live site and the dev site had automagically been updated to 5.9.3 obviously without an issue. Which comes down to some error within the live site only.
    • Finally drilled into a browser Inspect Console and discovered there were 403 errors on some scripts, like the wp-admin/loadstyles.php.

    A 403 Error Forbidden suggested it was htaccess or virtualhost related and probably not an issue with WordPress itself. I then confirmed file level permissions with default chmod and ownership with chown checked and re-applied just in case, but that made no difference.

    The end result was the Cpanel / WHM server the WordPress Toolkit was enabled for both the live and the dev sites. The two sites appeared to be configured identically but a cycle through each of the settings for security, disabling and re-enabling cleared the live site of whatever glitch / corruption was present.

    Summary: If you cannot find the core_updater.lock record then the error message is a fall-back error, or a red-herring to use an old-school term, and not accurate. What it is saying is “WordPress wants to run the update but something weird is happening and WordPress cannot write or read what it needs.”

    If I had this time over I would check in this order rather than what I did which was circuitous at best.

    1. WordPress Error “Another update is currently in progress” but no core_updater.lock
    2. Check in browser console (Inspect) to see if anything is giving errors

    WrenMaxwell provides fully managed hosting services for WordPress websites, business email, and domain names.

  • PowerDNS Error Not Starting

    This mornings issue of the day was, PowerDNS Error Not Starting on a Cpanel WHM server. 

    pdns has failed. Contact your system administrator if the service does not automagically recover.

    AlmaLinux is the Linux platform but that is not expected to be a factor in this.

    I could see errors in both the WHM web interface and at the command line. Slightly different text depending on which method, but the essence was the same. DNS is broken. 

    pdns_server[347366]: Error parsing bind configuration: Error in bind configuration '/etc/named.conf' on line xxxx : syntax error

    Checking further in the /var/log/messages with a filter to find pdns entries:

    #grep -n5 pdns /var/log/messages
    2120518:Mar 29 01:38:49 ns3 pdns_server[87833]: [webserver] Listening for HTTP requests on 127.0.0.1:953
2120519:Mar 29 01:38:49 ns3 pdns_server[87833]: Creating backend connection for TCP
2120520:Mar 29 01:38:49 ns3 pdns_server[87833]: Error parsing bind configuration: Error in bind configuration '/etc/named.conf' on line 1274: syntax error

    So the error is at a specific line and using my preferred Linux editor ‘mcedit’ (midnight commander editor “#yum install mc” will get it for you) I can see that the line is: 

    view "external" {

    Which looks to be ok, so the issue must be within the syntax and manifests at that line.

    Using named-checkconf to get an output:

    # named-checkconf named.conf
named.conf:1274: unknown option 'view'
named.conf:2485: unexpected token near end of file

    Of course, your line numbers will vary. However, the “unknown option ‘view’” is the one that we need to sort out, as ‘view’ is definitely a valid syntax option in named.conf.

    So why is it broken ?

    The syntax of the named.conf requires

    • a semi-colon ‘;’ to terminate each line or command
    • braces to open and close specific sections like { }

    In this specific case, for reasons unknown, the view command at line 65 was opened correctly:

    view "internal" {
    • view command is valid
    • “internal” is the view name
    • the opening brace { is correctly placed

    However when we get to lines 1270 and the last ‘zone’ element in the view section, the named.conf file failed to close the view segment with a closing brace and semi-colon, like ‘ }; ‘.

      ## end of last zone in the "internal" view section
}; //  this correctly closes the zone

}; // but this to close the "internal" view section is / was missing

view     "external" {

    So the named.conf file was trying to have a second ‘view’ segment opening before the previous one was closed and that is a syntax error for named.conf. You cannot nest or embed ‘views’.

    Ultimately a quick delete of named.conf and use of the cpanel rebuild script:

    # /usr/local/cpanel/scripts/rebuilddnsconfig

    fixed the problem. Noting that you must delete or rename the named.conf file first. If not then that rebuild script will run and silently not replace the named.conf with a working file. So your result is the same file, still not working.

    I did review a number of pages gathering ideas for fixing this including:

    As a bonus: named-checkconf can also accept an alternative filename so if you save multiple named.conf versions you can compare the output of errors or lack thereof. I used it when checking like this:

    [root@ns3 etc]# named-checkconf named.conf.rebuild-save-thowden
named.conf.rebuild-save-thowden:1274: unknown option 'view'
named.conf.rebuild-save-thowden:2485: unexpected token near end of file

    Use # named-checkconf -h to see a full list of options.

  • Cancel Prompt for htpasswd htaccess displays website

    Searching for a topic like “Cancel Prompt for htpasswd htaccess displays website” generally gives a lot of results with unrelated information and this one was not an exception. Plenty of instructions on ‘how to configure’ but relatively few on what to do if it fails.

    The cause of this dilemma was that a CPanel configuration for Directory Privacy was displaying the protected website home page if Cancel was selected 3 or more times when the htaccess password prompt was displayed.

    Directory Privacy, the CPanel interface option for configuring htaccess and htpasswd files for Apache websites, provides a ‘user friendly’ method to add specific user names and passwords to block public viewing of a website via a web browser.

    In this instance my search terms eventually led me to this explanation https://core.trac.wordpress.org/ticket/42120 which is credited to a number of others for the solution.

    To keep it simple, if you are experiencing a web page that is meant to be protected by .htaccess / .htpasswd, but it is being displayed if the Cancel option is selected at the password prompt, then check your .htaccess rule.

    1. Edit the .htaccess file in your home folder or website root (assumes that it is the whole site being protected)
    2. Find the line RewriteRule . /index.php [L]
    3. Replace with RewriteRule ./ /index.php [L]

    This worked in my case and as always your mileage may vary.

  • WordPress Booking Plugins

    We had a need to review WordPress Booking Plugins and we selected WP Booking Calendar.

    In the process we noted the following other plugins and made some quick notes on why they were rejected.

    In Alphabetical order the plugins we briefly tested were:

    Advanced Booking Calendar v1.5.4 https://booking-calendar-plugin.com/

    Appears ok, but needs some setting changes. Formatting / style might be an issue. Pricing and calculations are forced in the basic version and the paid version does not appear to provide any option for no price to be displayed. It also fails to provide booked vs unbooked dates as information to potential clients.

    AweBooking v3.0.7 https://awethemes.com/

    While the features list says it will be great, the actual interface is dreadful. Read the Documentation which only says install just like any other plugin. There is no further information. Create rooms, change settings, save settings, and still cannot create a booking, cannot see any availability calendar, no information on short-codes, etc. Read the reviews and you would not want to waste your time on this plugin.

    Pinpoint Booking System v2.7.8 http://www.dotonpaper.net/

    Requires registration with Pinpoint and perhaps purchase to get key features. It is built to be an automated booking system which is specifically not wanted. An error when trying to activate the plugin is not a good start. Tried several times and gave up. I think the path is missing a trailing / but I am not about to repair someone elses code.

    “Warning: sessionname(): Cannot change session name when session is active in /home/testsite/publichtml/wp-content/plugins/booking-system/framework/includes/class-session.php on line 129

    Warning: iniset(): Headers already sent. You cannot change the session module’s ini settings at this time in /home/testsite/publichtml/wp-content/plugins/booking-system/framework/includes/class-session.php on line 134″

    WooCommerce Accommodation Bookings v1.1.2 https://woocommerce.com/

    Cannot run without Woocommerce Bookings and that is a US$249 premium before you can test it. Did not proceed any further.

    WP Booking System v1.5 http://www.wpbookingsystem.com/

    This is an all-up purchase and an independent plugin, no subscription or connection to an external site. It is a ‘booking system’, a framework to roll-your-own booking solution. It seemed like a lot of work and effort to configure even a simple booking process, and the free version is limited to a single calendar, which makes testing of a dual calendar impossible. Granted we would only want 2 calendars, but layouts and formatting of a dual calendar is required. This plugin might be just the thing but roll-your-own means more time, more cost.

    WP Simple Booking Calendar v1.5.2 http://www.wpsimplebookingcalendar.com/

    This one possibly had more to offer, but I had already narrowed down a few features that I did not see in the list for this one, and I discounted it fairly early in the review.

    WPBooking v1.8.1 https://wpbooking.org/

    Reads like it is simple to use, but it is ‘accomodation’ with so many assumed conditions that it is restricted to suiting multi room hotel type accomodation. Trying to configure a ‘cottage’ BnB means all fields still need to be filled in for 1 Location, 1 Property, 1 Room Type, 1 Room, 1 Bedroom, etc… Instructions are inaccurate and cursory at best. Finding your way around is trial and error. The Quick Start assumes you are already familiar with this specific application.

    Summary

    There a lots and lots of options, (although I read a review that said there were not many options available but the ones reviewed were all for sale at the one market place provider, which stinks of commission sales attempts!).

    It could be that your choice of booking or event calendar needs features that I dismissed.

    The honorable mentions, because I will keep them in mind for future application are the WP Simple Booking Calendar from  http://www.wpsimplebookingcalendar.com/ and  WPBooking over at https://wpbooking.org/

    So while your mileage may vary, I would recommend you consider WP Booking Calendar from https://wpbookingcalendar.com/

     

  • Using WWW or your naked Domain Name

    Using WWW or your naked Domain Name is something that has been a hot topic for debate over a number of years.

    The literal or naked domain is the domain name that you probably use in your email address to the right of the @ symbol. Like wrenmaxwell.com.au

    Personally, I have always tried to use and recommend that default business web sites should have www. Using the domain name only just creates issues with Domain Name Service management, particularly when the website resides on a server separate from other services for the same domain, like email. This view is supported by this response to the question at ServerFault https://serverfault.com/questions/145777/what-s-the-point-in-having-www-in-a-url

    http://www.yes-www.org/why-use-www/ presents an excellent review of the main reasons and I will not repeat them here.

    Suffice to say,

    • YES, use www.yourdomain as your website URL
    • AND, make that your preferred address for Google / Bing webmaster tools
    • AND, redirect your naked domain so that end users who enter your domain name manually get redirected to www. This is important to ensure that you do not have duplicated content references to your pages.
    • AND, finally, get an SSL / TLS certificate installed so that you are using https:// for your website