Archive for PHP

Finding Which php.ini Is Loaded

This is actually a throwback to the post Overriding PHP Settings, but is presented here separately due to the number of times the question is asked.

If you’re on a *NIX-based system and are trying to figure out which php.ini is being loaded by the CLI, simply run the following command:

ls -l `/bin/env php -i | grep "Loaded Configuration File" | sed 's/.*=> //g'`

If you want to edit the file right from that command, simply replace ‘ls -l’ with an editor of your choice, such as:

vi `/bin/env php -i | grep "Loaded Configuration File" | sed 's/.*=> //g'`

PHP Network Upgrade Operation, Phase II: 100% PHP 5 Compliance

Well, the email from last night summarizes it appropriately:

ALL:

After the expulsion of the four non-compliant mirrors, the PHP
Network Infrastructure is now running no less than the common
distro-supplied version of 5.1.6, as outlined over the last two
months.

For those of you who put forth fantastic efforts to pull your
mirrors into compliance, we would like to thank you VERY much! And to
everyone as a whole, thanks for everything, as always. Keep up the
great work, and get ready for SQLite as a requirement, which will be
announced this month.

Thanks again!



daniel.brown@parasane.net || danbrown@php.net
http://www.parasane.net/ || http://www.pilotpig.net/

One phase remains: the addition of SQLite to all official mirrors around the world. Updates on that to follow as we near completion.

PHP Network Upgrade Operation: Phase I Complete!

Well, the first phase of the global network upgrade for php.net has worked out pretty well. Of 120 mirrors that were active at the time, only three were removed for failing to upgrade or respond to contact attempts. That comes out to just 2.5%, which is an acceptable number. I guess we can deem this part a success, thanks to the maintainers and providers around the world.

An email sent just a few moments ago to all of the maintainers who co-provide the PHP network’s global infrastructure with some basic metrics:

———- Forwarded message ———-
From: Daniel Brown
Date: Tue, Sep 1, 2009 at 14:05
Subject: Current PHP Global Network Statistics
To: PHP Mirrors List

ALL:

As you may now already know, after completing the first phase of the upgrade operation, all mirrors are running PHP5. Here is a breakdown of all versions, as well as some other statistics you may find interesting.

Overall:

Total Mirrors, World-Wide: 118
% of Mirrors with SQLite: 65.3%
% of Mirrors with Stats: 37.3%
% of Mirrors Running PHP5: 100.0%

By version:

5.0.3: 1
5.0.4: 1
5.1.1: 1
5.1.2: 2
5.1.6: 20
5.2.0: 8
5.2.1: 3
5.2.3: 2
5.2.4: 7
5.2.5: 2
5.2.6: 17
5.2.8: 12
5.2.9: 23
5.2.10: 12
5.3.0: 6
5.3.1: 1

Subject to deletion in Phase II: 5
Running development versions: 1

Content Age Sampling:

Oldest Mirror: 963096 Seconds (NOTE: Disabled, Pending Delete)
Youngest Mirrors: 98 Seconds
Most Common Ages: 1891 Seconds, 3699 Seconds
Total Average Age: 26160.2 Seconds (7 Hours, 16 Minutes)
Adjusted Average Age: 18083.2 Seconds (5 Hours, 1 Minute)
[NOTE: Adjustment removes disabled mirror from calculation.]

Thanks again, as always, for everyone’s hard work and dedication. We’re looking forward to working with all of you for a long time to come!



daniel.brown@parasane.net || danbrown@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
Check out our great hosting and dedicated server deals at http://twitter.com/pilotpig

PHP Network Upgrade Operation: Phase I Deadline….

This is it…. the moment I’ve been waiting for…. the moment when I can finally see a beautiful, bright, shiny 100% greet me when I look for the number of hosts, in accordance with policy, running PHP5.

Just a few more minutes….

PHP Network Upgrade Operation: The Stage Is Set!

The following is a message that I just sent out to the team of providers and maintainers who provide the global network infrastructure for php.net. Time to shake, rattle, and roll!

ALL:

After many detailed discussions, the PHP Project’s Network Infrastructure Team – the folks who manage the overall health and sanity of all mirrors around the globe – have decided to forcefully end participation with maintainers who have failed or refused to upgrade the version of PHP used on the mirrors they provide to the PHP Project. We regret that some of you may be permanently removed from the official mirrors program, but after more than a full year of attempts to work with some maintainers, we’re left with no other choice than to remove them from our roster.

As you are no doubt aware, the PHP Group publicly released version 5.3 of the language this summer (30 June, 2009). The latest version of the 5.2 branch, PHP 5.2.10, was released to the public on 18 June, 2009. Further, the end of support for PHP4 was announced over two years ago on 13 July, 2007, and PHP4 officially reached its end-of-life on 31 December, 2007. Unfortunately, nearly 6% of our mirror program participants have failed to upgrade, despite multiple notices and warnings issued, in which the ramification (expulsion from the program) was obviously noted throughout.

