PHP tags – once and for all. Yet again.

For those of us who have been using PHP since the early version 3 days and such, here is a modern day refresher for PHP tags:

If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.

And from the comment on the same page:

Since PHP 5.4 the inline echo <?= ?> short tags are always enabled regardless of the short_open_tag (php.ini) setting.

For me personally, closing PHP tags are a part of muscle memory.  I’ll have to unlearn that, I guess.  And in regards to the inline echo tags, I was under the impression that they are being phased out together with the other short tags (<? … ?>).  Apparently, I was wrong.  They are here to stay.  Which explains why there are in PSR-1, PSR-2, and in CakePHP 3 (which requires PHP 5.4.16 and fully adopts PSR-2) in particular.

Validating website HTML, CSS, and links from the command line

When working on a long running projects, it’s easy to lose track of HTML and CSS standard compliance.  Also, link rot is a common occurrence.  Gladly, there are command line tools that can be executed on a regular basis (think weekly or monthly cron jobs), that would check the site and report any issues with it.  Here is one of the ways.

Installation on Fedora:

yum install linkchecker
yum install python-tidy
yum install python-cssutils

Example command line:

linkchecker -t20 --check-html --check-css https://mamchenkov.net

Obviously, check the manual of linkchecker for more options.

Is INPUT tag valid when used outside of a FORM tag?

Here is an update from the “learn something new every day” department – using <input> tag outside of (or, in other words, without) <form> tag is perfectly valid.  It’s valid in the newest HTML5 spec, and it was valid with earlier versions of HTML and XHTML too.

Interesting, that today was the first time I came across this, after doing HTML for almost 20 years.

Aggregating feeds isn’t all that simple

As I mentioned a few times, one of my first start-up ideas was an RSS aggregator.  It was back in 2005 or so, before Google Reader was even alive.  Bloglines was the coolest tool, if I remember correctly, and it sucked badly.  I got together with a few friends of mine and we started coding.  It was an interesting challenge both technically and aesthetically.  But we got it to the point where it actually worked and wasn’t all too bad.  It was a weird mixture of Python, Perl, and PHP though.

Eventually, it became too much work.  We couldn’t figure out how to monetize the thing.  And Google Reader was announced.  That sort of killed the project.

A few month back, when the announcement of Google Reader’s end of life came out, I looked at the alternatives and wasn’t pleased.  I thought with all the technical advances in the last few years, and with my own improved knowledge, I could attempt the task again.  Yes, I know, I am hopeless optimist in a lot of matters.

At least this time it took just a few days to convince me not to pursue the goal.  Alternatives are plentiful.  Each and every one of them is light years ahead.  I still don’t enjoy front-end development.  And I still have no clue as to how to monetize it.  So, the Subs Reader got frozen.  At least I got it all in frameworks, and left it in the Open Source state.  If I ever will have another try, I can pick up from here.

One of the biggest mistakes I’ve done the last time, was not documenting the project’s process at all.  I vaguely remember that I didn’t sleep for a few nights, trying to figure out all kinds of problems.  But what were they, I don’t remember.

Today, I came across a blog post which lists similar problems that I had to solve, but in greater number and variety.  Even if you aren’t thinking about writing your own RSS reader any time soon (or ever), you should still read through the Brian’s stupid feed tricks.  First of all, they clearly illustrate how much complexity is hiding in the details.  Secondly, they show non-standard is the web in general and RSS in particular.  If you do any kind of web crawling, you’d probably see half of the same issues in your application.  Thirdly, even if you aren’t crawling the web at all, but just code a web application or an API to one, you’ll many places where you can go wrong without noticing it.  All in all, it’s a great list of problems that everybody involved in web development can learn from.

Theme fixes, improvements, and polish

If you have a lot of attention for details, you probably noticed a few things moving around and changing on this blog in the last few days. You weren’t dreaming – I indeed moved changed a few things. Here is a round-up for those of you who enjoy these sort of things:

  • List of categories moved up. Since I am interested in and blog about many different things, I don’t blame you if you would like to skip some of them and read only things that you care about. I moved the list of categories higher up in the sidebar, so that you could jump directly to the topic of your choice.
  • Full posts in categories, tags, and archives. This should also make reading posts about specific things easier. You won’t need to jump to the full post page all that often now. Less clicks and all.
  • Category header images. Some categories (see Photography, Movies, and Technology for examples) will greet you with different header images (once again, thanks to Igor Gorbulinsky for his talent and time). This feature should help you out a bit while navigating the site – instant indicator of where you are.
  • Highlight of category name, tag, and search query. When you navigate to posts of a specific tag or category, you should see the term at the top of the page. Sometimes the term is highlighted, like, for example, in case of search query. Also, sometimes, you have a link to RSS feed which provides easier access to similar posts.
  • Improved RSS feed auto-discovery. Depending on where you are on the site, your browser will suggest a different set of RSS feeds to subscribe to. I’m trying to make these things as intuitive as possible.
  • Improved browser compatibility and standard compliance. A few small glitches here and there were fixed. All RSS feeds are valid now, except for those rare cases when content of specific posts causes problems. CSS is now valid and many warnings are fixed. HTML is now almost valid. There are a few issues which which are caused by WordPress bugs, but fixes for these seem to be available in the upcoming version of WordPress. In any case, it seems all theme and plugin specific issues were fixed.
  • Upgraded WordPress to version 2.3.3 .  This is the latest version with all the security fixes and such.

As you can see from the list above, all of these changes are rather cosmetic and can be classified as web site polish. None of them should cause any issues to you or your browser, and much of the misbehaving functionality should be fixed now.

If you have any ideas on suggestions on further improvements, or if you notice any misbehavior at all, please let me know.