[skip-revcheck] Remove empty xi:fallback elements

[lacatoire]

Removes empty <xi:fallback/> across doc-en, turning
<xi:include ...><xi:fallback/></xi:include> into <xi:include .../>.

An empty fallback replaces a failed XInclude with nothing, hiding the failure
from the reporting configure.php already gives.

The two <xi:fallback> inside example CDATA (dom xinclude /
getElementsByTagNameNS) are kept, they document the feature itself.

Related:

• imagick: fix broken methodsynopsis xpointers in exception classes #5700 fixes the broken Imagick xpointers this removal exposed
• configure.php: recover failed XIncludes inside classsynopsis doc-base#326 lets such failures be recovered instead of hard-failing

[skip-revcheck]: no translated content affected.

[alfsb]

This is very impressive. And also very tasteful (the /> thing).

This was generated by script? If so, then can  you publish it somewhere, or can provide a patch file for translations, after this is merged? doc-base/languages.php is an easy way to generate a fresh clone of all languages in a new dir, for experiments.

As <xi:fallback> now causes more problems that it solves, I plan to merge this somewhat fest, by next monday at most, to avoid conflict to creep in. I will do a heads up on Discord, and also reserve some time to do a full testing for XML or revcheck differences. This will be a good testing bed for consecutive skip-revcheck code.

[alfsb]

Wow. You even found the xi:fallbacks with inline bodies. Nice!

[jordikroon]

I scanned through randomly and don't see anything weird. Also assuming the build will fail if something is wrong so I trust this is alright.

[alfsb]

I scanned through randomly and don't see anything weird. Also assuming the build will fail if something is wrong so I trust this is alright.

GH CI cannot be really trusted for this, as it does not consider posterior changes on main/master. So an ok result on CI can (and frequently is) completely broken after merge.

[alfsb]

I scanned through randomly and don't see anything weird. Also assuming the build will fail if something is wrong so I trust this is alright.

GH CI cannot be really trusted for this, as it does not consider posterior changes on main/master. So an ok result on CI can (and frequently is) completely broken after merge.

See, for example, on tests of this PR: https://github.com/php/doc-en/actions/runs/29993851297/job/89162721067?pr=5699

In "Checkout php/doc-en" step, we can see

HEAD is now at 4ff27bc Merge 6f4e802c5fd1e8c698e7836da8b88882947b00bf into e1b9f588815a51682acf68f9b8929f49ad612488

Note that e1b9 is NOT the head of doc-en, which now sits at 07b2, after e1b9.

In "Build documentation for en" we can see that doc-en is in 4ff2, a merge hash yes, but a merge hash into the past of doc-en.

doc-base: 9391318e46e6fdd09721a9f5e3553089e4382009
en:       4ff27bc6fb5413930ea05d1348f6de1067c808a7

I suspect the null in pull_request: null may have something to it, as it does not show in any GitHub examples.

I did not re-run the tests, to see if it changes anything. If anyone re-runs, and the hashes change, please comment.

[alfsb]

I scanned through randomly and don't see anything weird. Also assuming the build will fail if something is wrong so I trust this is alright.

GH CI cannot be really trusted for this, as it does not consider posterior changes on main/master. So an ok result on CI can (and frequently is) completely broken after merge.

See, for example, on tests of this PR: https://github.com/php/doc-en/actions/runs/29993851297/job/89162721067?pr=5699

In "Checkout php/doc-en" step, we can see

HEAD is now at 4ff27bc Merge 6f4e802c5fd1e8c698e7836da8b88882947b00bf into e1b9f588815a51682acf68f9b8929f49ad612488

With a rerun, the result was the same:  HEAD is now at 4ff27bc Merge 6f4e802c5fd1e8c698e7836da8b88882947b00bf into e1b9f588815a51682acf68f9b8929f49ad612488

In fact, e1b9 is the parent of two commits on the fork, so these test results completely ignore any latter commits on the main repository...

So either GH CI is weird in this aspect, or your repositories are configured to do this, or on: pull_request: null... or some other thing, that I do not know.

But test results are not to be trusted.

[alfsb]

But test results are not to be trusted.

... as test results depend on no other changes on master, ever, because actions/checkout ignores changes on master.

In fact, this makes me feel a little... insane... as this is not the default behaviour, or as I cannot find any indication on documentation on how to change the behaviour from "test against past master" into "test against present master".

The best I came up, after hours in help text is the following:

on:
 push
---
git checkout GITHUB_SHA            // tip of branch
                                   //  merged into
git pull --rebase origin master    // tip of master

or

on:
 push_request:
--
- uses: actions/checkout@v7
  with:
    ref: ${{ github.event.pull_request.head.sha }}  // tip of branch
---                                                 //  merged into
git pull --rebase origin master                     // tip of master

The present, actual "tip of master" is the thing that I cannot find anywhere in GH docs.

Sorry to make this beautiful PR into a discussion about GH CI, but this is something that haunts me since forever.