Our users look not only to the core teams of the PHP Project, but also to you, the official mirror maintainers, to provide guidance and leadership, and to provide the latest, safest, most stable versions of the language and software. By failing to meet this obligation to the community, a maintainer is failing to meet the high standard of quality we expect from our partners. Further, due to limitations and missing or outdated features and extensions in older incarnations of the PHP language, the Website Team (the folks responsible for the development and maintenance of php.net) have frequently reported difficulties in the implementation of new features, instead needing to make the system backward-compatible with mirrors using legacy versions of the language.

It should be noted that most of those who are likely to be removed from the program are maintainers from whom we’ve received no response to mailings in more than 12 months, or those who have expressly refused to upgrade their mirror.

When a mirror is removed from the program, we will immediately begin the process of replacing it with a compliant mirror physically located in the same country as the deleted mirror, giving priority to those who have applied to the program and have been placed on the Official Mirror Waiting List.

Finalized in discussions today, there is now a series of milestones and deadlines for completion of upgrades for those of you who wish to remain active and in good standing as an official mirror for the PHP Project and php.net. This is for the benefit – in performance and security – of the maintainer, the Project, and the PHP community as a whole. The deadlines are thusly defined:

EFFECTIVE IMMEDIATELY: All mirrors still using releases in the 4.3 branch or earlier will be removed with no further communication or extension of deadline.

21 AUGUST, 2009: Any mirror that has not yet upgraded to PHP5 must request – and be approved for – an exception to the deadline by 23:59 UTC on 21 August, 2009. Extensions will be granted or denied on a case-by-case basis, and never for more than 30 days beyond the standard deadline. There will be no exceptions allowed for this requirement.

31 AUGUST, 2009: [DEADLINE FOR STANDARD PHP4->PHP5 MIGRATION.] Any mirror that has not yet upgraded to PHP5 by 23:59 UTC on 31 August, 2009, will be removed with no further communication. There will only be exceptions to this deadline as provided for in the granting of an extension of the deadline as explained in the previous paragraph.

25 SEPTEMBER, 2009: Any mirror that has not yet upgraded to at least PHP 5.1.6 must request – and be approved for – an exception to the deadline by 23:59 UTC on 25 September, 2009. Extensions will be granted or denied on a case-by-case basis, and never for more than 14 days beyond the standard deadline. There will be no exceptions allowed for this requirement.

30 SEPTEMBER, 2009: [DEADLINE FOR EXTENDED PHP4->PHP5 MIGRATION.] Any mirror that has not yet upgraded to PHP5 by 23:59 UTC on 30 September, 2009, regardless of the prior approval of any extensions, will be removed with no further communication or extension of deadline. There will be no exceptions allowed for this requirement.

30 SEPTEMBER, 2009: [DEADLINE FOR STANDARD MODERN PHP5 UPGRADE.] Any mirror that has not yet upgraded to a version greater than or equal to PHP 5.1.6 by 23:59 UTC on 30 September, 2009, will be removed with no further communication. There will only be exceptions to this deadline as provided for in the granting of an extension of the deadline as explained in the previous paragraph.

14 OCTOBER, 2009: [DEADLINE FOR EXTENDED MODERN PHP5 UPGRADE.] Any mirror that has not yet upgraded to a version greater than or equal to PHP 5.1.6 by 23:59 UTC on 14 October, 2009, will be removed with no further communication. There will be no exceptions allowed for this requirement.

IN ADDITION, PLEASE BE ADVISED REGARDING SQLITE: It has been a requirement for approximately a year that all new applicants to the official mirrors program must install and utilize SQLite with PHP on their mirror. It is therefore highly recommended that you install and configure SQLite on your mirror immediately, if you have not already done so, as failure to do so will likely result in your mirror being permanently expelled from the program when we begin to require that existing mirrors observe this rule as well. A written notification will be sent to the PHP Mirrors mailing list at php-mirrors@lists.php.net in advance of the deadline on this when it has been determined. By opting to add SQLite support to your mirror now, you’ll not only begin to reap the benefits of a faster, more stable, more full-featured mirror right away, but you’ll also be eliminating your chances of being removed from the program for non-compliance.

If there are any questions, please contact us immediately via email on the PHP Mirrors mailing list at php-mirrors@lists.php.net.

Thank you very much, all of you, for your continued generosity and excellent service in providing an official mirror to the PHP Project. It is due in large part to all of you that PHP is as widely-distributed and successful as it is. And we, the PHP Group, are very grateful for everything you do.



daniel.brown@parasane.net || danbrown@php.net
http://www.parasane.net/ || http://www.pilotpig.net/

Just Follow The Rules!

If you’ve contributed notes to the PHP manual, you may have also had them modified, removed, or rejected by myself or another editor. If you disagree with it, that’s fine — we’re very open to hearing your side of things, and there’s been more than one occasion where I’ve agreed with the poster and replaced their note on the site.

There is, however, a proper way of doing that…. and the following thread excerpt shows the way not to do so. Keep in mind, the tenor of the thread was mostly professional from both sides, but nonetheless, the author’s name and email are protected from your prying eyes.

