Successfully reported this slideshow.

WordPress Code Architecture

4,290 views

Published on

WordPress Code Architecture - revising the code architecture of the WordPress CMS and comparing it to the design patterns and core decisions in other CMS and frameworks based on PHP, Python, Ruby, Java and C#.

Published in: Software

WordPress Code Architecture

  1. 1. WordPress Code Architecture Mario Peshev @no_fear_inc WordPress Engineer DevWP.eu
  2. 2. Agenda • Leading Factors • Frontend • Backend • Users • Database • Helpers (Forms, etc) • Others
  3. 3. Mario Peshev • WordPress Architect @ DevriX • Former Java/PHP/Python Developer • WordPress Ambassador at SiteGround • @no_fear_inc • Open Source addict and Cofficer
  4. 4. Personal opinion about different platforms out there No flame wars intended
  5. 5. Leading Factors • PHP – most widespread across hosting vendors • Inspiration from predecessor (b2/cafelog), different from Rails and MVC-frameworks • PHP 5.2.4 support in Core • LAMP/LEMP stack
  6. 6. Main Differences • PHP is stateless and single-threaded • Default stack: Apache + PHP + MySQL • No MVC or complete OOP support • Framework out of a CMS (and not vice versa) • No non-traditional data storage layers • No REST support in core (until 4.0)
  7. 7. PHP 5.2.4 support Supporting 5.2.4 means that we can’t use: • namespaces • traits • Class::{expr}() • Late Static Binding • Closures (Anonymous functions) • Dynamic access to static methods
  8. 8. Frontend
  9. 9. Layouts and Views • Some MVC frameworks such as CakePHP:
  10. 10. Razor View (ASP.NET)
  11. 11. AJAX Similar to ng-model/ng-bind in AngularJS
  12. 12. Backend
  13. 13. WordPress Backend • Flexible default admin panel • Complete views and listings for post types • User management and capability control • Settings, Media manager and much more • Reusable WP_List_Table Components
  14. 14. Alternative Admins Different Admin approaches for every popular CMS • Scaffolded admin panels from web frameworks • Admin components and user management extensions Extensibility vs. Complexity Dilemma
  15. 15. Data APIs • Wrappers and facade across post types • Unification in options – add_option, set_theme_mod,set_transient • Automatically serializing complex objects • Verifying for new records • Sanitizing data
  16. 16. Drupal Entity API You define your data types with most MVC frameworks. Drupal has the Entity API:
  17. 17. Environment
  18. 18. Default Infrastructure • These are not available as separate modules/components.
  19. 19. Hooks and DI • Actions and Filters in WordPress • Annotations and Attributes in other languages and platforms Streamlined vs. Layer-based application life cycle model
  20. 20. JSF Annotations
  21. 21. PHP has some, too! Doctrine:
  22. 22. Database
  23. 23. Database • Post Type API base • *_Query helper classes • wpdb class • Other helper CRUD functions
  24. 24. Challenges with Databases • Normalization vs. Denormalization • Data Decoupling • Data storage choices:
  25. 25. LINQ or even NoSQL
  26. 26. Helpers and Utilities
  27. 27. Forms • Token generation • Model-based validaiton • Unified access control
  28. 28. Hopes for the Settings API
  29. 29. Media Uploader and /uploads • Media uploader – wp-content/uploads for private documents
  30. 30. Other Areas • User Management • Multisite support • Tools and Libraries • Routing • Performance • Security • Packages and [Distributions]
  31. 31. Summary • WordPress is still AWESOME • There are just other ways to build an architecture • Other languages and platforms have their own strong sides too
  32. 32. Questions? Tweets as @no_fear_inc Mario Peshev on LinkedIn nofearinc on WordPress.org GitHubering via mpeshev DevWP.eu - blog
  33. 33. Notes • Take a look at ExoWP • Definitely watch To OOP or not to OOP

×