PSR stands for PHP Standards Recommendation - these are documents which lay out how the PHP community has agreed things will be done. The standards are developed by the FIG (Framework Interoperability Group), which draws members from all the major frameworks and tools built in PHP. Since they have been very widely adopted around the PHP world, including in Drupal, I thought it might be nice to give a quick recap of which standard relates to what. They have rather unmemorable numbers rather than names, which can make it hard to keep track!
Why are there two autoloading standards? When the first PSR was published, PHP 5.3 was new and therefore so was the namespaces feature. This first standard made some really excellent ground rules for naming, and also enabled us to begin to mix-and-match libraries and components from different frameworks in the same project.
PSR-4 is a valuable update to the original PSR-0 standard, which makes better use of namespaces and allows for multiple autoloaders in a single package. Drupal 8 is standardised on PSR-4, which basically states:
This covers the main points, but if you want, you can read the whole PSR-4 Autoloader Standard.
There are two recommendations for coding standards as well? At this point you would be excused for wondering whether these FIG people really just enjoy busywork! In fact, this is a really sane distinction.
PSR-1 deals with fundamental issues that will affect external users of your code. So it covers correct naming (including case sensitivity) of classes and methods, for example. It also dictates that short tags should never be used (they were removed in PHP 5.4, but this won't bother Drupal people as apparently they have never been acceptable here!). Finally, it makes the distinction that any given file should contain either functionality or output; the two should never be mixed.
PSR-2 is about the coding style of your project: a standard way of laying things out to improve readability for developers. It states how much space belongs around opening curly braces, namespace declarations, and control structures. It also lays out the correct ordering of the various parts of a method declaration, for example:
abstract public function doCoolStuff()
is correct; the abstract keyword must also be first. However for static methods:
public static function getCategoryChoices()
would be required. Adopting these standards does take time and energy but being able to read everyone's code equally easily is well worth it. Also: 4 spaces is the answer to the eternal question of "tabs or spaces?".
Best of all, both these standards are super easy to check, since newer versions of PHP Code Sniffer ship with both standards built it. So basically: no excuses!
Read about them both in full:
When I talk about OOP and namespaces, I always point out that every framework has a Logger class - but in this brave new world of picking the best libraries from all the available options, that's a problem. Enter PSR-3, which defines a set of interfaces that these classes can use. Once your code is expecting a PSR-3-compatible Logger, you can remove one and replace it with another – without requiring any changes in your code.
The full PSR-3 Logger Interface Standard recommendation document also includes some interfaces. Those psr/log packages are available using Composer via Packagist. You'll see that log package is a dependency of pretty much any other package in PHP that has logging functionality, which is ace.
The remaining PSRs (5-7) are not yet official at the time of writing, but they're taking shape enough for me to tell you what's going to be in them (and you can check their progress on GitHub).
PSR-5 relates to the correct way to document our code in comments. This standard is still under development but will allow for new, alternative documentation-parsing tools to be developed since all our inside-the-code documentation will conform to this standard.
PSR-6 will standardise the way we implement caching libraries. Such a common element in any framework - and just like the loggers, we'll be able to pick the best one for our application, or even change them later on. It is a step ahead of PSR-5, already in the review phase, meaning that it is preliminarily complete but feedback is being sought before it is accepted by the FIG.
PSR-7 relates to HTTP messaging and is also in the review phase. This one is going to be very interesting since almost every project has objects that represent a request and a response. Being able to pick between different implementations will bring a new level of flexibility to our development choices. This standard is shaping up really well; it may take time for the new interfaces to be adopted in a lot of projects since the Request/Response objects are fairly central components, but I'm sure it will come.
As a PHP developer myself, I have a lot of respect and gratitude for the excellent humans of the FIG who spend time staring at these documents and considering all the possible implications. Together as a community, we can achieve so much, and having shared, agreed-upon standards is a cornerstone of our bright future.
Drupal Developer having 9+ year experience, implementation and having strong knowledge of technical specifications, workflow development. Ability to perform effectively and efficiently in team and individually. Always enthusiastic and interseted to study new technologies
Giả sử bạn là 1 trong 100 triệu trang web trên thế giới. Vậy bạn làm thế nào để trang web của mình có thể dễ dàng được tìm thấy.
It's been a while since I've sat down and tried to write a module from scratch in Drupal 8. I've dabbled here and there in the various already existing modules but there's always something interesting about just trying to write that simple
If you site is new, this might not be too much of a problem. However, as your site grows, it will increasingly be seen as a valuable target for spammers. If they succeed in placing links on your site, they may get a couple of benefits:
