Fwd: [ANNOUNCE] PHP 8.1.11 Released

[Paul Smedley]

Hey guys,

OS/2 build at https://smedley.id.au/tmp/php-8.1.11-os2-debug-20220930.zip

Source code at https://github.com/psmedley/php-os2/tree/php-8.1

Cheers,

Paul


-------- Forwarded Message --------
Subject: [ANNOUNCE] PHP 8.1.11 Released
Date: Thu, 29 Sep 2022 11:30:57 -0500
From: Patrick ALLAERT <patrick...@php.net>
To: php-an...@lists.php.net

The PHP development team announces the immediate availability of PHP
8.1.11. This is a security release.

All PHP 8.1 users are encouraged to upgrade to this version.

For source downloads of PHP 8.1.11 please visit our downloads page. Windows
binaries can be found on the PHP for Windows site. The list of changes is
recorded in the ChangeLog.

Release Announcement: <https://php.net/releases/8_1_11>
Downloads: <https://php.net/downloads>
Windows downloads: <https://windows.php.net/download#php-8.1>
Changelog: <https://php.net/ChangeLog-8#8.1.11>
Release Manifest:
<https://gist.github.com/patrickallaert/56fc5a216173cb2dc61dcbb5a464dfb4>

Many thanks to all the contributors and supporters!

Patrick Allaert, Ben Ramsey & Joe Watkins

php-8.1.11.tar.bz2
SHA256 hash:
af6250b18b4403b6eeff9b4a02786ac86a12a208141f6f65478f79256f47f246
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmM0D00ACgkQGZ+d/vb/
uv3H2Q/6Ayd3kKlpe5rkkjOrEAo330bdw4x20kIcHiTHqZCmzn01+z4kPtq1ceR+
hCfvZyTxQHtTgRQkSPbnQ7Pdfv7bxRRT1a99lcpUfD+tZvIw+NWQerU2N7WketPB
WsQrZQDPRPnuzf3P3idH5+fFfKjpwX2BqV+72t4ps5aCihc/kRFYT9VRvyEUwWPo
oHkyohkEnRoMcSlTby8x2XadAEb4XDgEkS3t22DsXHiIuX3HRaeear9VfbP3yzoM
J0PS+qNd8TVJiyLkZvOXIaARiiZC6T3VNB4tMBYfbq0b+pVGJVr5CdVxldJOeHli
FK5wtIko+vmMC67IImayEsvUQL2WT8gJg9R1bbeKraGhGSb8Wl08wrecM5vqC9LG
G8Djn1qUsxgIRTHdI2lz4lSgNxaPriRbcN9EPzyBsZgBMU9akM7ZaQo2Kn1pJHqO
mph3aiaE7WM09agbNHefyJfQajI3OXV5X1XIEbK2HiVbBU8RsU8qOBGP5CNQfOK5
zzaCJJT1edk0unPEvW/KJ87NxuI8dg+zQDG71Vzcr8UaMK1FG21eF0KazeuZVzbQ
GRPNxZ4XBpDBSnBAThVNYbf5QdKu8TO66hNJ6pcdaC7Jvx4/+WTfX5MYZl9T5+RH
zAK2o02zjurlElsWPRogPxsQbe2sqcmMNi2Las3LCCxkPu7uDvM=
=EQwp
-----END PGP SIGNATURE-----

