Make WordPress Core

Opened 19 months ago

Closed 19 months ago

Last modified 18 months ago

#57325 closed defect (bug) (duplicate)

Fix the error 'Undefined array key' in 'wp-includes\class-requests.php' on line 214

Reported by: ilyachalov's profile ilyachalov Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch
Focuses: Cc:

Description

I work on the 'Windows 10' operating system. I am using the 'IIS 10' web server. I don't use solution stack packages like 'XAMPP', but install the necessary programs separately: PHP interpreter version 8.1.10, DBMS 'MySQL' version 8.0.30.

I install the latest version of the 'WordPress' (6.1.1) locally to study its operation on my computer in a directory C:\inetpub\wwwroot\wp\. After installation, the 'WordPress' web application will be available in the browser at the URL http://localhost/wp/ or https://localhost/wp/ (I am using a self-signed certificate).

I am adding full access to the 'DefaultAppPool' account (for me, this is the application pool of the 'IIS 10' web server through which the 'WordPress' web application runs) to the directory C:\inetpub\wwwroot\wp\ access control list (ACL), so that the 'WordPress' web application can create and modify files in this directory.

To configure the PHP interpreter, I used the 'php.ini-development' file obtained from the 'PHP For Windows' distribution (https://windows.php.net/download/). I copied the 'php.ini-development' file, renamed it to 'php.ini' and included PHP interpreter extensions for working with the 'MySQL' DBMS in it.

I didn't know that for the 'WordPress' web application to work, you need to enable the PHP interpreter extension to work with the 'OpenSSL' library, and therefore I didn't include it at first. When installing the 'WordPress' web application I was guided by the article How to install WordPress, article Before You Install and official requirement page. These three articles do not say that the 'WordPress' web application requires the 'OpenSSL' library and the inclusion of the PHP interpreter extension to work with this library.

Distribution 'wordpress-6.1.1.zip' I downloaded from the URL https://wordpress.org/download/ to my desktop.

Below I will outline two scenarios (cases) for reproducing the error.

Case 1.

Installing the 'WordPress' web application version 6.1.1 with the PHP interpreter extension NOT enabled to work with the OpenSSL library and trying to install a language pack for the Russian language.

1.1. Expand the archive 'wordpress-6.1.1.zip' on my desktop. By default, the 'wordpress' folder with files is expanded from it.

1.2. Rename the 'wordpress' folder on the desktop to the 'wp' folder. Move the 'wp' folder to the C:\inetpub\wwwroot\ folder (this requires computer administrator rights).

1.3. Add to the access control list for the folder C:\inetpub\wwwroot\wp\ element 'IIS AppPool\DefaultAppPool' with full access (used for this folder, its subfolders and files).

1.4. Check if the 'MySQL' DBMS server (mysqld.exe) is running. This can be done in the Task Manager (Ctrl+Shift+Esc) on the 'Processes' tab or the 'Details' tab. If the 'MySQL' DBMS server (mysqld.exe) is not running, then it should be started.

1.5. Create a database (for example, with the name 'wordpressdb'). For this I use the client C:\Program Files\MySQL\MySQL Server 8.0\bin\mysql.exe (you will need to enter the name of the database administrator (DBA) and his password) from the command line. Create a user (for example, with the name 'wordpressuser') and a password for it. Give the created user full access to the created database. Log out of the client. Something like this:

mysql> CREATE DATABASE wordpressdb;
mysql> CREATE USER "wordpressuser"@"localhost" IDENTIFIED BY "password";
mysql> GRANT ALL PRIVILEGES ON wordpressdb.* TO "wordpressuser"@"localhost";
mysql> FLUSH PRIVILEGES;
mysql> EXIT

1.6. Run the installation script http://localhost/wp/wp-admin/install.php from the browser.

1.7. A list of languages will appear. Select the item 'Русский' (Russian) from this list and click on the 'Продолжить' (Continue) button under the list of languages. After that we will receive an error message in the browser window:

PHP Warning: Undefined array key "a:1:{s:3:"ssl";b:1;}" in C:\inetpub\wwwroot\wp\wp-includes\class-requests.php on line 214

Case 2.

Installing the 'WordPress' web application version 6.1.1 with the PHP interpreter extension NOT enabled to work with the 'OpenSSL' library with the default language pack (for English).

(I deleted the 'wp' folder from C:\inetpub\wwwroot\ and deleted the database 'wordpressdb' (using the command DROP DATABASE wordpressdb;), remaining after case 1, to start again with a clean slate.)

2.1. Coincides with 1.1.
2.2. Coincides with 1.2.
2.3. Coincides with 1.3.
2.4. Coincides with 1.4.

2.5. Coincides with 1.5. I created the database 'wordpressdb' anew, and the user 'wordpressuser' remained after case 1, so I used it instead of creating a new one. Something like this:

mysql> CREATE DATABASE wordpressdb;
mysql> GRANT ALL PRIVILEGES ON wordpressdb.* TO "wordpressuser"@"localhost";
mysql> FLUSH PRIVILEGES;
mysql> EXIT

2.6. Coincides with 1.6.

2.7. A list of languages will appear, the item 'English (United States)' is already selected in it by default. Click on the 'Continue' button under the list of languages.

2.8. A screen opens with an explanation about the file 'wp-config.php'. Click on the "Let's go!" button.

2.9. A screen opens for entering information for the file 'wp-config.php'. Enter the database name (for example, 'wordpressdb'), the username (for example, 'wordpressuser') and the user password created in paragraph 2.5. Leave the default values for the fields 'Database Host' (localhost) and 'Table Prefix' (wp_). Click on the 'Submit' button.

2.10. The congratulation screen will open. Click on the 'Run the installation' button.

2.11. A screen will open for entering information about the site. Enter the site title (for example, 'My site title'), the site username (for example, 'ilyachalov'), the site user password, the site user's email, the "Search engine visibility" flag to leave unspecified. Click on the 'Install WordPress' button.

2.12. A screen will open with a message about the successful installation of the 'WordPress' web application. Click on the 'Log In' button.

2.13. The script http://localhost/wp/wp-login.php will start. Enter the site username and password created in paragraph 2.11. Click on the 'Log In' button.

2.14. The 'Dashboard' will open. In the menu on the left, select the item 'Tools', and inside it select the item 'Site Health'.

2.15. The 'Site Health' screen opens. On this screen, select the 'Info' tab. After that we will receive an error message in the browser window:

PHP Warning: Undefined array key "a:1:{s:3:"ssl";b:1;}" in C:\inetpub\wwwroot\wp\wp-includes\class-requests.php on line 214

Error fix

This error also appears in other situations, not only in the two described above.

If the PHP interpreter extension for working with the 'OpenSSL' library is enabled, then in the cases described above, the described error will not occur. (Library 'libssl-1_1-x64.dll' and PHP interpreter extension 'php_openssl.dll' are contained in the 'PHP For Windows' distribution.)

But I think that the above uncaught error needs to be caught, then the user of the 'WordPress' web application in the cases described above will not receive an incomprehensible error and his experience with the 'WordPress' web application will be more pleasant, without unnecessary stress. (The user learns about the need to enable the PHP interpreter extension to work with the 'OpenSSL' library from the 'Tools - Site Health' tool in the 'Dashboard' and after that will be able to enable it.)

I suggest the following fix in the script C:\inetpub\wwwroot\wp\wp-includes\class-requests.php in line 214.

Instead of (current version):

		if (self::$transport[$cap_string] === null) {

fix on:

		if (!isset(self::$transport[$cap_string])) {

The current version does not take into account the case when a key-value pair with a key from the $cap_string variable is not defined in the self::$transport array. Function isset track both cases: the absence of a key-value pair with the key $cap_string, and the case when the key $cap_string is defined, but the corresponding value is null.

I will attach a patch file to this ticket. I hope its format is suitable for the 'SVN' version control system. I will be creating a patch for the 'WordPress' web application for the first time, from the 'Git' program using the 'git diff' command from the command line. (Please let me know if the patch file format is incorrect, I will fix it.)

Attachments (1)

57325.diff (444 bytes) - added by ilyachalov 19 months ago.

Download all attachments as: .zip

Change History (6)

@ilyachalov
19 months ago

#1 @ilyachalov
19 months ago

  • Keywords has-patch added

#2 follow-up: @SergeyBiryukov
19 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Hi there, welcome to WordPress Trac! Thank you for the detailed bug report.

Please note that Requests is an external library and should not be patched directly in WordPress core, any suggested changes would need to be submitted to the upstream GitHub repository.

It looks like this code was already refactored in Requests 2.0.0, this commit fixes the issue as far as I can tell:

Add Requests::has_capability() which can be used to determine if SSL is available

See #54504 for updating the Requests library to the latest version.

#3 in reply to: ↑ 2 ; follow-up: @ilyachalov
18 months ago

Replying to SergeyBiryukov:

Thank you for the informative answer!

Before writing the ticket, I searched for tickets for this problem by setting the search string as 'class-requests.php ', but I didn't find any tickets in the search results concerning line 214 of this script.

Now I understand that you and other developers are going to update Requests library to version 2.0.0 (or to one of 2.0.1-2.0.5) as part of some future version of 'WordPress'. There the code is greatly changed and my correction of line 214 will be irrelevant.

My secondary goal when writing this ticket was to learn how to create a patch file from the 'Git' program (from the command line), such that it would be suitable for the 'SVN' version control system.

Could you tell me if my patch file for the 'SVN' version control system is suitable for the 'WordPress' project? The documentation says the opposite things about this: the article The Code Repository (Git) section Patches says that you can use the git diff command; and the article Submitting a Patch section Mac/Linux Command Line there is a link to the article svn patches from git which recommends using the command git diff --no-prefix.

Or is it better for me to contact the forum /chat with this question?

#4 in reply to: ↑ 3 ; follow-up: @SergeyBiryukov
18 months ago

Replying to ilyachalov:

My secondary goal when writing this ticket was to learn how to create a patch file from the 'Git' program (from the command line), such that it would be suitable for the 'SVN' version control system.

That's a great goal!

Could you tell me if my patch file for the 'SVN' version control system is suitable for the 'WordPress' project? The documentation says the opposite things about this: the article The Code Repository (Git) section Patches says that you can use the git diff command; and the article Submitting a Patch section Mac/Linux Command Line there is a link to the article svn patches from git which recommends using the command git diff --no-prefix.

git diff generates a file header with a/ and b/ prefixes:

diff --git a/src/readme.html b/src/readme.html
index 72bc2afe4b..30bf19acaa 100644
--- a/src/readme.html
+++ b/src/readme.html

git diff --no-prefix omits them:

diff --git src/readme.html src/readme.html
index 72bc2afe4b..30bf19acaa 100644
--- src/readme.html
+++ src/readme.html

I tried applying a patch with and without these prefixes using Subversion 1.14.2, and both were applied successfully, so this does not seem to make any difference in practice, and git diff appears to work as expected.

The "svn patches from git" article was written more than 10 years ago, so I suppose git diff --no-prefix was recommended at the time because of some compatibility issues that might not be relevant now.

Technically, 57325.diff is a perfectly valid patch that could have been accepted if it was not for an external library.

It is also possible to contribute code changes to WordPress core using GitHub Pull Requests. That makes it easier to review and collaborate on larger patches, as well as to see the results of automated tests right away. If your PR description includes a Trac ticket URL, it will be automatically linked to that ticket.

If you're interested in further contributing to core, the FAQ for New Contributors article might be helpful. I would also like to invite you to new core contributor meetings every 2nd and 4th Wednesday of the month at 19:00 UTC (an hour before weekly dev chat) in the #core channel on WordPress Slack, where you can ask any questions on contributing, working with patches, ask for a ticket review, next steps, etc. Welcome, and happy contributing! :)

Last edited 18 months ago by SergeyBiryukov (previous) (diff)

#5 in reply to: ↑ 4 @ilyachalov
18 months ago

Replying to SergeyBiryukov:

Thanks for your reply. I'll use the invitation if I can.

Note: See TracTickets for help on using tickets.