Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

WordPress Code Architecture

8.103 Aufrufe

Veröffentlicht am

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#.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

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

×