Installed the extension XMLReader on FastCgi version PHP 7.4/8.0 of CoreServer (V1) and made the WordPress hpb Dashboard plugin available

update Last updated: February 21, 2023 at 1:05 PM

The WordPress dashboard plugin (hpb Dashboard) for the website builder (hpb) provided by JustSystems requires the PHP "XMLReader" extension module.
If you select the hpb dashboard on a server that does not have XMLReader installed, you will get a fatal error.
Since this module can only be used in PHP 7.1 on the core server (V1), it was unavoidable to operate with PHP 7.1 until now.

However, PHP 7.1 has reached the end of security support, and the current recommended specs for WordPress (version 5.7.2 at the time of writing) are PHP 7.4 or higher.
The following screens are notifications from WordPress site health and plugin BackWPup.
In site health, as a fatal problem, BackWPup has an alert that support for PHP less than 7.2 will be discontinued. Specifically, the threatening language is:

Therefore, this time, build the latest version of PHP7 "PHP7.4.20" with reference to Skinerv's blog written at the link below, and apply the module of XMLReader (+ XMLWriter) to FastCgi version PHP 7.4 of CoreServer (V1) So I decided to upgrade my server environment.

A big thank you to Skinerv!
In addition, the option to upgrade the core server to V2 and operate it in PHP 7.4 may be the best, but since the V1 contract is still a little less than a year old, I would like to operate it in V1 for the time being.

1.PHP 7.4 Compatibility Check

Before upgrading the PHP version, first back up your WordPress system.
Next, check if your theme and all plugins are compatible with PHP 7.4.
This time, I used the WordPress plugin "PHP Compatibility Checker", but unfortunately this plugin can only check up to PHP 7.3.
However, if it works in the environment of PHP 7.3, it is probably possible to work with PHP 7.4, so I will try it for the time being. If there is a problem, you can fix the program or replace or remove the plug-in.
As described in the following screen, there is a warn in some plug-ins, but there is no fatal error, so there seems to be no problem in particular. However, it is not possible to check the operation at runtime, so be careful.

2.PHP Download and build 7.4

On the core server, in order to add an extension module with user privileges to a running PHP 7.4 (FastCgi version), it seems to be possible to do it by the following method.

  • Compile from the PHP 7.4 source by executing the Make command, build the PHP system in a different directory from the PHP installed as standard, and incorporate the extension module into the running PHP 7.4.

It is a somewhat irregular method, but it seems to work without problems at the moment.
From then on, until Chapter 3, it will be a quote of the content written in Mr. Skinerv's blog.

*Note: The following methods are not supported by CoreServer, so we cannot take any responsibility. Please do so at your own risk. Replace USERNAME with your account name.

first check the latest build of PHP 7.4 at the following site

At the time of writing (June 12, 2021), it has been confirmed that "PHP 7.4.20" is distributed as the latest version of PHP 7.4.

Tera Term , SSH to the core server and execute the following Linux commands (Bash) in order.
Regarding the execution of the configure script file described below, the option “–with-zip=shared –with-gmp=shared” can be omitted if not necessary.

mkdir php_selfbuild
cd php_selfbuild
tar zxvf *
rm *.gz
cd php-7.4.20
./configure --enable-xmlreader=shared --enable-xmlwriter=shared --with-zip=shared --with-gmp=shared

If make succeeds, the following screen will be displayed on Tera Term.
The second screen is the same image as the eye-catch, but it shows the generated directory to make sure that the PHP 7.4 build is done properly.

3.PHP Applying Modules

Add the following two public_html /virtual/USERNAME/public_html/.fast-cgi-bin/php74.ini
* From FTP, public_html ⇒ .fast-cgi-bin ⇒ php74.ini

In Mr. Skinerv's blog, 2 extension modules and are added, and a total of 4 lines are added. I will.


Php OPcache (Zend OPcache) seems not to be set properly, so tune the settings.

Edit /virtual/USERNAME/public_html/.fast-cgi-bin/php74.ini as follows:

1) Delete the line starting with opcache

2) Add:


《 Change the maximum memory value consumed by the script 》

Although it is not directly related to this installation, just in case, change the default 500M to 2GB.
By the way, according to the specifications of the core server (V1), the maximum memory is 384GB, and Skinerv confirmed with the support of the core server that the recommended value is 2GB.
It should be possible to define "2G" in the description below, but the Transposh plug-in displayed a memory value definition warning, so the unit is set to M (mega).

memory_limit = 2048M    ; Maximum amount of memory a script may consume (8MB)

4. Apply PHP 7.4 to CoreServer

Log in to the core server management screen and apply php74 from the site list.

5. Check operation

You can check that XMLReader and XMLWriter are enabled in the phpinfo function. The following screen is displayed by the php program (phpinfo.php) for displaying phpinfo.*

* phpinfo.php writes:


As you can see below, the hpb dashboard now opens successfully in the PHP 7.4 environment.