php-8.1.11.tar.gz
SHA256 hash:
3660e8408321149f5d382bb8eeb9ea7b12ea8dd7ea66069da33f6f7383750ab2
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmM0D00ACgkQGZ+d/vb/
uv0sgQ//ZXPpDUNFThSyoNV9ff5YsmdV+eyxgDydmRi77RxnD3KhZ+fxELss2q3u
4VIlsLqSK0OxujOKe3hlgkwO9aJ6ENQZa7HaDhHD/aLC6AtPjgpleUC3kNxUJOZw
7qkYCzyGO6UPkH4816hCSBEsKgBiX67JkZ0NLtS/AjSc1iuaVPInW8A0tJ0JkU5l
nbrIprhAvscH0P1sOiNSwcRvYDRhwCLVgniT/dbqj3aqP0EcYPg9tBa6a0ZEAe+2
w6Xm8SAZnDvs1xBbxzFSGNYGu/70D+kjfmZ5IZrpWT4MTDL6DIw0OPG6QlrLHpY+
SUQxJFhv8T/BtYCVThFD833/HX35kz5uiAy5ROyGV3mj8g7osxkM9yWMKyDcXfMj
P7257KUzBuFFlpTU5qusO8Ad/TjizkG5aHibOXBe1PKoo+dTQuUK9Ll0na9//XkI
CuIVBJrqoMyM8F7vpv5BTDXUYyS8TQddsg6vC+lDJqiGyCJMKnWiVwvnMdIsOfHG
xHcVFWtnSoQonpMwf9OL9aYQEZ3SPsbZ6DJng/13Nk4tsyqByf3jOK+fAsaDKjTO
wySSeZ0cfemUf9TKS2tzgehNAouchu+SJTKA1o4nms/uOaBCswWvIlw9uXfanPio
Djfff7hdH6J3ARX0DTKQNeBe6k2lKpGSWmShZlonrONrspFVv7I=
=fgQb
-----END PGP SIGNATURE-----

php-8.1.11.tar.xz
SHA256 hash:
3005198d7303f87ab31bc30695de76e8ad62783f806b6ab9744da59fe41cc5bd
PGP signature:
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmM0D00ACgkQGZ+d/vb/
uv26uBAAkdZmvHNMNh41rzURDLpId335z5A1M5V6mZjXr2xwB2noXs9cLqv0zgGe
KKMlwUZqWP0CoHEKai/NfkrIJSIKIKznB0HITEBHCkHGNRs5g3W/bMVHBb+n07tN
LyMWBeJ3Agz99lptQW4zJyMRi6hqAStiYwlpJutiiIgEtG9UEM8BI8fYLPyZs8Dj
Q9waCVucewcny13QYWk6DWHpBmzHSuRn0FTa3k2ULTfjGl+9XOPTWTGcjNehlBu8
9NGBxCfHH0G6rDTZPfDfEGDsU2qvqMxr8k+6gfb1mmzyze34a9Aqdlr9KW0pu51c
eDkJrEV1BTiweT2RBR6x0OkmnHB/Ns1UTcZ9yZVTFvF/ZPxnugcRFRAzoGzzWjar
CcY2ttJF0g9F4sG8Em3kds2DcUAYCimPG7tM3m66FnoteRPa58ZX5TbOBMpgypAD
RnGnDSRy//OglE1EG/bFLF4RPgJhPOn3a5n6prW0b2ugujt0+dfgalyGyZvFlaLH
2Dw6G8Cbf4VExDDxyAH950CYVBTovvnCkKduwFuHhFAcKlV2Mg+eVxkRZs3VAmUU
zwRphlnVCvKFbXIkC8qZ+vwJ/GnHonDhE9ozuMyWtlOIacqF6RyJnLo8Cll2j4js
/kpkejJXMnECezlCo0ktUnnsoljHT5aTewdrafLVgBpiifcOlZ8=
=WZBK
-----END PGP SIGNATURE-----


--
PHP Announcements Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Lewis G Rosenthal]

Hey, Paul...

On 09/29/22 06:37 pm, Paul Smedley wrote:
> Hey guys,
>
> OS/2 build at https://smedley.id.au/tmp/php-8.1.11-os2-debug-20220930.zip
>
> Source code at https://github.com/psmedley/php-os2/tree/php-8.1
>

8.1.11 seems to be as stable as 8.1.10.

I am having some major issues with WordPress 6.0.2, but I am not yet certain
how much may be WP-configuration-related. I can say that the issues are
identical for both PHP builds. More news when I figure out what's happening.

In brief, plugin updating stalls after the first one or two files are
extracted from the plugin's distribution zip. The admin page never finishes
refreshing, and nothing is logged to php.err (with E_ALL), so ATM, I'm still
floundering about to find where the script processing is giving up.

Anyway, thanks for the fresh build. More news when I have it.

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC www.2rosenthals.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------

[Paul Smedley]

Oops - replied to Lewis, not to the list...


-------- Forwarded Message --------
Subject: Re: [Apache/2] Fwd: [ANNOUNCE] PHP 8.1.11 Released
Date: Sat, 1 Oct 2022 17:41:11 +0930
From: Paul Smedley <pa...@smedley.id.au>
To: Lewis <lgros...@2rosenthals.com>

