@rquadling, Seems this is identical for #467 and #468 , so they can be closed. If the changes are relevant for the PHP 5.4 branch, they will be merged back to 5.5 and master.

I wasn't sure if I needed to do a patch for each branch. Thank you for
looking.
On 22 Sep 2013 13:38, "Lior Kaplan" notifications@github.com wrote:

@rquadling https://github.com/RQuadling, Seems this is identical for
#467 #467 and #468#468, so they can be closed. If the changes are relevant for the PHP 5.4
branch, they will be merged back to 5.5 and master.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/466#issuecomment-24881300
.

Hrm... I think I closed the bug report about that topic a few days ago with "Won't fix" (because we already have SAPI dependent INI files).

But you can't use SAPI specific ini files in the additional ini path.

On the servers I'm interacting with that is the only place for ini files.
They are not our servers.

Each extension has its own ini file in the additional ini directory, so
being able to add to it the SAPI specific settings ... everyone is happy.

Whilst I am very familiar with SAPI specific files (big fan when I was a
Windows user and one of the reasons I helped with getting multiple
versions+SAPI paths from the Registry - Aug 2006 - Ha! It's been a while),
it was always a pain that I couldn't have a default ini with just a few
changes to separate the SAPI specific features.

The patch I've supplied does just that.

99% of the ini file is the same for all SAPIs. That 1% difference is
clearly marked in the same file. Single point of maintenance when a non
specific change is made. Easy for repo's to handle for changes and is
compliant with the environments I'm finding myself having to use.

If I was allowed to build my own code on their servers, then this wouldn't
be an issue, but please reconsider the WFx as the SAPI specific files fail
if used in the additional ini directory.

I do fully appreciate that this is yet another option to maintain, but it
operates in a very familiar way, namely [PATH] and [HOST], so this is just
re-using existing pattern, switching the identifier (SAPI name for PATH /
HOST) and determining when to apply the changes (that took me some time).

Kind regards,

Richard Quadling.

On 4 October 2013 08:43, Michael Wallner notifications@github.com wrote:

Hrm... I think I closed the bug report about that topic a few days ago
with "Won't fix" (because we already have SAPI dependent INI files).

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/466#issuecomment-25681322
.

Richard Quadling
Twitter : @rquadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

My bad ... :-/ I closed https://bugs.php.net/bug.php?id=53358 instead of https://bugs.php.net/bug.php?id=65681 :)

Is there anything else I need to do to get this merged into core?

Has it been discussed on internals?

Comment on behalf of krakjoe at php.net:

Since this PR targets an unsupported version of PHP, and since it requires an RFC and discussion to move forward, I'm closing this PR.

Please take this action as encouragement to create a clean PR, if possible (not sure if possible) with tests, targeting the correct branch. In addition, please create an RFC and start an internals discussion.