PHP & Web Development Blogs

Halloween is filled with ghouls, ghosts, zombies and lots of other spookiness, but the scariest thing ever is FOMO. It’s conference season and several have their call for papers out (including us at Nomad PHP :D). This is the perfect time for you to share your knowledge with the community. Whether it’s your first time or 100th time - it can be scary to put yourself out there and do a talk, but worse than that is not taking the chance and submitting your talk and doing the presentation. Plus, many of these events host lightning talks (short 5-15 minute talks) - meaning you can test out your talk risk free ;)

So here is your chance - submit for one or submit for all of them. May the odds be ever in your favor!

Fosdem 2019

First we have Fosdem 2019 which will take place on February 2 & 3 in Brussels,Belgium. Some facts about this call for papers:
*Deadline: November 3, 2018
* Presentations are expected to be 50 minutes long (including audience questions) and should cater to a varied technical audience. For examples check out youtube.
*Submit your proposals via Pentabarf: https://fosdem.org/submit.
* The conference covers reasonable travel expenses agreed upon in advance as well as arranges accommodations

Midwest PHP 2019

Next up we have Midwest PHP which will take place on March 8 & 9 in Bloomington, Minnesota.
*Deadline: November 15, 2018
* There is a speaker package included (conference pass, 2 hotel nights, airfare/travel - $500 max, lunch, etc.)
* Make sure the talk title and abstract define the exact topic and what you hope people will learn from it.
* Recommended to submit more than one talk because it can increase your chances of one of them being picked.
*Submit your talk here: [https://cfp.midwestphp.org/] (https://cfp.midwestphp.org/)

Longhorn PHP

Next we have Longhorn PHP which will take place on May 2 (tutorial day) then MAy 3 &4 (conference) in Austin, Texas.
*Deadline: December 15, 2018
* For all speakers, you'll get a full conference pass (tutorial day and main conference days), including access to lunch, after-parties, and any other activities included in the conference.
* For speakers remote to the Austin area, we'll provide 3 nights at the speaker hotel (4 nights if presenting a talk and a tutorial) near the conference venue.
* For speakers outside Texas, we'll book you an Economy or equivalent round-trip airfare on a flight into Austin we'd be comfortable taking ourselves (we're conference speakers too!). Plus, we'll arrange transportation between the Austin airport and the speaker hotel.
* Three different session lengths: 3 hour tutorials, 60 minute talks, and 30 minute talks.
* It doesn't have to just be a PHP related talk. For more information on talks click here.
*Submit your talk here: https://cfp.longhornphp.com/.

Laravel Live India 2019

Then we have LaravelLive India 2019 in Mumbai, India.
*Deadline: December 31, 2018
* Talk length is 30 minutes - Q&A up to the presenters discretion but would be included in the 30 minute time limit.
* Talks will be recorded and distributed for free as well as the presentation slides.
* Looking for a range of talks from PHP (security, testing and frameworks), web development, HTML5, JavaScript, mobile development, emerging technologies and non-technical proposals that will appeal to developers.
*Talk guidelines: Objective with clear expectation for audience, short and to the point description, mention of employer is only allowed at the beginning of the content and background image/wallpaper shouldn’t include company name/logos.
*Submit your talk here: [https://www.papercall.io/laravellive-india] (https://www.papercall.io/laravellive-india)

Nomad PHP

(you know you want to)

Last but not least - this is an ongoing call for papers. This is perfect if you want to present from the comfort of your office, home or really wherever you are. It’s via RingCentral meetings and will be live and recorded. This is for none other than Nomad PHP.
*Deadline: Anytime :D
* Talk length: 45 - 60 minutes.
* Talks should be unique to Nomad PHP and not available in video format online.
* Talk should not be recorded or made available elsewhere online for at least 3 months following your talk.
* The talk will be featured on our page and promoted via social media.
* Speakers will receive a financial stipend.
* Upon being selected we will reach out with further details.
*Submit here: [https://www.papercall.io/nomadphp] (https://www.papercall.io/nomadphp)
Now that you have some information - it’s the perfect time to take it all in and get started on your talk proposals :)! Looking forward to seeing all the amazing talks that will be coming out!!!

INTRO

If you are working as a PHP software developer, there is an extremely high chance that all of your application, you’re currently working on, using frameworks of any kind.
PHP community developers of all levels worship frameworks since there are big historical and practical reasons for that.

Historical reasons

Since early PHP versions, developers were disreputable because not everybody considered PHP as a programming language, similar to JavaScript a couple of years ago. While strong type language existed decades ago, PHP continues to be soft type since now, only in version 7 basic types were introduced. There is also a matter of the fact that you can script in PHP without using a single object.

But that opened a space for frameworks to step in and introduce themselves as a tool or standard which will shape projects, give them right and order, introduce structure and rules.
And finally, they did. Frameworks are good examples of nice structures, using all available new features PHP offers with every version, enforcing some good practice, etc.

Practical reasons

The framework offers a lot of common problems already solved. They offer a nice ecosystem for other developers to contribute and plug their components. There is a lot of online resources for learning and stay updated about any particular framework. Also, what every framework community tries very hard, is to make setup and usage easy.

WHEN PHP FRAMEWORKS SUCKS

I recently had the opportunity to give a talk on a conference and one meetup about why PHP framework sometimes sucks. Sometimes things we see in framework tutorials does not seem to be very much aligned with some object-oriented standards we are striving to enforce, and with basic clean code guidelines. On the other hand, there is nothing wrong with using a framework, if you use it right.

This article is the first "pilot" article in this series. In every new blog in this series, we will go more in-depth about every specific topic I covered during my presentation.
I'm very excited to share this knowledge, as I saw many developers suffer from bonded-to-framework disease.

https://twitter.com/damnjan/status/1058306144458956800

I won’t spend much time here on any particular framework discussion. This series will be just a guide on how to unbind yourself from frameworks and use them as a tool, instead of being independent.

**Here is the link to the presentation slides.**

I've been using PHP since 1996. I've been paid to use PHP for the last 12 years.

I am a big fan of the language and it's amazing to see just how much it's changed in the last 24 years.

I finally joined NomadPHP because in the current climate, I feel like I need to give back to the community, and share some of the things that I've learned over the years.

In my current role, I’m working with a large pool of developers from many different backgrounds and skill levels to maintain a large pool of php based tools for a web hosting company.

These tools range from in house tools for support and sales, to customer facing tools for automation and quality of life applications.

I’m a big fan of frameworks, specifically Laravel. I discovered Laravel 4.0, decided to give it a try and immediately realized how valuable it could be as a way to prototype quickly. It has since grown to a tool in my toolbox I use regularly for medium and small applications simply as a time saver.

Please feel free to reach out to me if you have any questions, or what to pick my brain. I can’t promise I know it all, but over the years I’ve learned how to solve problems and find answers.

Thank you, and I look forward to what may come.

Chris.

It seems like this question gets asked every year, as for some reason the perception surrounding PHP is that it is a language used by hobbyists, or a dying language - a programming language on its way out.

Before we take a look at "is PHP being used less," let's start with some critical points to consider when choosing a programming language to learn/ invest in.

PHP powers ~80% of the web

The first point is how popular PHP is as a program language. Recently in a podcast a debate around PHP was raised, with the question being is it an "enterprise" language. The argument against PHP is that it is not widely adopted by enterprises for enterprise application development - or apps that are traditionally developed in Java or .Net.

The key here is understanding that every tool has its strengths and weaknesses, and there are times where using a compiled language such as Java is a smarter move than using PHP. As always, you want to choose the right tool for the job, and PHP as a programming language excels for web applications. That's why today it powers nearly 80% of the websites on the internet! I want to repeat that number, nearly 80% of websites on the internet!

In the podcast, after the initial argument that PHP was not an enterprise language, I had one question to ask - "can you name one enterprise that doesn't use PHP?" Despite the misconception that PHP is not an enterprise language, nearly every enterprise utilizes PHP in some fashion (many for their website, blog, or internal tools). While PHP may not power the app they offer as a service (although for many companies it does), it powers just as critical of offerings that help drive success for the company.

PHP made Yahoo, Facebook, and Tumblr possible

It's not just personal blogs running on a WordPress install, or small sites running on Drupal (btw, both of these power high traffic, well known web properties), but PHP actually makes development for the web easier and faster. Because it is not a compiled language and is designed to scale, companies are able launch faster, add new features as they go, and grow to enormous scale.

Some of the sites that started with PHP include Yahoo, Facebook, Tumblr, Digg, Mailchimp, and Wikipedia! But it's not just older platforms that started off and have grown to scale with PHP - Etsy, Slack, Baidu, Box, and Canva also got started with PHP! Read why Slack chose PHP

In fact, according to BuiltWith, PHP powers 53.22% of the top 10k websites!

Programming languages don't just disappear

Understanding the prevalence of PHP today, and how often it is used is critical to understanding the longevity of PHP. Despite the radicalized idea, programming languages (and thus programming jobs) do not just disappear overnight. Today you can still find jobs writing code used in mainframes - such as Fortran or Cobol.

As long as companies have applications that use PHP, they'll need someone who knows PHP to maintain the application. And with PHP actively being developed and maintained (PHP 8 having just been released), and PHP powerhouses like WordPress, Drupal, SugarCRM, and others powering websites and apps around the world, it's a safe bet PHP won't be going anywhere anytime soon.

But with the basics out of the way, let's look at how PHP has faired over the years.

PHP usage over the years

While there is no exact measurement that determines how programming languages are ranked, there are several different rankings we can look at to see how a language has evolved over the years, and where it ranks today.

GitHub's most popular programming languages

Every year GitHub releases a report of the most popular languages being used to create repositories on GitHub.com. While this isn't an exact way to quantify a programming language, it does help us understand what languages developers are using and promoting for their applications. It also helps us see how lively the community itself is.

In 2014, PHP was ranked as the 3rd most popular programming language, being beat out only by JavaScript and Java. With the emergence of Typescript, C# moving open source, and increased usage of Python for AI - PHP did drop - and was the 6th most popular programming language on GitHub for 2020.

PHP's ranking on the Tiobe index

Another index for software popularity is the Tiobe index, which bases their ratings off of the number of search engines for programming languages. This index is heavily relied on by companies when making programming and investment decisions, especially in developer marketing.

Like with GitHub, PHP has also seen a decline in the Tiobe index. Ranked 8th last year for all languages, PHP dropped to 9th place, being outranked by the C languages (C, C#, C++), Java, Visual Basic, Python, JavaScript, and Assembly. However, to put the rankings in contrast, PHP is 9th out of the 274 languages Tiobe tracks, and bests SQL, Ruby, Groovy, Go, and Swift.

You can see the latest Tiobe index (updated monthly) at: https://www.tiobe.com/tiobe-index/

PHP's ranking on BuiltWith

The last model we'll look at is BuiltWith. BuiltWith scans website headers to determine what a website is powered by, and like GitHub and Tiobe provides a ranking of programming language popularity and trends.

Builtwith provides an interesting perspective in that we can see an explosion of sites being built with PHP (nearly tripling from 2013 to 2016) before dropping and normalizing in 2017. From 2017 to present, the number of sites using PHP has remained almost constant.



This suggests (as with what we've seen with GitHub and Tiobe) that other languages have grown in popularity, such as JavaScript and Node.js. This doesn't mean that PHP is no longer being used or relied or, but rather that there is more competition and that there are other viable options whereas PHP stood alone at times in terms of being the goto language for web development.

Indeed, when we look at how PHP ranks amongst all technologies on BuiltWith, PHP receives the following BuiltWith awards:

• The most popular on the Entire Internet in Frameworks category.

• The most popular in the Top 10k sites in Frameworks category.

• The most popular in the Top 100k sites in Frameworks category.

• The most popular in the Top 1 Million sites in Frameworks category.

Conclusion

PHP's popularity has dropped from its height 10 years ago, however it still remains the most popular programming language powering the web. It's important to remember that every tool has pros and cons, and some of the bad rap PHP gets is when compared to languages designed to accomplish tasks or build programs that PHP was never designed to.

It's also important to remember a lot of early criticism for PHP came from it being a procedural programming language and not encompassing Object Oriented Programming capabilities. These capabilities were added in PHP 4 and with PHP 7 & 8 OOP has become a staple of the PHP language.

PHP is a viable, powerful language used by nearly every enterprise and many businesses large and small. In fact it powers over 50% of the top 10,000 websites on the web! With such large usage, popular tools such as WordPress, and an active community, it is safe to assume that PHP will remain a prominent language for years to come.

Composer is the way that that PHP developers manage libraries and their dependencies. Previously, developers mainly stuck to existing frameworks. If you were a Symfony developer, you used Symfony and libraries built around it. You didn’t dare cross the line to Zend Framework. These days however, developers focus less on frameworks, and more on the libraries they need to build the project they are working on. This decoupling of projects from frameworks is largely possible because of Composer and the ecosystem that has built up around it.

Like PHP, Composer is easy to get started in, but complex enough to take time and practice to master. The Composer manual does a great job of getting you up and running quickly, but some of the commands are involved enough so that many developers miss some of their power because they simply don’t understand.

I’ve picked out five commands that every user of Composer should master. In each section I give you a little insight into the command, how it is used, when it is used and why this one is important.

1: Require

Sample:

$ composer require monolog/monolog

Require is the most common command that most developers will use when using Composer. In addition to the vendor/package, you can also specify a version number to load along with modifiers. For instance, if you want version 1.18.0 of monolog specifically and never want the update command to update this, you would use this command.

$ composer require monolog/monolog:1.18.0

This command will not grab the current version of monolog (currently 1.18.2) but will instead install the specific version 1.18.0.

If you always want the most recent version of monolog greater than 1.8.0 you can use the > modifier as shown in this command.

$ composer require monolog/monolog:>1.18.0

If you want the latest in patch in your current version but don’t want any minor updates that may introduce new features, you can specify that using the tilde.

$ composer require monolog/monolog:~1.18.0

The command above will install the latest version of monolog v1.18. Updates will never update beyond the latest 1.18 version.

If you want to stay current on your major version but never want to go above it you can indicate that with the caret.

$ composer require monolog/monolog:^1.18.0

The command above will install the latest version of monolog 1. Updates continue to update beyond 1.18, but will never update to version 2.

There are other options and flags for require, you can find the complete documentation of the command here.

2: Install a package globally

The most common use of Composer is to install and manage a library within a given project. There are however, times when you want to install a given library globally so that all of your projects can use it without you having to specifically require it in each project. Composer is up to the challenge with a modifier to the require command we discussed above, global. The most common use of this is when you are using Composer to manage packages like PHPUnit.

$ composer global require "phpunit/phpunit:^5.3.*"

The command above would install PHPUnit globally. It would also allow it to be updated throughout the 5.0.0 version because we specified ~5.3.* as the version number. You should be careful in installing packages globally. As long as you do not need different versions for different projects you are ok. However, should you start a project and want to use PHPUnit 6.0.0 (when it releases) but PHPUnit 6 breaks backwards compatibility with the PHPUnit 5.* version, you would have trouble. Either you would have to stay with PHPUnit 5 for your new project, or you would have to test all your projects to make sure that your Unit Tests work after upgrading to PHPUnit 6.

Globally installed projects are something to be thought through carefully. When in doubt, install the project locally.

3: Update a single library with Composer

One of the great powers of Composer is that developers can now easily keep their dependencies up-to-date. Not only that, as we discussed in tip #1, each developer can define exactly what “up-to-date” means for them. With this simple command, Composer will check all of your dependencies in a project and download/install the latest applicable versions.

$ composer update

What about those times when you know that a new version of a specific package has released and you want it, but nothing else updated. Composer has you covered here too.

$ composer update monolog/monolog

This command will ignore everything else, and only update the monolog package and it’s dependencies.

It’s great that you can update everything, but there are times when you know that updating one or more of your packages is going to break things in a way that you aren’t ready to deal with. Composer allows you the freedom to cherry-pick the packages that you want to update, and leave the rest for a later time.

4: Don’t install dev dependencies

In a lot of projects I am working on, I want to make sure that the libraries I download and install are working before I start working with them. To this end, many packages will include things like Unit Tests and documentation. This way I can run the unit Tests on my own to validate the package first. This is all fine and good, except when I don’t want them. There are times when I know the package well enough, or have used it enough, to not have to bother with any of that.

Many packages create a distribution package that does not contain tests or docs. (The League of Extraordinary Packages does this by default on all their packages.) If you specify the --prefer-dist flag, Composer will look for a distribution file and use it instead of pulling directly from github. Of course if you want want to make sure you get the full source and all the artifacts, you can use the --prefer-src flag.

5: Optimize your autoload

Regardless of whether you --prefer-dist or --prefer-source, when your package is incorporated into your project with require, it just adds it to the end of your autoloader. This isn’t always the best solution. Therefore Composer gives us the option to optimize the autoloader with the --optimize switch. Optimizing your autoloader converts your entire autoloader into classmaps. Instead of the autoloader having to use file_exists() to locate a file, Composer creates an array of file locations for each class. This can speed up your application by as much as 30%.

$ composer dump-autoload --optimize

The command above can be issued at any time to optimize your autoloader. It’s a good idea to execute this before moving your application into production.

$ composer require monolog/monolog:~1.18.0 -o

You can also use the optimize flag with the require command. Doing this every time you require a new package will keep your autoloader up-to-date. That having said, it’s still a good idea to get in the habit of using the first command as a safety net when you roll to production, just to make sure.

BONUS: Commit your composer.lock

After you have installed your first package with composer, you now have two files in the root of your project, composer.json and composer.lock. Of the two, composer.lock is the most important one. It contains detailed information about every package and version installed. When you issue a composer install in a directory with a composer.lock file, composer will install the exact same packages and versions. Therefore, by pulling a git repo on a production server will replicate the exact same packages in production that were installed in development. Of course the corollary of this is that you never want to commit your vendor/ directory. Since you can recreate it exactly, there is no need to store all of that code in your repo.

It is recommended that also commit your composer.json. When you check out your repo into production and do an install, composer will use the composer.lock instead of the composer.json when present. This means that your production environment is setup exactly like your development environment.