Hey guys,

On 1/10/22 16:44, Paul Smedley wrote:
> Hey Lewis,
>
> On 1/10/22 13:22, Lewis wrote:
>> Interestingly enough (I should have thought of this sooner), enabling
>> WP_DEBUG_LOG in wp-config.php got me some interesting DEPRECATED
>> statements. This is surprising as the deprecated code should be WP
>> 6.0.2 code, which is *supposed* to be compatible with PHP 8.1. A
>> couple particularly interesting lines include (mind the wrapping):
>
> <snip>
>
>> [01-Oct-2022 03:42:42 UTC] PHP Notice:  copy(): Write of 5459 bytes
>> failed with errno=22 Invalid argument in
>> J:\APPS\apache24\htdocs\website\wordpress\wp-admin\includes\class-wp-filesystem-direct.php on line 309
>
> If I had to guess, sounds like select() failing on a pipe() - I'll take
> a look this evening. Just got home from a trip down to the holiday house
> to do lawns and jobs, and of course, have lunch (delicious Indian)
> whilst we're down there, and have a walk on the beach with Miss Lexi.

ok... so that error comes from:

https://github.com/psmedley/php-os2/blob/php-8.1/main/streams/plain_wrapper.c#L373

Interesting....

Cheers,

Paul

[Paul Smedley]

Hey All,

Some more...

Downloading update from
https://downloads.wordpress.org/release/en_AU/wordpress-6.0.2.zip…

The authenticity of wordpress-6.0.2.zip could not be verified as
signature verification is unavailable on this system.

Unpacking the update…

source =
E:/web/wordpress/wp-content/upgrade/wordpress-6.0.2-HYMINm/wordpress/wp-admin/includes/update-core.php,
destination = E:/web/wordpress/wp-admin/includes/update-core.php, rtval = 0
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.

(NB: the line beginning with source =...) was debug added by me.)

The paths are good, and checking
E:/web/wordpress/wp-admin/includes/update-core.php the contents are
truncated - so something is borked with the PHP copy() command.

copy() appears to work fine for simple, small examples.

I can reproduce the error with a script like:
<?php
$file = 'roof.png';
$newfile = 'roof.png.bak';

if (!copy($file, $newfile)) {
echo "failed to copy $file...\n";
}
?>

Which results in: Notice: copy(): Write of 393810 bytes failed with
errno=22 Invalid argument in E:\web\copy.php on line 5
failed to copy roof.png...

where roof.png is an almost 400k png file - that should make things a
bit easier to debug :P

I've raised https://mantis.smedley.id.au/view.php?id=772 to capture this.

Tomorrow (Monday) is a holiday here, so I hope to be able to fix this
before the end of our long weekend.

Note; I also build sodium.dll, to try and fix the "The authenticity of
wordpress-6.0.2.zip could not be verified as signature verification is
unavailable on this system." but for my efforts, I get a SIGSEGV
starting apache with sodium.dll loaded - more on this later.

Cheers,

Paul

[Steven Levine]

In <f6c35152-8e20-b035...@smedley.id.au>, on 10/02/22
at 10:49 AM, Paul Smedley <pa...@smedley.id.au> said:

Hi all,

>Which results in: Notice: copy(): Write of 393810 bytes failed with
>errno=22 Invalid argument in E:\web\copy.php on line 5
>failed to copy roof.png...

>where roof.png is an almost 400k png file - that should make things a
>bit easier to debug :P

Agreed. This should be easy to walk through with the debugger. My
current suspect is a mmap problem because my read says we get here:

main\streams\streams.c:1540
PHPAPI int _php_stream_copy_to_stream_ex(php_stream *src, php_stream
*dest, size_t maxlen, size_t *len STREAMS_DC)

Assuming I am reading the code right, the php copy implementation is at:

ext\standard\file.c:1624
PHP_FUNCTION(copy)


Steven

--
----------------------------------------------------------------------
"Steven Levine" <ste...@earthlink.net> Warp/DIY/BlueLion etc.
www.scoug.com www.arcanoae.com www.warpcave.com
----------------------------------------------------------------------

[Paul Smedley]

Hi Steven,