The following is the site health screen after applying PHP 7.4, but it is pointed out that the recommended module imagick of WordPress is not installed. PHP 7.1 has imagick installed, but unfortunately PHP 7.4 on the core server (V1) does not have the extension installed.

However, since the PHP 7.4 package has the GD module installed as standard, WordPress can run without imagick.
With imagick, it seems that you can generate thumbnails from PDF files and achieve more advanced image processing, but I don't think it's really necessary for this site. Therefore, we will ignore this warning.
In addition, imagick's installation is quite troublesome and there are also security vulnerabilities, so I would like to suspend support for imagick for the time being.

For reference, phpinfo shows the configuration of the GD module in PHP 7.4 below.

2021.06.16 Added

About PHP 8.0

In this chapter, as an experiment, I built the latest version of PHP 8.0 with the following Linux command in the same way as for PHP 7.4.
The extension module includes the xmlreader and xmlwriter.

cd php_selfbuild
tar zxvf php-8.0.7.tar.gz
rm *.gz
cd php-8.0.7
./configure --enable-xmlreader=shared --enable-xmlwriter=shared

Also, to apply the PHP module,
Added the following two public_html /virtual/USERNAME/public_html/.fast-cgi-bin/php80.ini


With the above settings, when PHP 8.0 was applied in the site settings of the core server and the website was accessed, "A serious error occurred on the site" was displayed, so it seems that it does not work obediently with PHP 8.0.
I haven't checked the logs yet, so I don't know the exact cause, but I think it's either that the theme or plugin is incompatible with PHP 8.0, or that the extension specification is incorrect.
In any case, the transition from PHP 7.4 to PHP 8.0 seems to be quite a hurdle as there are too many incompatibilities, as shown in the linked article below.

Later, when I checked the logs in WordPress debug mode, I found that the plugin was getting an error. You're probably fine with the PHP 8.0 extension.
The plug-ins causing the error are as follows:

  • custom-more-link-complete … removed the plugin as it is not working in WordPress 5.7.2
  • transposh-translation-filter-for-wordpress ... Author to support PHP 8.0
  • invisible-recaptcha ... Removed the plug-in and replaced it with "reCaptcha by BestWebSoft" because it was not maintained and seemed to be functioning properly
  • wp-database-backup … the restore function is incomplete. I also have BackWPup and removed the plugin as I don't need it
  • PHP Compatibility Checker ... Removed because incompatibilities with PH P8.0 have been pointed out.

2021.06.21 Added
I reported a Jetpack bug to the following WordPress forums:
The main glitch is that even with Jetpack's site accelerator enabled, the CDN doesn't work and images don't display.
Probably, the cause is that the IP address sent and received from Automattic is restricted by the security control of the core server.
It seems that core server access restrictions are automatically performed, so it is difficult to solve the problem fundamentally, and it seems impossible to use all the functions of Jetpack in the core server.

The following is an answer from Core Server Support:

Thank you for your continued patronage of our services.
We will inform you about the inquiry.

When I confirmed it with our department, some IP addresses were rejected on the server side of our company within the IP address range of "" contacted and connection restrictions were implemented.

The above restrictions have been lifted by the department in charge.

However, we have a security mechanism that automatically rejects the source IP address that is causing the high load on the server.

Therefore, we may refuse to connect from the target IP address again, but please understand that we can not stop implementing the above restrictions for security reasons.

If you have any other questions, please feel free to contact us.
We look forward to your continued service in the future.
Thank you for your continued patronage of our services.
We will inform you about the inquiry.

Customer Support Questionnaire - Value Domain -

2021.06.24 Update
Yesterday, the following contact was made by the hosting company, Bear Server, as follows:

As for the measures taken by our company this time, we have lifted all restrictions based on IP addresses, such as restrictions on connection source IP addresses for behaviors that are suspected of brute force attacks against WordPress.

Customer Support Questionnaire - Value Domain -

Therefore, I checked the operation of Jetpack.
As a result, we have confirmed that the following bugs have been resolved for the core server:

  1. "Status 400" error when turning on/off Jetpack extension module
  2. Site Accelerator (CDN) not working
  3. In addition, when checking Jetpack's "Known Issues‎" as shown below, it was found that "Google Captcha (reCAPTCHA) by BestWebSoft" corresponds to this website.

2022.05.02 Update
As described in the following article, CORESERVER V1 will be upgraded and migrated to a server with new specifications. For the new server, "the latest system for all plans, high-speed CPU with up to 64 cores, large-capacity memory with up to 1TB, high-speed SSD RAID" will be adopted to enable higher speed and stable operation. At the same time, the PHP version will be upgraded from 7.1 to 7.4.

Therefore, after migration to the new server, if you are using PHP 7.4, you will no longer need to install the PHP "XMLReader" extension yourself.

2022.06.06 Update / 6.30 Update
As shown in the article below, due to the migration of the core server (V1) to a new server, incompatibility occurred in Perl 5.26 and an old CGI program caused an error.
The extension modules XMLReader, XMLWriter, imagick, etc. were installed on the new server.

Add this entry to the hasebookmark
X (post)

Leave a Reply