# Where did the _logo_ functions go? - Thread: https://externals.io/message/63901 - Original archive: https://news-web.php.net/php.internals/63901 - Started by Philip Olson on 2012-11-16T01:26:04+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #63901 — Philip Olson — 2012-11-16T01:26:04+00:00 URL: https://externals.io/message/63901#63901 Hello geeks, Why does PHP 5.5 remove the *_logo_* functions? Is this a security related move? Shouldn't these emit `E_DEPRECATED` errors in 5.5? Regards, Philip --- ## #63905 — Sherif Ramadan — 2012-11-16T02:31:45+00:00 URL: https://externals.io/message/63901#63905 · In reply to: #63901 > Hello geeks, > > Why does PHP 5.5 remove the *_logo_* functions? Is this a security > related move? Shouldn't these emit `E_DEPRECATED` errors in 5.5? > > Regards, > Philip > > -- > > > Because the guids were removed. They were replaced with data URIs. It would make sense if there was some function to expose those data URIs to user-land, in the same way that the *_guid functions did, but I guess there isn't. --- ## #63925 — Ferenc Kovacs — 2012-11-16T11:10:31+00:00 URL: https://externals.io/message/63901#63925 · In reply to: #63905 On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan wrote: > > > […] > > Because the guids were removed. They were replaced with data URIs. It > would make sense if there was some function to expose those data URIs > to user-land, in the same way that the *_guid functions did, but I > guess there isn't. > > -- > > > > it was removed when https://github.com/php/php-src/pull/132 got merged after a brief vote on the internals mailing list. see Stas concerns about reusing the same function names for getting the data urls: http://www.mail-archive.com/internals@lists.php.net/msg59293.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #63941 — Sherif Ramadan — 2012-11-16T21:38:05+00:00 URL: https://externals.io/message/63901#63941 · In reply to: #63925 > > > > On Fri, Nov 16, 2012 at 3:31 AM, Sherif Ramadan > wrote: > > […] > > it was removed when https://github.com/php/php-src/pull/132 got merged after > a brief vote on the internals mailing list. > see Stas concerns about reusing the same function names for getting the data > urls: http://www.mail-archive.com/internals@lists.php.net/msg59293.html > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu Obviously it doesn't make sense to use the same function names for the data uris, but why weren't new functions added to expose the data uris to userspace in the same way we used to expose the guids to userspace? It only seems to make sense that we'd continue to do that and it's such a simple fix to replace the functions with new ones. I honestly don't care too much about this particular feature myself, but it sounds pretty silly that this PR did not include the new functions for exposing the uris. My 0.00002 cents... --- ## #63944 — Nikita Popov — 2012-11-16T22:07:48+00:00 URL: https://externals.io/message/63901#63944 · In reply to: #63941 On Fri, Nov 16, 2012 at 10:38 PM, Sherif Ramadan wrote: > Obviously it doesn't make sense to use the same function names for the > data uris, but why weren't new functions added to expose the data uris > to userspace in the same way we used to expose the guids to userspace? > > It only seems to make sense that we'd continue to do that and it's > such a simple fix to replace the functions with new ones. I honestly > don't care too much about this particular feature myself, but it > sounds pretty silly that this PR did not include the new functions for > exposing the uris. > > My 0.00002 cents... > Why would you need those data uris? I mean, if you want to embed a PHP logo, then just embed that logo. If you want to put an image on a website, you would usually also just include that .png, rather than creating a data URI from it and embedding that. I don't see a reason to expose those uris. Nikita --- ## #63945 — Kalle Sommer Nielsen — 2012-11-17T12:01:25+00:00 URL: https://externals.io/message/63901#63945 · In reply to: #63944 Hi Nikita 2012/11/16 Nikita Popov : > I don't see a reason to expose those uris. We all seem in the PHP project to talk about the inconsistency of the language, and the like, re-implementing a "feature", or well an ability, what I proposed and I even think I committed a change until it was shut down was to convert the *_logo_guid() functions into constants, since it returns a constant/static value, I don't think it would hurt to do the same here for the data:uri's. But I honestly don't think it makes much sense to re-add them as functions, while I do think it makes sense to expose the data, because why not if its useful to some users like the *_logo_guid() functions did/does. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #63952 — Sherif Ramadan — 2012-11-17T17:09:46+00:00 URL: https://externals.io/message/63901#63952 · In reply to: #63944 > Why would you need those data uris? For what reason would anyone need the GUIDs? To get the logo maybe? I don't know. > I mean, if you want to embed a PHP logo, > then just embed that logo. If you want to put an image on a website, you > would usually also just include that .png, rather than creating a data URI > from it and embedding that. > > I don't see a reason to expose those uris. > I didn't see a reason to expose the GUIDs either, but hey I'm just stating the obvious here. PHP had a way to get the logo exposed to userspace. It seems like we just make up these reasons as we go along. When they were GUIDs they were OK when they became data URIs, obviously (and for reasons that appear to be obvious only to those who make these decisions) they weren't. I guess I need to get in on this foresight I'm not in possession of. --- ## #63957 — Nikita Popov — 2012-11-17T18:22:59+00:00 URL: https://externals.io/message/63901#63957 · In reply to: #63952 On Sat, Nov 17, 2012 at 6:09 PM, Sherif Ramadan wrote: > On Fri, Nov 16, 2012 at 5:07 PM, Nikita Popov > wrote: > > […] > > For what reason would anyone need the GUIDs? To get the logo maybe? I > don't know. > > > […] > URI > > […] > > I didn't see a reason to expose the GUIDs either, but hey I'm just > stating the obvious here. > > PHP had a way to get the logo exposed to userspace. It seems like we > just make up these reasons as we go along. When they were GUIDs they > were OK when they became data URIs, obviously (and for reasons that > appear to be obvious only to those who make these decisions) they > weren't. > The GUID functions were added decades ago, but now we're talking about ... now. Things changed. PHP isn't in the just-add-a-function-for-everything mode anymore. Unless displaying a PHP logo is a common thing to do there is no reason to add a function for it. --- ## #64006 — Philip Olson — 2012-11-21T05:38:12+00:00 URL: https://externals.io/message/63901#64006 · In reply to: #63957 Thanks everyone, I didn't remember thinking about this so was impulsively curious. Dug a little now, so here's what happened: Proposal to internals (July 14, 2012) with discussion July 14-18: ------------------ Thread: http://markmail.org/thread/kewdoz3dowrr7rfv Summary: Seemed okay, discussed more "how" than "why", and more "yes" than "maybe" approved. Conclusion: No clear decision was reached. The patch: ------------------ Patch: https://github.com/php/php-src/pull/132 Pull: http://git.php.net/?p=php-src.git;a=commitdiff;h=c9eb641 Summary: Mostly a technical/patch related discussion there, several tweaks, then pulled. Conclusion: Merged/pulled into master on August 4, 2012. What happened: ------------------ - The PHP logo GUIDs were removed, and replaced with data URIs in `phpinfo()` and friends. - BC: Removed four *_logo_* functions, and GUID usage. - `E_DEPRECATED` was not used beforehand, nor doc updates, they were simply removed. FWIW, also no RFC. It's understandable how a minimally used feature can be changed and removed without much worry/thought. But, they appear to be the only functions removed in 5.5, and this helps it feel even easier to not break BC for this not-so-important change. Proposal: I propose we revert this change. Future consideration might include `E_DEPRECATED` for these functions in 5.5, although I am not proposing that part. Seems sensible, though. Regards, Philip --- ## #64007 — Stas Malyshev — 2012-11-21T05:45:30+00:00 URL: https://externals.io/message/63901#64007 · In reply to: #64006 Hi! > Proposal: I propose we revert this change. Future consideration might I see no reason to revert the change and keep dragging around the GUIDs. Data URLs are much better and cleaner solution, and only reasons not to do it are purely bureaucratic, for which I don't care much. We could keep the functions, but what these functions would do? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64008 — Adam Harvey — 2012-11-21T05:51:54+00:00 URL: https://externals.io/message/63901#64008 · In reply to: #64007 > > […] > > I see no reason to revert the change and keep dragging around the GUIDs. > Data URLs are much better and cleaner solution, and only reasons not to > do it are purely bureaucratic, for which I don't care much. We could > keep the functions, but what these functions would do? The issue I have with this is just that we don't seem to be making much of an effort to stick to the promises we've made around BC when it doesn't suit us to. I agree: in practice, I can't imagine anyone caring a jot about these functions being removed, but we've said that when we're going to remove something, we'll deprecate for a minor release, then remove. Why don't we live up to it? Adam --- ## #64010 — Rasmus Lerdorf — 2012-11-21T05:58:54+00:00 URL: https://externals.io/message/63901#64010 · In reply to: #64008 > > > […] > > The issue I have with this is just that we don't seem to be making > much of an effort to stick to the promises we've made around BC when > it doesn't suit us to. I agree: in practice, I can't imagine anyone > caring a jot about these functions being removed, but we've said that > when we're going to remove something, we'll deprecate for a minor > release, then remove. Why don't we live up to it? We also have to apply common sense here. You are implicitly comparing ext/mysql which millions of sites use to these logo functions which 0 sites use. The one and only reason we had to add them over simply doing an tag was because people complained that we were tracking them. It is obviously way better to just stick an img src tag in your page if you want to put a php logo on there so there is no reason for people to use these functions and people don't. We weren't even going to document them actually, but someone did for completeness sake, I guess. -Rasmus --- ## #64011 — Stas Malyshev — 2012-11-21T06:34:22+00:00 URL: https://externals.io/message/63901#64011 · In reply to: #64008 Hi! > The issue I have with this is just that we don't seem to be making > much of an effort to stick to the promises we've made around BC when We make a lot of effort to do this. But it does not mean we should be blindly and stupidly following the rigid rules even when it makes zero sense in practice. > it doesn't suit us to. I agree: in practice, I can't imagine anyone > caring a jot about these functions being removed, but we've said that > when we're going to remove something, we'll deprecate for a minor > release, then remove. Why don't we live up to it? Exactly because in practice it is not important. So on one side, you have making PHP better without any practical downside. On the other side, you have delaying making PHP better, but feeling good about strictly following bureaucratic rules. I prefer the former. Rules are important, but it is also important to not lose the sight of the goal - why these rules exist and when they make sense. And when they don't. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64013 — Philip Olson — 2012-11-21T06:50:05+00:00 URL: https://externals.io/message/63901#64013 · In reply to: #64011 > Hi! > > > […] > > We make a lot of effort to do this. But it does not mean we should be > blindly and stupidly following the rigid rules even when it makes zero > sense in practice. We made sense, and are not being blind and stupid. You may disagree but I don't understand why this discussion has to become so harsh. > > […] > > Exactly because in practice it is not important. So on one side, you > have making PHP better without any practical downside. On the other > side, you have delaying making PHP better, but feeling good about > strictly following bureaucratic rules. I prefer the former. > > Rules are important, but it is also important to not lose the sight of > the goal - why these rules exist and when they make sense. And when they > don't. It's the inconsistency that bothers me. I think a rule like "Never remove a ~function without it first emitting E_DEPRECATED" can be followed 100% of the time, and don't see this as a bureaucratic rule but instead think this consistency would make PHP better. Regards, Philip --- ## #64014 — Adam Harvey — 2012-11-21T07:15:46+00:00 URL: https://externals.io/message/63901#64014 · In reply to: #64011 > > […] > > Exactly because in practice it is not important. Actually, I'm going to retract my statement, and here's why: http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php Let's set aside that this is terribly misguided code[0]. If that was a good enough reason to remove functionality willy-nilly, I could have saved myself a lot of e-mails on the ext/mysql front. But (to my horror) users are actually using php_logo_guid() in the wild. I haven't searched for the other functions, but I assume there are cases where they're used too. And it's not just one WordPress plugin. Nanoweb[1] calls php_logo_guid() on its demo page[2]. ErfurtWiki[3] has a similar demo page[4]. There are other projects of dubious provenance on Ohloh that call it too. It may only be a handful of projects, none of which any of us have probably ever heard of, or will ever hear a complaint from, but I bet those projects are important to their creators. > Rules are important, but it is also important to not lose the sight of > the goal - why these rules exist and when they make sense. The rules are there to protect developers from having functions dropped out from under them without warning. I don't see the problem with reverting this on the 5.5 branch only, adding `E_DEPRECATED` warnings to the appropriate places, and making the first item in the master UPGRADING guide for 5.6 be that these functions were removed. Adam [0] Hell, it won't even "decrypt" or "encrypt" properly on April 1, which is entertaining. [1] "The PHP Web Server": http://nanoweb.si.kz/ [2] http://nanoweb-instant.googlecode.com/svn/trunk/www/vhosts/www.cgidemo.com/index.php [3] http://sourceforge.net/projects/erfurtwiki/ [4] https://erfurtwiki.svn.sourceforge.net/svnroot/erfurtwiki/trunk/ewiki/examples/zendwiki.php --- ## #64019 — Stas Malyshev — 2012-11-21T08:41:20+00:00 URL: https://externals.io/message/63901#64019 · In reply to: #64013 Hi! > It's the inconsistency that bothers me. I think a rule like "Never remove > a ~function without it first emitting E_DEPRECATED" can be followed 100% > of the time, and don't see this as a bureaucratic rule but instead think > this consistency would make PHP better. I guess that's where we disagree. I think in this particular case the change does make PHP better, and I do not value consistency for its sake and having 100% for its sake. If there were any practical reason why the change is wrong, that'd be different matter of course. P.S. I of course did not mean you or anybody else when talking about stupidly following rules, I just described a situation we want to avoid. Sorry if I sounded offensive, it was not my intent. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64020 — Stas Malyshev — 2012-11-21T08:45:44+00:00 URL: https://externals.io/message/63901#64020 · In reply to: #64014 Hi! > Actually, I'm going to retract my statement, and here's why: > http://svn.wp-plugins.org/praized-community/trunk/includes/php/praized-php/PraizedCipher.php I think breaking this code is an advantage :) That's definitely not how php_logo_guid should be used and using it as a secure salt makes no sense at all. To add insult to injury, it's wrapped in an if()! Please make me unsee it. > The rules are there to protect developers from having functions > dropped out from under them without warning. I know why the rules are. I just think in this case the function is clearly abused and delaying this improvement for at least a year because of somebody using logo guids as encryption salts makes no sense to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64023 — johannes@schlueters.de — 2012-11-21T08:58:35+00:00 URL: https://externals.io/message/63901#64023 · In reply to: #64020 > Hi! > > > […] > > I think breaking this code is an advantage :) That's definitely not how > php_logo_guid should be used and using it as a secure salt makes no > sense at all. To add insult to injury, it's wrapped in an if()! Please > make me unsee it. Agree. We never guaranteed this to be any stable value. And even using it to display the logo is error-prone: Whether the logo can be shown depends on expose_php in php.ini. johannes