On 2/10/22 12:00, Steven Levine wrote:
> In <f6c35152-8e20-b035...@smedley.id.au>, on 10/02/22
> at 10:49 AM, Paul Smedley <pa...@smedley.id.au> said:
>
> Hi all,
>
>> Which results in: Notice: copy(): Write of 393810 bytes failed with
>> errno=22 Invalid argument in E:\web\copy.php on line 5
>> failed to copy roof.png...
>
>> where roof.png is an almost 400k png file - that should make things a
>> bit easier to debug :P
>
> Agreed. This should be easy to walk through with the debugger. My
> current suspect is a mmap problem because my read says we get here:
>
> main\streams\streams.c:1540
> PHPAPI int _php_stream_copy_to_stream_ex(php_stream *src, php_stream
> *dest, size_t maxlen, size_t *len STREAMS_DC)

Thanks, I hadn't got quite this far yet, before going for a walk.

On a whim, I rebuilt libcx with the latest commit
(https://github.com/bitwiseworks/libcx/commit/b2819ac4c9bce2c4ed64f251cbd113f768e0bb90)
but it didn't help (not surprising given the description).

> Assuming I am reading the code right, the php copy implementation is at:
>
> ext\standard\file.c:1624
> PHP_FUNCTION(copy)

Yeah that's where I got to as well.

Interestingly, PHP5 and PHP7 appear to show the same defect. PHP7
doesn't surprise me, as that's when mmap use increased, but PHP5 barely
used mmap...

Cheers,

Paul

[Steven Levine]

In <f6c35152-8e20-b035...@smedley.id.au>, on 10/02/22
at 10:49 AM, Paul Smedley <pa...@smedley.id.au> said:

Hi all,

>where roof.png is an almost 400k png file - that should make things a
>bit easier to debug :P

I had a bit of time so I used it as an opportunity to update the php
install to 8.1.11 and crank up the debugger.

It is, as I suspected, a memory mapped file issue. The failure is
reported at:

main\streams\streams.c:1134
ssize_t justwrote = stream->ops->write(stream, buf, count);

because buf is not committed and this results in the errno 22 when the
DosWrite fails and returns error 87. I've not been in the memory mapped
file IO code for a bit, but IIRC the libcx exception handler triggers the
required DosRead when the uncommitted memory mapped buffer is accessed.
This access must be done a ring3 time, not while the DosWrite is
attempting to access the buffer from ring0.

This is variant of an issue we fixed in the past. Recall that we needed
to implement a touch_pages routine so that recv() had a committed buffer
to read into because the libcx exception handler can not get control when
ring0 code is running.

In this case, we need a access_pages routine that is invoked before

stream->ops->write(stream, buf, count)

is called. The read should trigger the libcx exception hander commit the
buffer and to invoke DosRead to fill the buffer.

access_pages will be something like:

static inline void __attribute__((optimize("O0"))) access_pages(char* buf,
int bufbytes) {
char *p = buf;
int cnt = 0;
int touched;
for (; cnt < bufbytes; p += touched, cnt += touched) {
*p;
touched = 4096 - ((unsigned int)p & 0xfff);
}
}

The __attribute should ensure that the compiler does not optiimize this
code away because it appears to do nothing.

[Paul Smedley]

Hey Steven,

Thanks for the analysis - we've just finished a bottle of
https://bechardy.com.au/products/bec-hardy-village-green-shiraz-2021, so
I'll wait until the effects of that to wear off before I look into this
more :)

Cheers,

Paul

[Steven Levine]

In <6340e2c7-bc85-38c7...@smedley.id.au>, on 10/02/22
at 02:26 PM, Paul Smedley <pa...@smedley.id.au> said:

Hi Paul,

>Thanks, I hadn't got quite this far yet, before going for a walk.

:-)

Let's see if using access_pages() is sufficient to fix it.

>Interestingly, PHP5 and PHP7 appear to show the same defect. PHP7
>doesn't surprise me, as that's when mmap use increased, but PHP5 barely
>used mmap...

5.6.40 does:

main\streams\streams.c:1529
if (php_stream_mmap_possible(src)) {

so I guess this one of those barely cases. :-)

[Steven Levine]

In <6340e2c7-bc85-38c7...@smedley.id.au>, on 10/02/22

at 02:26 PM, Paul Smedley <pa...@smedley.id.au> said:

Hi Paul,