On Wed, Mar 4, 2009 at 08:31, <php-notes@lists.php.net> wrote:
> You are receiving this email because your note posted
> to the online PHP manual has been removed by one of the editors.
>
> Read the following paragraphs carefully, because they contain
> pointers to resources better suited for requesting support or
> reporting bugs, none of which are to be included in manual notes
> because there are mechanisms and groups in place to deal with
> those issues.
>
> The user contributed notes are not an appropriate place to
> ask questions, report bugs or suggest new features; please
> use the resources listed on <http://php.net/support>
> for those purposes. This was clearly stated in the page
> you used to submit your note, please carefully re-read
> those instructions before submitting future contributions.
>
> Bug submissions and feature requests should be entered at
> <http://bugs.php.net/>. For documentation errors use the
> bug system, and classify the bug as “Documentation problem”.
> Support and ways to find answers to your questions can be found
> at <http://php.net/support>.
>
> Your note has been removed from the online manual.
>
> —– Copy of your note below —–
>
> on the line:
>
> %R Same as “%H:%I” Example: 00:35 for 12:35 AM, 16:44 for 4:44 PM
>
> i think you mean
>
> %R Same as “%H:%M” ….

It’s true. I had rewritten the strftime() manual page last month at about 03:30 in the morning, and I’d made a mistake in transposing %M with %I. Those of you familiar with the date() function in PHP will recognize how this mistake probably came to pass (hint: in date(), ‘i’ is used to represent the minute).

So if you, dear reader, were the visitor to that page and noticed the error, the proper way of alerting us to the error would be to report a documentation bug so that we can repair it right away. It’s not as common-sense as you’d think, though, and it shouldn’t actually come as a surprise — some folks really don’t see it as a “bug” so much as something about which they, in good faith and with all good intentions, should warn other users.

Because it’s the improper venue for reporting bugs, though, and in following policy and procedure, I deleted the note. (I also immediately ate a slice of humble pie and committed the fix.)

…. but it didn’t end with that….

On Wed, Mar 4, 2009 at 11:51, frank <null@example.com> wrote:
> if a human actually reads this, you’ll see that i was in accordance
> with the rules about posting comments to this page. i am pointing out
> a typo ON THIS ACTUAL PAGE.

A human DOES read this, and one of them is replying to you right
now. Ooooh!!!!

I’m the one who not only deleted your note because it was
completely against the obviously-posted rules, but I’m actually the
one who did that particular manual entry. You’re correct that I had
mistakenly typed %I instead of %M, and I fixed that in the manual
source when I read your note (it will update on the web the next time
the system does its automatic update and build).

Now let me point something out to you — you were NOT in
accordance with the rules. It should’ve been posted as a bug, not as
a user note, and that’s mentioned multiple times on the site and
through the process of posting the note. It is then even printed in
the very email that you quoted herein in your reply. So you will see
why I deleted your note with prejudice.

Thanks for your contribution, and for pointing out my mistake.
Despite the incorrect manner in which the bug was reported, you’ve got
a keen eye and have helped to ensure that the manual is the best it
can be.

Perhaps a little strong, which would’ve garnered an apology from me under most circumstances. It wouldn’t have required one, but I would’ve offered it anyway. The majority of folks from the community who contribute to PHP are fantastic. Seriously, I genuinely mean that.

Our conversation took a different turn.

On Wed, Mar 4, 2009 at 15:04, frank <null@example.com> wrote:
> Hey man, no need to get your panties all knotted. The first email I
> received was obviously a form letter generated by your system…
> whether a human decided to send it out or not, I don’t know, and
> frankly don’t care.

Listen, Sally, if I want my underpants knotted, you can damn-well
bet that I’m going to wear them that way. And there isn’t a thing
that you or anyone else is going to do to stop me. In fact, as soon
as I’m done typing this message, I’m going to strip down right here in
my office and tie them up, just to prove that point.

There are probably some of you who know me well enough to actually wonder if I did, in fact, strip down right then and there. Well, I won’t go as far as to describe anything in vivid detail, but I will say that some breaking occurred, my chair was involved, and that’s about all I know at this point.

The point is, since some folks don’t notice the guidelines for contributing a user note when they’re doing it, and since a staggering number of the daily traffic of user notes, if you are going to retort with an attitude, don’t expect the rebuttal to be any less attitudinal!

(In all seriousness, my thanks to “frank,” though…. people like him who point out errors and flaws truly make things like the documentation better for everyone. I sure hadn’t noticed the error myself!)

Overriding PHP Settings

Getting the following error?

Invalid command ‘php_flag’, perhaps mis-spelled or defined by a module not included in the server configuration

Well, if your host and server configuration allow it, and should you so desire, you can override some of the php.ini settings for your site (and each subdirectory within your web directory). While you can’t override PHP_INI_SYSTEM settings, there’s still a host of other settings that can be overridden while still maintaining the rest of the configuration of the system – if your server is set up to allow it. And no, n00bZ, it won’t override php.ini for the rest of the box.

To grab your php.ini and copy it to the current directory, just run this command:

cp `/bin/env php -i | grep "Loaded Configuration File" | sed 's/.*=> //g'` .

Then just edit the php.ini and save it in place. Voila! No need to restart Apache or anything.