Move some PDO file entities at sibling positions, wkhtmltox fragment dir

[alfsb]

While creating a new tool for detecting problematic XML files (from libxml perspective), I got reports of two invalid XML files in wkhtmltox, that are really XML fragment files, and various files in PDO hierarchy.

The "error" was about "Extra content at the end of the document", caused by entities used outside elements. To avoid losing that test, this PR changes the position of these entities of s at sibling positions of other <reference>s, maintaining the structure of XML, and to better reflect how the manual is rendered at the end.

But... are these files intended to be positioned in sibling positions? It is rendered nowadays as:

It's is possible to have <reference>s inside <reference>s, so an alternative is to move these class documentation inside their defining PDO drivers files.

Also, I suggest to reaming the titleabrev to something that is more easy to search and render more naturally in image above. MySQL PDO Driver" instead of ``MySQL (PDO), and so on.

[Girgias]

Ohhhh that's how I was meant to add the new PDO subclasses for 8.4

[kamil-tekiela]

It's is possible to have s inside s, so an alternative is to move these class documentation inside their defining PDO drivers files.

Also, I suggest to reaming the titleabrev to something that is more easy to search and render more naturally in image above. MySQL PDO Driver" instead of ``MySQL (PDO), and so on.

Yes, please. The classes should be listed within their respective driver pages.

I don't know what this PR changes. I was hoping that it would fix the build failure I keep getting locally that I cannot fix, but it didn't. But if this PR fixes some error then let's merge it.

[alfsb]

Ohhhh that's how I was meant to add the new PDO subclasses for 8.4

You mean, meant do be side by side to old PDO drivers "chapter" (this PR), or to inside, as kamil-tekiela requested?

[alfsb]

I don't know what this PR changes. I was hoping that it would fix the build failure I keep getting locally that I cannot fix, but it didn't. But if this PR fixes some error then let's merge it.

I can make the changes, but it may make your local build failures worse. Let's first try to fix this mysterious build failure. You are building on Windows? The build failure is in doc-en or an translation?

if you have NO local changes, you can try these commands. Beware that they will erase any local change that you have:

1. Erase (not git rm) the doc-en/reference, and doc-lang/reference;
2. Inside doc-en, git clean -fdXand git restore . Same thing inside translation.
3. Try to build again.

[kamil-tekiela]

Thank you @alfsb. That worked.

I can compare your PR and the live version now and I can't spot any difference, so I think it's safe to merge.

[alfsb]

Thank you @alfsb. That worked.

Glad that it worked. And... also saddened to know that this two decade old heisenbug still haunts the PHP manual.

I can compare your PR and the live version now and I can't spot any difference, so I think it's safe to merge.

Merging this will enable the broken file testing being (way) more strict that it is now. But there is no hurry for that. I will wait for the decision to rename or not, rearrange within or not, to avoid sending piece-wise chantes to translations.