FYI, the libcx code that does to DosRead in response to the exception is
at:

src\mmap\mmap.c:1819
ULONG read = PAGE_SIZE;
LONGLONG pos = m->f->fmem->off + page_addr -
m->f->fmem->start;
TRACE("Reading %lu bytes to addr %lx from fd %ld at offset
%llx\n",
read, page_addr, m->f->fh->fd, pos);
arc = DosSetFilePtrL(m->f->fh->fd, pos, FILE_BEGIN, &pos);
TRACE_IF(arc, "DosSetFilePtrL = %ld\n", arc);
if (!arc)
{
/* Page is committed, so calling original DosRead is safe.
*/
arc = _doscalls_DosRead(m->f->fh->fd, (PVOID)page_addr,
read, &read);
TRACE_IF(arc, "DosRead = %ld\n", arc);
}

As we can see the read is for a single page. The exception handler does
not know how many bytes the application is attempting to access so there's
no way for it to know if it would be better to read muliple pages in
response to the exception.

[Steven Levine]

In <c3ac2130-bb6b-862b...@smedley.id.au>, on 10/02/22
at 03:22 PM, Paul Smedley <pa...@smedley.id.au> said:

Hi,

>Thanks for the analysis - we've just finished a bottle of
>https://bechardy.com.au/products/bec-hardy-village-green-shiraz-2021, so

And here I thought this kind of liquid refreshment would free up your
thinking. :-)

[Paul Smedley]

Hey Steven!

On 2/10/22 15:48, Steven Levine wrote:
> In <c3ac2130-bb6b-862b...@smedley.id.au>, on 10/02/22
> at 03:22 PM, Paul Smedley <pa...@smedley.id.au> said:
>
> Hi,
>
>> Thanks for the analysis - we've just finished a bottle of
>> https://bechardy.com.au/products/bec-hardy-village-green-shiraz-2021, so
>
> And here I thought this kind of liquid refreshment would free up your
> thinking. :-)

It does - to a point :)

I built https://smedley.id.au/tmp/php-8.1-dll-20221002.zip using the
diff at https://smedley.id.au/tmp/php.diff

It still fails in the same way. More in a bit...

Cheers,

Paul

[Paul Smedley]

Hey Steven,

On 2/10/22 14:46, Steven Levine wrote:

> In this case, we need a access_pages routine that is invoked before
>
> stream->ops->write(stream, buf, count)
>
> is called. The read should trigger the libcx exception hander commit the
> buffer and to invoke DosRead to fill the buffer.
>
> access_pages will be something like:
>
> static inline void __attribute__((optimize("O0"))) access_pages(char* buf,
> int bufbytes) {
> char *p = buf;
> int cnt = 0;
> int touched;
> for (; cnt < bufbytes; p += touched, cnt += touched) {
> *p;
> touched = 4096 - ((unsigned int)p & 0xfff);
> }
> }

Any reason for *p; vs *p = 0; in the equivalent touch_pages()?

With *p = 0 - I get further - but now get a SIGSEGV...

New dll at https://smedley.id.au/tmp/php-8.1-dll-20221002b.zip

Cheers,

Paul

[Steven Levine]

In <050dd727-1921-0421...@smedley.id.au>, on 10/02/22

at 05:42 PM, Paul Smedley <pa...@smedley.id.au> said:

Hi,

>Any reason for *p; vs *p = 0; in the equivalent touch_pages()?

Yes. There reason for the functions differ. Touch_pages exists to ensure
the buffers are writable when recv() tries to write to them. Access_pages
exists to ensure that the data is read from the when memory is read. The
attempt to access the uncommitted memory will trigger a DosRead in the
exception handler.

>With *p = 0 - I get further - but now get a SIGSEGV...

Sorta expected. libcx is expecting a read access exception, not a write
access exception.

The reason access_pages() did not work is because the compiler dropped the
*p, even though we tried to tell it not to do this. Try the attached.
This might be good enough to make the compiler do what we want it too.

When access_pages is called EDI happens to point to the buffer. If you
display the storage pointed to be EDI, before the call it will display as
?'s. After the call, the storage should display the contents of the file.

[Paul Smedley]

Hey Steven,

