PHP World - 2015 - Actually Modernizing WordPress

WordPress has a bad rap. Yes, it's deserved. The core architecture of WordPress reflects the period of its inception and its provenance as a blog engine. Recently, there's been a concerted effort to wrangle WordPress into a reasonable development environment. We'll discuss the tools and techniques that can be utilized to create an end-to-end development stack rivaling those found in modern frameworks like Laravel or Rails. Using tools like Bedrock, Capistrano, Toran, and Composer, we'll cover topics such as library management (including 3rd-party code), deployment, asset pipelines, and collaboration.

Transcript

1. EUGENE T. COOK PHP WORLD - NOVEMBER 18 ACTUALLY MODERNIZING WORDPRESS DEVELOPMENT
2. A BIT ABOUT ME Transactional and Start Up Attorney MBA - IT and 
 Operations Management Polymathic Technologist JD - Rule of Law in
 Developing Nations Shameless Plugs
4. SPECIAL THANK YOU
5. 5.2 25 12 WordPress was first released in May, 2003, making it 12 years old. Many of the legacy elements remain. 25% of the top 10 million websites are powered by WordPress. WordPress currently requires only PHP 5.2.4. Efforts are being made to work with hosts and migrate to newer versions of PHP, but reality of legacy code remains. THE WORDPRESS STATS
6. WP.ORG ISN’T IN IT FOR YOU PLUGIN AND THEME HELL NO CODE SEPARATION NO 3RD PARTY STANDARDS REPETITION LACK OF ABSTRACTION The default WordPress structure places custom development within the library itself. This makes dev difficult. WordPress’ strength is also its weakness. Trying to track and manage hundreds of plugins and themes is Sisyphean. WordPress predates the acceptance of abstraction best practices, and is an amalgam of all three MVC layers. Due to the manual nature of the standard WordPress workflow, there’s lots of repetitive work that is difficult to automate. This includes project building, updates, maintenance and deployment. The architectural ethos that governs core WordPress design decisions prioritizes legacy compatibility and the widest possible support. This is often in opposition to modern techniques. The vibrant “informal” market sustains a massive economy, but lack cohesion and convention. Third party libraries and packages are proprietary in all respects. COMMON COMPLAINTS
7. WordPress is user- centric in its design principles. Most of the recent dev minded development has happened outside of core, and often happens in spite on core decisions. WordPress has always considered backwards compatibility sacrosanct. WordPress’ adopted deviation from standard semantic versioning well established it would never see a major version rebirth. The WordPress codebase is written to the lowest common denominator. The suggested conventions often reflect that, such as serializing everything to reduce the number of queries. LEGACY COMPATIBILITY BROADEST SUPPORT USER CENTRIC WORDPRESS PHILOSOPHY
8. SO WHAT?! YOU CONTROL THE ENVIRONMENT WORDPRESS CAN BE TAMED
9. 12 QUICK TANGENT FAMILIARIZE YOURSELF WITH 12 FACTOR 1. CODEBASE 2. DEPENDENCIES 3. CONFIG 4. BACKING SERVICES 5. BUILD, RELEASE, RUN 6. PROCESSES 7. PORT BINDING 8. CONCURRENCY 9. DISPOSABILITY 10. DEV/PROD PARITY 11. LOGS 12. ADMIN PROCESSES
10. 0 WORDPRESS
11. Due to the nature of most WordPress projects, keeping the entire project in the code repository is unrealistic and unwieldy, The structure of WordPress also lends itself to having libraries and application code intermingled. Collaborative development within WordPress is notoriously difficult. Bringing on another developer can often take hours. How do you ensure that there is code parity amongst all of your project developers? How do you know you’re using the same plugin/theme versions? DEV ONBOARDING CODE PARITY VERSION CONTROL COMMON CHALLENGES
12. Consistent and safe deployments of new WordPress code can sometimes be difficult, especially if you’re deploying to multiple end points (E.g. load balanced). The beauty of WordPress is the extensive ecosystem of code, plugins and themes that are freely available. How do you properly manage these dependencies within your project? Often times you’ll need a commercial plugin or theme that isn’t available within the standard WordPress repo. How do you index, retain and make these dependencies available to your projects? DEPENDENCIES THIRD PARTY LIBS DEPLOYMENTS COMMON CHALLENGES
13. DRY DON’T REPEAT YOURSELF
14. How do you efficiently test your codebase with different versions of plugins, themes or WordPress? How do you manage these different configurations? The process of building your new WordPress project, selecting and installing dependencies and initializing can be repetitious and time consuming. Build predictably and quickly every time. Managing the configuration of WordPress across your different environments can be tedious, especially if your dev, staging and production environments have different security protocols. (E.g. different dependencies) NEW PROJECT BUILDS WP CONFIGURATION TESTING SWIMMING WITH WORDPRESS
15. AUTO MATE 3RD PARTY TORAN LEAN GIT BUILD COMPOSE R BUILD One of the most repetitive tasks in the WordPress lifecycle, and one of the most difficult to automate.
16. Bedrock is modularly-developed, modern WordPress stack that delivers many of the best practices discussed in this presentation out of the box.
17. 1 Environment Configuration Management Autoloader for Plugins and Non-WP PHP Libraries Predictable and Consistent Builds (Scripts) Library and Code Separation 2 3 4 BEDROCK Composer Foundation 5
18. GIT’TING STARTED
19. ENVIRONMENT
20. SELECT DEPENDENCIES http://wpackagist.org - WordPress Themes and Plugins https://packagist.org - PHP Libraries GENERIC PHP LIBRARIES WILL BE AUTOLOADED AND MADE AVAILABLE TO YOUR WP APP AUTOMAGICALLY
21. BUILD WHY DID WE USE COMPOSER UPDATE? WHEN WE DO USE COMPOSER INSTALL?
22. POST INSTALL SCRIPTS CONTROL POST INSTALLATION TASKS LIKE MOVING SUNRISE.PHP OR DB.PHP INTO APP ROOT FOR PREDICTABLE AND CONSISTENT BUILDS
23. AUTO MATE 3RD PARTY TORAN LEAN GIT DEV COMPOSE R DEVELOPMENT Manage your project, your code and your collaboration.
24. I’m elite status now, for sure, but what about my custom code? How do I structure my new project? PR. STRUCTURE DEV SO ELITE
25. STRUCTURE IF YOU PLAN ON REDISTRIBUTING OR REUSING YOUR NEW PLUGIN OR THEME, TURN IT INTO A COMPOSER LIB AND ADD IT.
26. CREATE A DEPENDENCY { "name": "myown_plugin/phpworld-plugin", "type": "wordpress-plugin", "description": "This is awesome", "keywords": ["plugin","wordpress","phpworld","demo"], "require": { "composer/installers": "~1.0.6" } } DEFINE YOUR DEPENDENCY BY ADDING A COMPOSER.JSON FILE TO ITS ROOT. ONCE YOUR NEW DEPENDENCY IS ON GITHUB, ADD IT TO PACKAGIST.
27. 1 By using “—prefer-source” Composer will clone the repo instead of downloading the “dist”. This allows you to edit and push changes directly from the dependency’s folder. By setting up the webhooks in Github, Packagist will automatically reindex your dependency with each push. You can tell Composer to use the latest repo commit by selecting “dev-master” Replace master with your branch. Github tags are interpreted as versions by Packagist. You can then choose a particular release with that tag. 2 3 4 NOTES Each time you update a dependency, you need to update your main project’s composer.json with the new version or update the lock if you’re tracking the branch. (See 2.) 5
28. HE’S ALIVE You can now easily select specific versions of plugins, themes or even WordPress by redefining your composer.json. This makes testing your code with even older versions trivial. Now, new devs need only clone your project repo and run `composer install` to build your exact project. Rest assured that they will be in full parity with your installation. (Don’t forget — prefer-source) We’ve now created a repo that contains only your project definition and potentially some custom code. Even WordPress is a dependency. Your repo is lean and mean, and easily deployed or distributed. EASY DEV ONBOARDING LIGHTWEIGHT REPO PROJECT TESTING WHAT HAVE WE DONE?
29. LET’S GET 31337
30. I piss excellence. My code is worth billions. I also have billions invested in commercial plugins and themes. I don’t want my code to be publicly available on Github or Packagist. PR. PRIVATE REPOS ELITE SO ELITE
31. PRIVATE VAULT
32. REPO OPTIONS SATIS TORAN PACKAGIST FOSS Commercial FOSS Static Generator Dynamically Generated Dynamically Generated Lightweight and Easiest to Setup Fairly complicated to setup Most complicated to setup Static file hosted anywhere Self-Hosted / Hosted Soon Self-Hosted / Public Version No web interface Rudimentary Web Interface Richest Web Interface w/ Search References Libraries Proxies Libraries (git + zip) References Libraries Support Composer / Packagist
33. I have hundreds of repositories now, strewn across multiple providers, even though the repos are in Toran or Packagist, I still need to give other devs and the servers access. PR. SO. REPO PERMS TORAN 1st ELITE
34. I have hundreds of 3rd party themes and plugins. How do I keep them all updated within my repositories? PR. SO. UPDATES? ELITE
35. WAIT WHAT?
36. I use many plugins for development purposes only, and would like to be able to define which dependencies are activated on an environment by environment basis. WP Plugin Control PR. SO. ENV PLUGINS ELITE
37. GIVE IT TO ME
38. MORE AWESOMENESSTOMORROW
39. BOOTCAMP .COM/PRIMETIMECODE
40. PrimeTime Code https://github.com/primetimecode Composer https://getcomposer.org/ Toran Proxy https://toranproxy.com/ Bedrock https://roots.io/bedrock/ Tutum https://www.tutum.co/ 01. 03. 04. 02. 05. TOOLS Packagist https://packagist.org/ Satis https://github.com/composer/satis 06. 07.
41. KEEP IN TOUCH @ETC ECOOK E@ETC.IO
42. QUESTIONS?
43. THANK YOU