The TutsPlus.com site has posted the latest in their "Programming with Yii2" series of tutorials with this new article looking at features for the application useful to build community around the site.

In today's tutorial, I'm going to show you how to extend Yii to easily mimic a site like Reddit with voting, comments, and sharing.

[...] I built some my latest Twitter API episodes on the early version of this platform, following friends on behalf of users and analyzing our followers. The site I described in those, Twixxr, forms the foundation of my Yii customization work.

So adding core functionality like voting, comments and sharing makes so much sense. As you expand your Yii codebase with these kinds of features, building new sites becomes faster, easier and increasingly powerful.

He then spends the rest of the article showing how to use three Yii2 plugins to help provide the community functionality he needed: a voting extension, a plugin for integrating Disquis and a "social extension" for other social plugins and widgets. He shows how to get these extensions installed and what code updates you'll need to make to use them across the application. This also includes screenshots of the results so you can be sure that you're on the right track.

In a recent RFC that's been proposed and is now up for voting, the suggestion has been made to drop the var keyword in PHP 7.1 and completely remove it in PHP 8 (made a bit redundant buy the public keyword in classes). Evert Pot, however, disagrees and suggests dropping public instead.

A PHP RFC vote has started to deprecate the var keyword in PHP 7.1 and remove it in PHP 8. At the time of writing, there 23 who say it should be removed, and 18 who say it should not. [...] I’d like to offer a different opinion: I think people should be using var instead of public. I realize that this is as controversial as tabs vs. spaces (as in: it doesn’t really matter but conjures heated discussions), but hear me out!

He goes through an example on one of his own projects, showing how he's mostly removed the public level of exposure from his development (using final and statics instead). He then suggests three common thoughts he sees people having being in favor of dropping var versus public:

• #1: Everyone doing the same thing is good
• #2: It’s ugly!
• #3: The public keyword is useful to convey intent

He also points to one place where he does see the need for a public but also suggests that in that case var would do juts fine too.

As Matthew Weier O'Phinney has posted, the PSR-7 PHP-FIG proposal is in the voting stages. The PSR-7 standard defines a unified interface for working with HTTP requests and responses.

As of a short bit ago, PSR-7 (meta) — HTTP Message Interfaces — is now in the voting phase! If you are a voting member of PHP-FIG, I urge you to read the specification and meta document now, and cast your vote accordingly.

I have written previously on the need for HTTP message abstractions, and also detailed how PSR-7 works. Those posts are still valid (I've kept the latter updated with all changes!). Since the review period, my sponsors and I have been looking over feedback and comments to see if any changes were needed. Fortunately, we've not found any substantive changes were really necessary; we have, however, made a few clarifications.

He clarifies some things around:

• why base path concerns are not represented in the ServerRequestInterface or UriInterface
• a note that UriInterface::getPath() MUST return the string "/" if the path is empty
• that UriInterface implementations MUST percent-encode reserved characters in paths and query strings, per RFC 3986
• why StreamableInterface is mutable, and provided guidelines to implementors and consumers regarding how and when to use writable streams
• the addition of several sections to the meta documentation detailing solutions to common stream-based concerns

He also gets into a bit more detail about streams, base paths and some of the overall outcomes if the PSR-7 proposal passes (which it looks like it will so far).

If you adopt PSR-7, will you need to change your code? Almost certainly. The goal of PHP-FIG is to improve interoperability between projects, and PSRs typically attempt this via codification of what member projects are already doing.

The PHP-FIG has officially started the voting process for the PSR-4 autoloading standard that would provide an interface to make autoloading a bit more standardized across applications.

The purpose is to specify the rules for an interoperable PHP autoloader that maps namespaces to file system paths, and that can co-exist with any other SPL registered autoloader. This would be an addition to, not a replacement for, PSR-0.

The current autoloading standard definition (PSR-0) still allows for the use of the underscore in class names to resolve to directory paths in the application's files. In this new standard, that allowance is gone, relying only on the actual namespacing to define package pathing. This "package-oriented autoloading" is set to help move PHP package development forward into a more standardized structure.

According to this recent discussion on the PHP-FIG mailing list, the Yii framework project has tossed their hat into the ring and joined the PHP-FIG.

As Alexander Makarov writes in his post:

I'd like to apply for voting membership because I feel that fig is very important and that I have enough experience to make the final result better.

All of the votes from current members have been "+1" for the project's inclusion into the standards group including ones from several other well-known projects (like Zend Framework, PEAR and Doctrine).

Phil Sturgeon has a new post about some of the progress the PHP-FIG is making (the PHP framework interoperability group) and how some of the more recently proposed standards...and a workflow he thinks can help keep things from fading like they are now.

For the last two years the ML has been chock full of different discussions about potential PSRs that could be worked on. [...] This to me is the central point of the PHP-FIG as by defining these standards it can stop the need to build 6 different damn adapter classes for your composer package if you want it to work with Buzz, Guzzle, Zend HTTP, Curl, Whatever). [...] It became apparent to me that the PHP-FIG wasn't going to get all that far as things stood. I actually saw quite a few problems with the workflow.