On 2/10/22 18:02, Steven Levine wrote:
> In <050dd727-1921-0421...@smedley.id.au>, on 10/02/22
> at 05:42 PM, Paul Smedley <pa...@smedley.id.au> said:
>
> Hi,
>
>> Any reason for *p; vs *p = 0; in the equivalent touch_pages()?
>
> Yes. There reason for the functions differ. Touch_pages exists to ensure
> the buffers are writable when recv() tries to write to them. Access_pages
> exists to ensure that the data is read from the when memory is read. The
> attempt to access the uncommitted memory will trigger a DosRead in the
> exception handler.
>
>> With *p = 0 - I get further - but now get a SIGSEGV...
>
> Sorta expected. libcx is expecting a read access exception, not a write
> access exception.
>
> The reason access_pages() did not work is because the compiler dropped the
> *p, even though we tried to tell it not to do this. Try the attached.
> This might be good enough to make the compiler do what we want it too.
>
> When access_pages is called EDI happens to point to the buffer. If you
> display the storage pointed to be EDI, before the call it will display as
> ?'s. After the call, the storage should display the contents of the file.

This one seems to work :) for the testcase at least

https://smedley.id.au/tmp/php-8.1-dll-20221002c.zip

Thanks again!

Cheers,

Paul

[Paul Smedley]

Hey Guys,

Full rebuilds:
PHP 7.4.32: https://smedley.id.au/tmp/php-7.4.32-os2-debug-20221002.zip
PHP 8.1.11: https://smedley.id.au/tmp/php-8.1.11-os2-debug-20221002.zip

Cheers,

Paul

[Massimo S.]

thanks

just installed
it's just me, or this build has some performance improvement/fix?

massimo

[Paul Smedley]

Hey Max,

The *only* change from the previous 7.4.32 build is
https://github.com/psmedley/php-os2/commit/d9c9a049ecd9da424e9a510a88e464db2730fa08

Cheers,

Paul

[Steven Levine]

In <9cf98d96-295f-0e7d...@ecomstation.it>, on 10/03/22
at 12:14 AM, "Massimo S." <m...@ecomstation.it> said:

Hi Massimo,

>just installed
>it's just me, or this build has some performance improvement/fix?

I can't think of any specific reason for a noticable bump in performance.
Paul may have switched to building with a new gcc version. This often
results in better optimized code.

The defect that this build fixes does not apply to you because none of
your php code is using the php copy() function.

[Paul Smedley]

Hey Guys

On 3/10/22 11:12, Steven Levine wrote:
> In <9cf98d96-295f-0e7d...@ecomstation.it>, on 10/03/22
> at 12:14 AM, "Massimo S." <m...@ecomstation.it> said:
>
>> just installed
>> it's just me, or this build has some performance improvement/fix?
>
> I can't think of any specific reason for a noticable bump in performance.
> Paul may have switched to building with a new gcc version. This often
> results in better optimized code.

Nope, I've been using GCC 12.x for a while now....

Cheers,

Paul

[Lewis G Rosenthal]

Hi, Paul...

On 10/02/22 04:16 am, Paul Smedley wrote:
> Hey Guys,
>

<snip>

> Full rebuilds:
> PHP 7.4.32: https://smedley.id.au/tmp/php-7.4.32-os2-debug-20221002.zip
> PHP 8.1.11: https://smedley.id.au/tmp/php-8.1.11-os2-debug-20221002.zip
>

Confirmed that plugin updates are now working with WordPress 6.0.2 under PHP
8.1.11. Thanks!

[Lewis G Rosenthal]

On 10/02/22 09:53 pm, Lewis G Rosenthal wrote:
> Hi, Paul...
>
> On 10/02/22 04:16 am, Paul Smedley wrote:
>> Hey Guys,
>>
>
> <snip>
>
>> Full rebuilds:
>> PHP 7.4.32: https://smedley.id.au/tmp/php-7.4.32-os2-debug-20221002.zip
>> PHP 8.1.11: https://smedley.id.au/tmp/php-8.1.11-os2-debug-20221002.zip
>>
>
> Confirmed that plugin updates are now working with WordPress 6.0.2 under
> PHP 8.1.11. Thanks!
>

...however, multiple plugin updates stop after the first one...

IOW, I have 13 plugins in need of updates. If I select all of them, only the
first one in the list is processed. It might be a browser issue;
checking...doubtful (Dooble is able to "select all" - unlike SeaMonkey,
where I had to individually select them - but the result is the same: first
one is updated, the rest are not).

