# removing some cruft - Thread: https://externals.io/message/52523 - Original archive: https://news-web.php.net/php.internals/52523 - Started by marius adrian popa on 2011-05-28T07:09:18+00:00 - Messages: 6 - 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 --- ## #52523 — marius adrian popa — 2011-05-28T07:09:18+00:00 URL: https://externals.io/message/52523#52523 Removing some cruft from php I'm thinking that the logo should be optional --disable-logo PHPE9568F34-D428-11d2-A769-00AA001ACF42 http://www.phpsadness.com/ via combinator http://news.ycombinator.com/item?id=2591845 --- ## #52524 — Kalle Sommer Nielsen — 2011-05-28T10:05:38+00:00 URL: https://externals.io/message/52523#52524 · In reply to: #52523 2011/5/28 marius adrian popa : > Removing some cruft from php > I'm thinking that the logo should be optional --disable-logo > PHPE9568F34-D428-11d2-A769-00AA001ACF42 expose_php = Off? -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #52525 — Daniel Brown — 2011-05-28T17:42:37+00:00 URL: https://externals.io/message/52523#52525 · In reply to: #52524 > > expose_php = Off? I think what he and others mean is that they want the option to leave the logo, credits, et cetera, completely out of the build at compile time. -- Network Infrastructure Manager http://www.php.net/ --- ## #52563 — Philip Olson — 2011-05-31T13:57:36+00:00 URL: https://externals.io/message/52523#52563 · In reply to: #52525 > > > […] > > I think what he and others mean is that they want the option to > leave the logo, credits, et cetera, completely out of the build at > compile time. We also have other possibilities here (this is not a proposal, but rather, a list of options/ideas to ponder): 0. Do nothing 1. Disable expose_php within the distributed php.ini-* files Trivial, but changing [at least] php.ini-production is a real possibility. 2. Disable expose_php by default within PHP We could do this too. Default === when no php.ini file is used. 3. Remove the specific PHP version from the exposed PHP header There are security concerns although I'm not sure what implications (BC?) or real help this would offer. For example, version information can be deciphered by other means (e.g., logos and credits change over time) but maybe it's a help because, for example, displaying `phpinfo()` requires direct user action. See also #4. 4. Change its behavior and usage For example, `phpinfo()` relies upon expose_php for both the logo and credits information to be displayed. However, the `phpinfo()` output clearly exposes PHP (along with the version) regardless of the expose_php setting so we could instead embed the logo into `phpinfo()`, and display credits as per `phpcredits()`, instead of relying upon expose_php for this as done currently. In other words, expose_php could be off yet `phpinfo()` behavior would remain close to the same with either a little extra markup, or appended credits near the license. But this raises the question: Why do we have magical logo and credit guids? 5. And a performance review People are concerned with performance issues (e.g., images loaded into memory) although I'm not sure what real performance is lost (some have made guesses). Is there a real issue with performance here? How does it compare with, let's say, loading an additional extension? If so, how can it be helped? Regards, Philip --- ## #52564 — Hannes Landeholm — 2011-05-31T14:06:04+00:00 URL: https://externals.io/message/52523#52564 · In reply to: #52563 Yeah, I was wondering why the magical logo thing was implemented like that. Just use the href= "data:image/png;base64,..." scheme instead if you really need a logo there. Combine that with smaller size and heavy jpeg compression and it shouldn't make the HTML /that/ bloated. Hannes If you really need such content in `phpinfo()` you could simply embed the picture in HTML using the data: scheme. > > > > > […] > wrote: > > […] > > We also have other possibilities here (this is not a proposal, but rather, > a list of options/ideas to ponder): > > 0. Do nothing > > 1. Disable expose_php within the distributed php.ini-* files > > Trivial, but changing [at least] php.ini-production is a real possibility. > > 2. Disable expose_php by default within PHP > > We could do this too. Default === when no php.ini file is used. > > 3. Remove the specific PHP version from the exposed PHP header > > There are security concerns although I'm not sure what implications (BC?) > or real help this would offer. For example, version information can be > deciphered by other means (e.g., logos and credits change over time) but > maybe it's a help because, for example, displaying `phpinfo()` requires direct > user action. See also #4. > > 4. Change its behavior and usage > > For example, `phpinfo()` relies upon expose_php for both the logo and credits > information to be displayed. However, the `phpinfo()` output clearly exposes > PHP (along with the version) regardless of the expose_php setting so we > could instead embed the logo into `phpinfo()`, and display credits as per > `phpcredits()`, instead of relying upon expose_php for this as done currently. > In other words, expose_php could be off yet `phpinfo()` behavior would remain > close to the same with either a little extra markup, or appended credits > near the license. > > But this raises the question: Why do we have magical logo and credit guids? > > 5. And a performance review > > People are concerned with performance issues (e.g., images loaded into > memory) although I'm not sure what real performance is lost (some have made > guesses). Is there a real issue with performance here? How does it compare > with, let's say, loading an additional extension? If so, how can it be > helped? > > Regards, > Philip --- ## #52621 — Stas Malyshev — 2011-06-01T04:45:20+00:00 URL: https://externals.io/message/52523#52621 · In reply to: #52564 Hi! > Yeah, I was wondering why the magical logo thing was implemented like that. > Just use the href= "data:image/png;base64,..." scheme instead if you really > need a logo there. Combine that with smaller size and heavy jpeg compression > and it shouldn't make the HTML /that/ bloated. Well, there are some browsers that don't support data: (ahem, IE7) but I'd say cleanness is more important and those browsers must die anyway :) That, however, doesn't solve problem with credits page, and IE hates navigable data: (meaning HTML) so we couldn't use it for credits. But if someone submits patch for images, I don't see a problem with that. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227