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

1. WordPress Code
Architecture
Mario Peshev @no_fear_inc
WordPress Engineer DevWP.eu

2. Agenda
• Leading Factors
• Frontend
• Backend
• Users
• Database
• Helpers (Forms, etc)
• Others

3. Mario Peshev
• WordPress Architect @ DevriX
• Former Java/PHP/Python Developer
• WordPress Ambassador
at SiteGround
• @no_fear_inc
• Open Source addict and Cofficer

4. Personal opinion about different platforms out there
No flame wars intended

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

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

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

9. Frontend

11. Layouts and Views
• Some MVC frameworks such as CakePHP:

12. Razor View (ASP.NET)

13. AJAX
Similar to ng-model/ng-bind in AngularJS

14. Backend

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

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

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

18. Drupal Entity API
You define your data types with most MVC frameworks.
Drupal has the Entity API:

19. Environment

20. Default Infrastructure
• These are not available as separate modules/components.

21. Hooks and DI
• Actions and Filters in WordPress
• Annotations and Attributes in other
languages and platforms
Streamlined vs. Layer-based application
life cycle model

22. JSF Annotations

23. PHP has some, too!
Doctrine:

24. Database

25. Database
• Post Type API base
• *_Query helper classes
• wpdb class
• Other helper CRUD functions

26. Challenges with Databases
• Normalization vs. Denormalization
• Data Decoupling
• Data storage choices:

27. LINQ or even NoSQL

28. Helpers and Utilities

29. Forms
• Token generation
• Model-based validaiton
• Unified access control

30. Hopes for the Settings API

31. Media Uploader and /uploads
• Media uploader – wp-content/uploads for
private documents

33. Other Areas
• User Management
• Multisite support
• Tools and Libraries
• Routing
• Performance
• Security
• Packages and [Distributions]

34. Summary
• WordPress is still AWESOME
• There are just other ways to build an architecture
• Other languages and platforms have their own
strong sides too

35. Questions?
Tweets as @no_fear_inc
Mario Peshev on LinkedIn
nofearinc on WordPress.org
GitHubering via mpeshev
DevWP.eu - blog

36. Notes
• Take a look at ExoWP
• Definitely watch To OOP or not to OOP