PS. Where are you pulling all these PHP files from - are they publicly accessible?
Yup, they're publicly accessible... I began this whole SMF-patching arc (back when I did my
first) by just downloading the archived sources for 1.1.19 (from
here) and then getting them to run in an era-appropriate version of Debian inside a QEMU image.
But, over time, I've upgraded my branch of 1.1.19 to get it working within a more modern/comfortable environment (modern PHP version, modern MySQL version, etc.), which has resulted in hundreds of little modifications.
So, there are three versions of SMF that I need to consider when I put together a new patch (my version, theymos' version, and original 1.1.19). What I do is
test things on my version (which includes the hundreds of little changes I mentioned earlier, and sometimes also includes some subset of my other patches), but, because that version includes many changes that were never in 1.1.19 and that theymos likely doesn't have in his version, at least, not in exactly the same places/forms, when I'm finished testing a patch, I carefully re-base it against original 1.1.19 (so that theymos has a constant backdrop to consider my diffs against).
I don't have access to theymos' version of SMF, but, even though I can't see it, it does influence the way I put together my patches. Because I know that theymos will be looking at diffs that he can't merge as-is (because they're not based against his version), I try to keep the number of "patch points" to a minimum and try to place them in spots that I figure are relatively stable between all three versions. If I could see theymos' version, then my patches would probably look a lot different than they do, but, for now, I'm basically stuck in a situation where I have to give theymos "impressionistic" diffs that I'm counting on him to be able to read/interpret and then carefully splice into his version while considering all the hazards that I can't see. (Part of the reason that the 2FA patch was such a challenging piece of work was because it's very security-sensitive code, and finding just the right way to express a high-consequence modification like that, given the constraints I've mentioned, took a great deal of effort/thinking.)
And how do you test these things?
As above, in my own modified version of SMF. I crank all the logging/error-reporting stuff up to paranoid levels, and then basically just manually exercise SMF and make sure that the logs stay clean.
Thanks PowerGlove, that was super-fast and quicker than I expected
No problem. Thanks for suggesting it.
There are other elements in forum that have similar ''issue'', one of them is footer aka Info Center, but this is more useful than a header.
Haha, you didn't read my whole post, did you?
See the last line of the OP, quoted below:
(Though I've described the problem only with respect to the collapsible section at the top of the page, there's another one, the so-called "info center" at the bottom of the main page, that these fixes also address.)
@theymos: Looking at the first diff again (Fix A), it's actually kind of goofy to use the
$settings array the way I did. Only the code in
template_main_above() is affected by the new setting, and I don't see anything else ever needing access to it (the category collapse stuff works in its own distinct way), so I'd probably just base the three changed if-statements on a local variable instead (something like
$force_collapse_by_cookie), with a similar comment to the one I left in
template_init().