To try to help resolve these problems, Phil has proposed a bylaw that aims to help (and has since been voted in as part of the process). The flow has several steps that a PSR proposal has to go through, all tracked by co-sponsors, one being the main coordinator. It goes through a pre-draft, draft, review and acceptance phases. There's also some points in there about attribution, the use of the voting protocol and the flow of the voting process.

PHPClasses.org has posted the latest episode (#34) of their "Lately in PHP" podcast series. In this episode they talk about the current PHP voting process for features and a possibly better one that was proposed.

This was one of the main topics discussed by Manuel Lemos and Cesar Rodas on the episode 34 of the Lately in PHP podcast. They also discussed about the latest PHP releases, updating PHP with minimized downtime, as well how brilliant are some developers for creating pure PHP components that overcome PHP limitations without upgrading to a newer PHP version.

You can listen to this latest episode either through the in-page player, by downloading the mp3 or subscribing to their feed. If you'd like to see the video recording of the session you can check that out over on YouTube.

With some of the recent talk about the consistency of naming methods in PHP (or lack thereof) Phil Sturgeon has put together some ideas about why this (and unicode) changes aren't happing in the language.

PHP is well known for having an inconsistent API when it comes to PHP functions. Anyone with an anti-PHP point of view will use this as one of their top 3 arguments for why PHP sucks, while most PHP developers will point out that they don't really care. [...] Another big thing that anti-PHP folks laugh about is the lack of scalar objects, so instead of $string->length() you have to do strlen($string). ANOTHER thing that people often joke about is how PHP 6.0 just never happened, because the team were trying to bake in Unicode support but just came across so many issues that it never happened.

He shares an "obvious answer" to the problems and shares a theory as to why it's not happening - that no one is really working on out (outisde of this POC) and some of the handling with the recent property accessors RFC. He finishes off the post with three more points, all related to the results of the voting - little points seem to get voted in easier, the representation of developers in the process and that at least one of the "no" votes had to do with not wanting to maintain the results.

Making changes to this language should not be blocked just because a quiet minority of the core team don't like the idea of being asked to do stuff.

Be sure to check out the comments on the post - there's lots of them, so be sure you have some good time to read.

As is mentioned in this new post to PHPMaster.com, the PHP standards group is officially in the voting process on two new standards (PSR-0 being the first) setting up some standard development practices for PHP applications - PSR-1 and PSR-2.

They initially started out as one proposal but the initial round of voting didn’t yield a majority in favor. Participants did however see merit in various requirements the decision was made to split it into 2 proposals - one for mandatory interoperability and one for suggested style.

The PSR-1 standard proposes some basic coding standards (like namespacing structure and class/method naming definitions) and the PSR-2 standard covers similar things, but more in-depth with more recommendations.

If you want to find out how your application stacks up against this new standard, you can try out PHP-CS-Fixer (from Fabien Potencier) to see how many things need an update.

According to this new post on the Zend Developer Zone, the voting state of the Packt 2010 Open Source Awards has officially started and you can cast your vote in one of many categories (and maybe win a prize for your efforts).

The nomination stage is now closed and voting has begun in the 2010 Open Source Awards. [...] You can cast your vote here: http://www.packtpub.com/open-source-awards-home/voting-stage.

The categories for the awards this year are:

• Open Source CMS Award
• Hall of Fame CMS
• Most Promising Open Source Project
• Open Source E-Commerce Applications
• Open Source JavaScript Libraries
• Open Source Graphics Software

If you want more information or to cast your vote for any of the projects in these categories, go over to the Packt voting page and get your opinion heard.