I'm not seeing anything useful in the WordPress debug log (lots of
deprecation notices, but nothing fatal even in the deprecated bits which
would lead me to believe that there was a failure of the WP code; generally,
these are all empty string handling issues which changed after PHP 5.x).

[Paul Smedley]

Hey Lewis,

On 3/10/22 12:43, Lewis G Rosenthal wrote:
> On 10/02/22 09:53 pm, Lewis G Rosenthal wrote:
>> Hi, Paul...
>>
>> On 10/02/22 04:16 am, Paul Smedley wrote:
>>> Hey Guys,
>>>
>>
>> <snip>
>>
>>> Full rebuilds:
>>> PHP 7.4.32: https://smedley.id.au/tmp/php-7.4.32-os2-debug-20221002.zip
>>> PHP 8.1.11: https://smedley.id.au/tmp/php-8.1.11-os2-debug-20221002.zip
>>>
>>
>> Confirmed that plugin updates are now working with WordPress 6.0.2
>> under PHP 8.1.11. Thanks!
>>
>
> ...however, multiple plugin updates stop after the first one...
>
> IOW, I have 13 plugins in need of updates. If I select all of them, only
> the first one in the list is processed. It might be a browser issue;
> checking...doubtful (Dooble is able to "select all" - unlike SeaMonkey,
> where I had to individually select them - but the result is the same:
> first one is updated, the rest are not).
>
> I'm not seeing anything useful in the WordPress debug log (lots of
> deprecation notices, but nothing fatal even in the deprecated bits which
> would lead me to believe that there was a failure of the WP code;
> generally, these are all empty string handling issues which changed
> after PHP 5.x).

I don't have enough plugins installed locally to reproduce this right
now, but I am seeing issues with installing plugins...

Plugins like 'Akismet Spam Protection' give an 'Installation Failed'
error....

phperror log shows:
[03-Oct-2022 02:53:52 UTC] PHP Warning:
require_once(E:\web\wordpress\wp-content\plugins\akismet/class.akismet.php):
Failed to open stream: Bad file number in
E:\web\wordpress\wp-content\plugins\akismet\akismet.php on line 50
[03-Oct-2022 02:53:52 UTC] PHP Fatal error: Uncaught Error: Failed
opening required
'E:\web\wordpress\wp-content\plugins\akismet/class.akismet.php'
(include_path='.;e:/internet/php8/include;e:/internet/php8/pear') in
E:\web\wordpress\wp-content\plugins\akismet\akismet.php:50
Stack trace:
#0 E:\web\wordpress\wp-admin\includes\plugin.php(2313): include_once()
#1 E:\web\wordpress\wp-admin\plugins.php(192):
plugin_sandbox_scrape('akismet/akismet...')
#2 {main}

So something still isn't quite right with streams support...

[Lewis G Rosenthal]

I wonder why I didn't see this in the log? Maybe I didn't update Akismet...
WooCommerce seems utterly broken (as in the entire site refuses to render
beyond a "fatal error occurred" WP page); could be a partial download. Hard
to tell.

Meanwhile, I'll hold up further testing until you have something to add -
unless I can come up with a better testcase.

[Paul Smedley]

Hey Lewis,

Installing via a .zip also fails - but differently <uggh> one step
forwards...

I'll investigate as time permits..

Cheers,

Paul

[Paul Smedley]

Hey guys,

OK....

One clue in the above was the displayed path... ie
E:\web\wordpress\wp-content\plugins\akismet/class.akismet.php and the
mix of \ and /. My 'guess' was that something was escaping the \ and
resulting in a borked path - and hence the 'Bad file number' error.

It seems changing DEFAULT_SLASH per
https://github.com/psmedley/php-os2/commit/c7d389da164ca6d8099525b2b3489ff1e6fb1afe
improves the situation.

New build at https://smedley.id.au/tmp/php-8.1.11-os2-debug-20221003.zip

I can now install the individual plugins that were failing this morning.

Cheers,

Paul

[Paul Smedley]

...and once more...

Confirming that installing from a local .zip now works too.

Cheers,

Paul

[Lewis G Rosenthal]

Thanks. I'll re-test and will advise.