PHP Weekly improvements(phpweekly.com)
phpweekly.com
PHP Weekly improvements
http://www.phpweekly.com/archive/latest.html
9 comments
Professional software developers who care about creating secure and maintainable applications that perform well will, by necessity, be very hesitant to use or recommend the use of PHP.
It has a very poor track record when it comes to security flaws, for example. It is also rife with inconsistencies and unjustifiable oddities throughout the language itself, and its standard library. Factors like those then promote the development of software that is of an unacceptable quality.
There do happen to be many extremely experienced software developers here at HN, and we won't hesitate to point out the flaws with various technologies, including PHP. This is not a bad thing; it's quite good. It's extremely important to be vocal about low-quality technologies.
These days, there are just so many alternatives that are far superior to PHP in every respect. Even with its new features, PHP is still not an acceptable option. So we shouldn't be looking for positives where there just aren't any, nor should we be surprised when all we find are negatives.
It has a very poor track record when it comes to security flaws, for example. It is also rife with inconsistencies and unjustifiable oddities throughout the language itself, and its standard library. Factors like those then promote the development of software that is of an unacceptable quality.
There do happen to be many extremely experienced software developers here at HN, and we won't hesitate to point out the flaws with various technologies, including PHP. This is not a bad thing; it's quite good. It's extremely important to be vocal about low-quality technologies.
These days, there are just so many alternatives that are far superior to PHP in every respect. Even with its new features, PHP is still not an acceptable option. So we shouldn't be looking for positives where there just aren't any, nor should we be surprised when all we find are negatives.
> Professional software developers who care about creating secure and maintainable applications that perform well will, by necessity, be very hesitant to use or recommend the use of PHP.
Nonsense. As the most widely deployed platform it has absolutely massive exposure and security flaws are fixed quickly.
Don't confuse poor practices by newbies with platform security and stability.
> It has a very poor track record when it comes to security flaws, for example.
It does not.
> It is also rife with inconsistencies and unjustifiable oddities throughout the language itself
Every language has its warts. What's your point?
> These days, there are just so many alternatives that are far superior to PHP in every respect.
Yeah. Don't blame the tool. Blame the craftsman. And a craftsman who spends quite a bit of time complaining about the tools others use ... well ... you can fill in the rest.
Nonsense. As the most widely deployed platform it has absolutely massive exposure and security flaws are fixed quickly.
Don't confuse poor practices by newbies with platform security and stability.
> It has a very poor track record when it comes to security flaws, for example.
It does not.
> It is also rife with inconsistencies and unjustifiable oddities throughout the language itself
Every language has its warts. What's your point?
> These days, there are just so many alternatives that are far superior to PHP in every respect.
Yeah. Don't blame the tool. Blame the craftsman. And a craftsman who spends quite a bit of time complaining about the tools others use ... well ... you can fill in the rest.
Don't be afraid to make the text here:
http://www.phpweekly.com/archive/latest.html
larger, and expand the width of the layout some. If you're going to leverage a simple layout like that in which the text is the sole focus, you might as well go a bit larger font size.
http://www.phpweekly.com/archive/latest.html
larger, and expand the width of the layout some. If you're going to leverage a simple layout like that in which the text is the sole focus, you might as well go a bit larger font size.
Hi and thanks for the suggestion. As this is an archive from the email itself thats why we used that width.
Hi there. We posted about PHP Weekly last week and we had some really good suggestions from people - mainly about how we'd not done a great job explaining what we are doing!! Took all the suggestions on board and added in an image, latest issue link as well as archives. We've also added in an RSS feed, but I note the comment (on here) about the RSS feed being terrible. Sorry, we'll work on that.
Thanks, I must have missed it last week. Looks like a much more readable alternative to phpdeveloper.org (which has too many automated posts imo).
>Dealing with Duplicated Code
Anyone notice the duplicate topic under Tutorials and Talks "Offline Processing in PHP with Advanced Queuing," just gave me a little chuckle when one of the articles is dealing with duplicated code.
Aside from this, I LOVE PHP. A prospective employer was asking if I would be open to learning RoR. Anyone who is experienced on Rails, could you let me know if it's a similar structure as PHP (which I'm great at)? Thanks.
Anyone notice the duplicate topic under Tutorials and Talks "Offline Processing in PHP with Advanced Queuing," just gave me a little chuckle when one of the articles is dealing with duplicated code.
Aside from this, I LOVE PHP. A prospective employer was asking if I would be open to learning RoR. Anyone who is experienced on Rails, could you let me know if it's a similar structure as PHP (which I'm great at)? Thanks.
As Rails is a framework and not a language, it has a much more specified "structure."
Syntactically, the languages are not all that similar. It's probably closer to Python.
As much as people abhor PHP in programming communities (and I get that sentiment), I find RoR to be a far, far worse platform to build upon.
Syntactically, the languages are not all that similar. It's probably closer to Python.
As much as people abhor PHP in programming communities (and I get that sentiment), I find RoR to be a far, far worse platform to build upon.
What do you find worse about RoR? Compared to whichever PHP framework.
Ugly monkey patching everywhere, open classes, insecure by default (e.g. mass assignment), global states, model classes easily too much tied to a single controler, active record pattern, ...
It's interesting. Much of what I think is beautiful about Ruby (and Python, and Objective C, and Smalltalk) is what people who like PHP consider ugly. I, myself, and it's a matter of taste, find PHP (and most of the code written with it) ugly. There is no objective measurement for ugliness.
There you go https://github.com/runekaagaard/snowscript
PHP is a kludge. You'd be surprised to know that world is made of kludges with a few elegant hacks thrown in and not the other way round.
Performance hacks are always kludges. Can you live without them ?
Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ? What makes that time well spent ?
Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
PHP is a kludge. You'd be surprised to know that world is made of kludges with a few elegant hacks thrown in and not the other way round.
Performance hacks are always kludges. Can you live without them ?
Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ? What makes that time well spent ?
Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
Well, everyone has their own definition of "elegant syntax" which makes objectivity difficult.
I guess the best tools are ones which help you produce output quickly whilst being conductive to elegance and readability, Ruby's terse syntax and features like blocks are an attempt at this.
It also depends on how big your project will get and how long it will need to be maintained for.
There are plenty of projects I have seen where chunks of extremely bad code have been pumped out to create a 1.0 with a giant list of features. Of course such code becomes increasingly costly to maintain or modify without breaking. In many cases they would have been better off cutting features from the 1.0 (most features are unused anyway) and concentrating on quality.
I guess the best tools are ones which help you produce output quickly whilst being conductive to elegance and readability, Ruby's terse syntax and features like blocks are an attempt at this.
It also depends on how big your project will get and how long it will need to be maintained for.
There are plenty of projects I have seen where chunks of extremely bad code have been pumped out to create a 1.0 with a giant list of features. Of course such code becomes increasingly costly to maintain or modify without breaking. In many cases they would have been better off cutting features from the 1.0 (most features are unused anyway) and concentrating on quality.
> You'd be surprised to know that world is made of kludges
No. I wouldn't. I'm an electrical engineer by training.
> Performance hacks are always kludges.
Not always. Sometimes they bring out some inner beauty in the code that was previously hidden. But, again, sometimes they don't.
> Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ?
It depends on your priorities. If you were a poet, would you be more worried about making good poetry or selling more books?
> Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
Again, it depends on what is your output and how you relate with the fact that the thing generating that output is a horrible mess.
No. I wouldn't. I'm an electrical engineer by training.
> Performance hacks are always kludges.
Not always. Sometimes they bring out some inner beauty in the code that was previously hidden. But, again, sometimes they don't.
> Honest question, should I waste my time worrying about the "What makes syntax elegant" than working with the existing kludge ?
It depends on your priorities. If you were a poet, would you be more worried about making good poetry or selling more books?
> Why shouldn't I seek beauty in output and look for a programming language that get's me the output quickly ?
Again, it depends on what is your output and how you relate with the fact that the thing generating that output is a horrible mess.
> No. I wouldn't. I'm an electrical engineer by training.
I agree. Electrical, Electronics, Civil, NASA aka Real Engineering will not have more kludges.
Phone Radiation / Drainage Systems have a few "Oh well I'll just leave it here ..."
But what about medicine, law, newspapers ? Are they not part of the real messy world ?
I agree to be a kludge worker and an idealist part time poet :) (pragmatic choice)
I agree. Electrical, Electronics, Civil, NASA aka Real Engineering will not have more kludges.
Phone Radiation / Drainage Systems have a few "Oh well I'll just leave it here ..."
But what about medicine, law, newspapers ? Are they not part of the real messy world ?
I agree to be a kludge worker and an idealist part time poet :) (pragmatic choice)
Here I'll admit that my exposure to PHP frameworks is minimal. My primary issues are the rigidity of RoR, the ample amount of security issues and the general slowness of Ruby in some very key areas (which tends to cascade down even more with a framework).
Syntactically, the languages are not all that similar. It's probably closer to Python.
My impression was that Ruby is much closer to Perl than Python.
My impression was that Ruby is much closer to Perl than Python.
Don't really see that. PHP was basically written as a C-style interpreted language with $vars. It ended up so much like Perl that there's a decent amount of Perl and PHP you can cross-paste without error.
Speaking as someone who made this exact jump a couple years back, here's the big differences I remember.
* The languages are very different, syntactically. Ruby's blocks and enumerators really don't have an analog in PHP, and they'll take some getting used to. There's also some pretty deep philosophical differences in what the two languages mean by "class". That said, they sit at about the same abstraction layer, so line by line the complexity and flow shouldn't be that big of a jump.
* Rails is more like, say, Zend Framework than raw PHP. It enforces an MVC layout on your code and does what looks at first like a lot of magic to figure out which template files correspond to which pages. When you're starting out the rails scaffold generators are your friend.
* Ruby's standard library has a lot less in it than PHPs, so no XML parser or SQL client out of the box. Gems, and bundler in particular, makes it much easier to add third party code, though. You'll spend a lot more time bikeshedding over which third-party library to use, but the competition generally leads to more pleasant APIs in the long run.
* Ruby convention is to have more files and less code per file. A lot of your template files will only end up being three or four lines long. It's honestly easier in the long run, but get an editor that supports that workflow (multiple tabs, fuzzy file open, find-in-project, etc).
* RoR is almost completely independent of Apache for configuration. You get to move all the logic that was in .htaccess into ruby code in your app somewhere, and you get much more freedom over defining what you want your URLs to look like. You'll need to familiarize yourself with a concept called reverse proxying to figure out how this works in production, though.
* Not strictly ruby, but the rails asset pipeline is magic. Once you get used to it you'll never want to do frontend coding without it.
* The languages are very different, syntactically. Ruby's blocks and enumerators really don't have an analog in PHP, and they'll take some getting used to. There's also some pretty deep philosophical differences in what the two languages mean by "class". That said, they sit at about the same abstraction layer, so line by line the complexity and flow shouldn't be that big of a jump.
* Rails is more like, say, Zend Framework than raw PHP. It enforces an MVC layout on your code and does what looks at first like a lot of magic to figure out which template files correspond to which pages. When you're starting out the rails scaffold generators are your friend.
* Ruby's standard library has a lot less in it than PHPs, so no XML parser or SQL client out of the box. Gems, and bundler in particular, makes it much easier to add third party code, though. You'll spend a lot more time bikeshedding over which third-party library to use, but the competition generally leads to more pleasant APIs in the long run.
* Ruby convention is to have more files and less code per file. A lot of your template files will only end up being three or four lines long. It's honestly easier in the long run, but get an editor that supports that workflow (multiple tabs, fuzzy file open, find-in-project, etc).
* RoR is almost completely independent of Apache for configuration. You get to move all the logic that was in .htaccess into ruby code in your app somewhere, and you get much more freedom over defining what you want your URLs to look like. You'll need to familiarize yourself with a concept called reverse proxying to figure out how this works in production, though.
* Not strictly ruby, but the rails asset pipeline is magic. Once you get used to it you'll never want to do frontend coding without it.
Seeing as I have no choice to learning Ruby if I become apart of this dev team, this is great to know. One of the greatest strengths that I absolutely utilize all the time in PHP is the libraries (curl, gd2, xml parsing, mysql, ect)...I couldn't imagine doing effective programming without it now.
Oh well, another challenge, another achievement. Thanks Vec!
Oh well, another challenge, another achievement. Thanks Vec!
Ruby has bindings for most of those libraries (or classes of libraries, like XML parsers.)
I think CURL is handled in a more abstract way in Rails, but I haven't really gotten to work with Http clients in Rails yet.
I think CURL is handled in a more abstract way in Rails, but I haven't really gotten to work with Http clients in Rails yet.
I've done both PHP and Ruby/Rails professionally. They are quite different. I earned a living with PHP first, but I prefer to use Rails (or Sinatra) for most projects these days.
Even though PHP and Ruby (and therefore Rails) have little in common, I think you can still learn the Rails fundamentals quickly. Check out Michael Hartl's excellent Rails Tutorial. Also, Ryan Bates' Railscasts are a fantastic resource.
Even though PHP and Ruby (and therefore Rails) have little in common, I think you can still learn the Rails fundamentals quickly. Check out Michael Hartl's excellent Rails Tutorial. Also, Ryan Bates' Railscasts are a fantastic resource.
Thanks symfoniq. I started with PHP also, and picked it up fairly quickly. I'd learned Ruby regardless, just to work with this dev team and it never hurts to know another language. I really wanted to hear experience from someone who went from php to ruby (since that's what I'd be doing).
Php .net is so well doc'd with an example for almost every function/feature that it made it EXTREMELY easy to pick up. Does Ruby have something similar (really hope it's not -> ruby-lang.org, reminds me of w3), not too keen to Michael Hartl's just cause I'd have to buy it.
Php .net is so well doc'd with an example for almost every function/feature that it made it EXTREMELY easy to pick up. Does Ruby have something similar (really hope it's not -> ruby-lang.org, reminds me of w3), not too keen to Michael Hartl's just cause I'd have to buy it.
Michael Hartl's book is free to read online...
I much prefer Ruby's documentation to PHP's. Especially when it comes to 3rd party code, I don't have one gem in my current Rails project that isn't very nicely documented. Compare that to the PHP I work on during the day and almost all the 3rd party libs have no documentation.
I much prefer Ruby's documentation to PHP's. Especially when it comes to 3rd party code, I don't have one gem in my current Rails project that isn't very nicely documented. Compare that to the PHP I work on during the day and almost all the 3rd party libs have no documentation.
Perhaps I am misinterpreting your statement, but it almost sounds like you blame PHP for the lack of documentation of those libraries. Really you should be blaming the authors of the libraries for poorly documenting them, or the developer who chose those libraries, for choosing ones with poor documentation.
it is ruby-doc. What don't you like about it specifically? Its very concise, consistent, and thorough, which is what I always thought was ideal for these.
I learned PHP years ago, never got past the "futzing around making a basic CMS" stage with RoR (I currently do most of my work in C# and ObjC). I'm sure I'll be politely corrected in this view, but the piles of add-on gems and scripting utilities that characterize Rails-in-practice meant that Rails struck me as kind of a moving target.
Coming from PHP where basically nothing happens unless you make it happen (for better and very often for worse), I found Rails confusing once you got beyond easy Active Record calls and into using gems. There are tons of add-ons that do useful things, but they do a lot of their work behind the scenes assuming adherence to certain conventions—which, I know, is a strength as well as a weakness, I get it. But that increases the difficulty of jumping past the stage of following a tutorial and just installing one persons collection of gems, scripts and other helpers.
Coming from PHP where basically nothing happens unless you make it happen (for better and very often for worse), I found Rails confusing once you got beyond easy Active Record calls and into using gems. There are tons of add-ons that do useful things, but they do a lot of their work behind the scenes assuming adherence to certain conventions—which, I know, is a strength as well as a weakness, I get it. But that increases the difficulty of jumping past the stage of following a tutorial and just installing one persons collection of gems, scripts and other helpers.
It really depends on how you write PHP.
If you write Object Oriented PHP and use a framework with strong OOP principals you probably will have no problem learning Rails.
If you've used MVC before, and you understand the role of a Model, View, Controller, data bindings, ORM, etc. then you should have no problem learning Rails.
If all you know is PHP and it's control structures, and you expect your file to be interpreted every time you visit a URL, then you will probably have more difficultly learning Rails.
It would be helpful to know what you love about PHP.
If you write Object Oriented PHP and use a framework with strong OOP principals you probably will have no problem learning Rails.
If you've used MVC before, and you understand the role of a Model, View, Controller, data bindings, ORM, etc. then you should have no problem learning Rails.
If all you know is PHP and it's control structures, and you expect your file to be interpreted every time you visit a URL, then you will probably have more difficultly learning Rails.
It would be helpful to know what you love about PHP.
You spotted the deliberate mistake - erm. Whoops. Thanks for pointing that out!
Have you seen Wes Mason's PHP Weekly newsletter: http://phpweekly.info? Is this intended as a replacement?
Hi there. We'd actually been running this as a weekly news list for some time (we'd owned the domain for years) via a PHP-related product that I also run. We decided to open this up wider based on seeing the Python Weekly one, as we're also fans of Python. Someone pointed me to Wes last week and I dropped him a line and we have exchanged some friendly emails between us. I need to pick that up again after being away for nearly a week.
After reading the linked http://www.phpclasses.org/blog/post/208-5-Reasons-Why-the-We..., I have to wonder why people still think their favorite technology must "win".
It may be a response to the PHP hate that's common. PHP is very popular, so an end run around technical merits may be alluring to those that don't know how to argue the merits, can't find enough merits to argue, or are just looking for a quick way to draw in the large audience of PHP users that are looking for validation in their choices.
For all the hate given to PHP, I still can't understand why the cool-elite-rockstar-ninja-sexy-hot-hackers of python/ruby/java/go/haskell/clojure/S*t can't come up with half-as-dumb replacement for mod_php and compete with it on its own terms.
Good variable names and documentation are infinitely more important than new shitty frameworks or do vs "{" vs "\t".
Good variable names and documentation are infinitely more important than new shitty frameworks or do vs "{" vs "\t".
Fun fact: mod_php can't safely coexist with anything else.
A few years ago, I briefly ran a webserver that had both mod_python and mod_php installed at the same time. Everything seemed fine until I tried using md5 from Python and repeatedly got completely wrong values:
But I get your point about PHP's deployment story being one of its (arguably few) strong points.
A few years ago, I briefly ran a webserver that had both mod_python and mod_php installed at the same time. Everything seemed fine until I tried using md5 from Python and repeatedly got completely wrong values:
>>> md5.md5("hello").hexdigest()
'00000000000000005039985304054aac'
>>> md5.md5("hello").hexdigest()
'00000000000000009ebb1c1ea77b5505'
But I get your point about PHP's deployment story being one of its (arguably few) strong points.
Might one not say, then, that mod_python also cannot safely coexist with anything else? Seems neither decided to namespace that but you seem to decide to blame PHP?
It has nothing to do with variable names.
People aren't rushing to make mod_* for other languages because it implies a lot of behavior (by nature of it being served through Apache) which isn't really the best idea for security.
Having a structure that mixes the code files, templates (let's ignore mixing of logic and presentation), and static content all in the same publicly accessible location is just asking for security problems.
You can lock down what's accessible or not based on file extensions, but that's through a config that's not part of the deployment (Apache conf) so it's not as easily controlled in your code, or if it is part of the deployment (htaccess), can be affected or overridden by directives nowhere near your code (Apache conf). It's fun when someone breaks the php loading directives in the Apache config and your code starts showing as plain text. You made sure not to hard-code ANY credentials in your PHP files that are publicly reachable, right? Your config isn't publicly reachable, is it?
The closest you are going to get to something sane here is to approximate what the other frameworks are doing, which is to create a completely different site root, and a directory structure that completely separates your public content from your code, and point Apache at the public dir, not the code root. Unfortunately this does nothing to mitigate the problem of someone breaking any URL rewriting you need going on at the global Apache config, nor does it make it any easier to deal with crazy rewriting rules in Apache.
Apache is great at serving content; Apache isn't the best choice anymore for serving applications.
People aren't rushing to make mod_* for other languages because it implies a lot of behavior (by nature of it being served through Apache) which isn't really the best idea for security.
Having a structure that mixes the code files, templates (let's ignore mixing of logic and presentation), and static content all in the same publicly accessible location is just asking for security problems.
You can lock down what's accessible or not based on file extensions, but that's through a config that's not part of the deployment (Apache conf) so it's not as easily controlled in your code, or if it is part of the deployment (htaccess), can be affected or overridden by directives nowhere near your code (Apache conf). It's fun when someone breaks the php loading directives in the Apache config and your code starts showing as plain text. You made sure not to hard-code ANY credentials in your PHP files that are publicly reachable, right? Your config isn't publicly reachable, is it?
The closest you are going to get to something sane here is to approximate what the other frameworks are doing, which is to create a completely different site root, and a directory structure that completely separates your public content from your code, and point Apache at the public dir, not the code root. Unfortunately this does nothing to mitigate the problem of someone breaking any URL rewriting you need going on at the global Apache config, nor does it make it any easier to deal with crazy rewriting rules in Apache.
Apache is great at serving content; Apache isn't the best choice anymore for serving applications.
>Apache is great at serving content; Apache isn't the best choice anymore for serving applications.
What is?
What is?
To clarify, it's not the best choice for serving applications where Apache works as anything but a proxy.
For what's best, take your pick of any framework that entirely decouples the application directory structure from the routes and keeps the logic for it all completely internalized. All logic for how URI's are handled should be within the application configuration or code. Something written in the target language will probably provide far more benefits than whatever is lost through Apache.
Whether Apache is in the path to your application is irrelevant, whether Apache does anything except note that a request should be handled by another application and hand the entire request off without change is not.
For what's best, take your pick of any framework that entirely decouples the application directory structure from the routes and keeps the logic for it all completely internalized. All logic for how URI's are handled should be within the application configuration or code. Something written in the target language will probably provide far more benefits than whatever is lost through Apache.
Whether Apache is in the path to your application is irrelevant, whether Apache does anything except note that a request should be handled by another application and hand the entire request off without change is not.
Oh I see. I'm a beginner programmer and I just started learning PHP with Apache yesterday. I was up until 3AM installing and configuring it all along with MySQL and MyPHPAdmin last night. I thought by your post that I should be learning something else instead ;-).
In some respects, Apache + mod_php is actually harder to get set up and working that some of the other frameworks, assuming it's not already configured for your box (many linux distros include packages so "it just works").
Generally the application itself. Listening on an http port or a unix socket is pretty easy in most modern languages. Then use a normal HTTP server like apache to listen to incoming connections and proxy them on to whatever port on localhost your application is listening to.
Because mod_php is one of the main things that said hackers don't like about PHP. 1 file to 1 url does not scale to even small blogs, and using mod_rewrite to handle routing is both more complicated and less powerful than port forwarding to an app server and letting it handle urls in application code.
I always hear people say this, but I've used both a fair bit and `rails s` plus port forwarding is an order of magnitude easier than fighting with apache's vhost config.
I always hear people say this, but I've used both a fair bit and `rails s` plus port forwarding is an order of magnitude easier than fighting with apache's vhost config.
I think you are simplifying a bit. AFAIK, the slow performance of mod_php is a result of the massive memory foot-print that each Apache worker process will have.
The operating system can cache hundreds of 10 KB PHP files without problem, it doesn't make a difference how many files you have when they are all small and cached.
So, in conclusion, I propose that PHP performance is OK if you use something like php-fpm.
The operating system can cache hundreds of 10 KB PHP files without problem, it doesn't make a difference how many files you have when they are all small and cached.
So, in conclusion, I propose that PHP performance is OK if you use something like php-fpm.
> 1 file to 1 url does not scale to even small blogs,
I suspect you are aware of this, but using URL parameters it is quite easy to make multiple urls map to the same file (i.e. `/foo/?abc=123` and `/foo/?abc=234`).
I suspect you are aware of this, but using URL parameters it is quite easy to make multiple urls map to the same file (i.e. `/foo/?abc=123` and `/foo/?abc=234`).
Of course you can, but most of the time you don't want /blog/index.php?slug=title-of-the-article, you want /blog/title-of-the-article. To do this in a CGI-style app (i.e. mod_whatever) you've got to mangle the URL in the webserver layer. This moves application logic out of the application and into a config file for some other program, so it would be bad even if Apache's rewrite syntax wasn't incomprehensible black magic.
It cuts both ways, too. CGI-style routing gives a URL to everything, whether you want to or not. Unless you explicitly disable it, visiting /blog/config/database_credentials.ini (or whatever) will happily serve that file to the client. Plus it allows any user to execute the code in any file in your system out of context. Admittedly this will probably either error out or do nothing, but can you guarantee that for every single code file in your whole tree?
It cuts both ways, too. CGI-style routing gives a URL to everything, whether you want to or not. Unless you explicitly disable it, visiting /blog/config/database_credentials.ini (or whatever) will happily serve that file to the client. Plus it allows any user to execute the code in any file in your system out of context. Admittedly this will probably either error out or do nothing, but can you guarantee that for every single code file in your whole tree?
Technically speaking you would need one single rule in your web server configuration that rewrites all urls to a single router.php file (for instance), and code there your own logic to handle urls in PHP. This is not very different from other server languages except for the fact that you are in control of the routing logic AND you can delegate it to a framework if you choose to do so.
I've been using this technique (single url rewrite rule, send everything to index.php, handle routing there) for some time and it's worked quite well for me.
I've been using this technique (single url rewrite rule, send everything to index.php, handle routing there) for some time and it's worked quite well for me.
The only rewrite rule you need is one to direct all requests to index.php. Then you just parse the URL in PHP to achieve /blog/title-of-the-article. What is the problem with this approach?
>1 file to 1 url does not scale to even small blogs
Huh? You can use a lightweight framework like CodeIgniter to immediately remove this problem.
Huh? You can use a lightweight framework like CodeIgniter to immediately remove this problem.
Yes, any half-decent PHP framework will have some solution for this. CodeIgniter, in particular, gets around it with a combination of .htaccess files in every root directory, index.html pages in every subdirectory, and a boilerplate `defined('BASEPATH') OR exit('No direct script access allowed');` snippet at the top of every file. As long as the developer continues this convention through all their additions, this works quite well and is very secure and stable. It's also completely unnecessary. And it breaks if you want to host under nginx or lighttpd or anything that's not apache.
The point is that this is a problem web frameworks don't have to have in the first place. It is relatively easy to fix, if you know how, but it creates boilerplate code and adds potential for security holes for literally no benefit. The ability to heal a self-inflicted wound is a poor substitute substitute for not being injured in the first place.
The point is that this is a problem web frameworks don't have to have in the first place. It is relatively easy to fix, if you know how, but it creates boilerplate code and adds potential for security holes for literally no benefit. The ability to heal a self-inflicted wound is a poor substitute substitute for not being injured in the first place.
The downloadable distribution of CodeIgniter and many other PHP frameworks have those file and boilerplate to protect badly configured Apache setups where the user just unzips the downloaded distribution into public_html. If you have .php files handled by PHP, or you have the mod rewrite htaccess rules enabled, the PHP files won't be exposed to the user.
None of these are necessary if you have properly configured your web server.
None of these are necessary if you have properly configured your web server.
I really like the Javascript Weekly / HTML5 Weekly newsletters... since I'm (theoretically, anyway) a PHP dev, this will be a nice addition.
I'm not fond of PHP, but I don't know it as well as Ruby and Python. Still, I like to read about new technologies concerning PHP. I use HN to discover new stuff, but HN is a poor resource concerning PHP. HN has tremendous vocal disdain for PHP. Every PHP thread transforms into "Why I like or dislike PHP" instead of actual discussion regarding new technologies or libraries. What's worse is the debates feel like I've warped 10 years past because there is nothing ever new to them. People complain about the old things of PHP and never talk about the new things.
Put simply, even though I don't know PHP that well I feel like maybe it has potential and can actually do good in the right hands, but HN brainwashes you into thinking PHP is the worst.