https://github.com/hacklabr/wp-mvc
MVC based WordPress theme for complex websites
https://github.com/hacklabr/wp-mvc
Last synced: 9 days ago
JSON representation
MVC based WordPress theme for complex websites
- Host: GitHub
- URL: https://github.com/hacklabr/wp-mvc
- Owner: hacklabr
- Created: 2013-05-23T21:11:35.000Z (about 13 years ago)
- Default Branch: master
- Last Pushed: 2014-04-10T21:45:58.000Z (about 12 years ago)
- Last Synced: 2024-04-16T01:27:32.763Z (about 2 years ago)
- Language: PHP
- Size: 149 KB
- Stars: 5
- Watchers: 5
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
## WP-MVC Theme
My experience developing in WordPress is that the callback orientation of hooks
allow developers to design any structure to a theme, easilly turning it into a
mess, and for the cases of complex websites, a huge mess. That way it's
dificult to know how a theme works with WordPress.
Trying to solve this problem, the proposal is to _change the WordPress behavior
always the same way_. This simple structure aims to be a guideline for complex
WordPress themes with lots of queries and custom rewrite rules by relying in
the MVC architecture, then you can explicitly define where, how and when
queries are chosen and executed.
### MVC architecture
Translating from the Wordpress theme dictionary, we get something like this:
* Model: Custom post types and taxonomies used by the theme;
* View: WordPress templates of the theme according to the [template hierarchy](http://codex.wordpress.org/Template_Hierarchy);
* Controller: The [rewrite rules](http://codex.wordpress.org/Class_Reference/WP_Rewrite) and [query variables](http://codex.wordpress.org/WordPress_Query_Vars).
### Post types
Organize your post types and taxonomies inside the `models` directory,
declaring each one of them in its`.php` file. All files in this
directory will be automatically included.
### Queries
To link queries from URLs to views you'll use the `router.php` file:
1. Define a rewrite rule in the `_query_rules` function:
return array(
'^sample-rule/([^/]+)/?$' => 'custom_query=$matches[1]', // sample rule
// another rule here
// one more rule here
// ..
);
2. Create a variable in the `$_query` object in the `_init_query_object`
function:
$_query = (object) array(
// built-in template var
'template' = false,
// My custom query
'custom_query' = false,
/* other variables here ... */
);
3. Define the condition to use this variable in the `_query_processor`
function.
function _query_processor( &$query ) {
global $_query, $post, $wpdb, $wp_query;
/* other conditions /*
} elseif ( $custom_query = get_query_var( 'custom_query' ) ) {
/* Define the template to be used. If left to false, then WordPress
will choose the template */
$_query->template = 'custom-template';
/* Define a new query maybe ysing $custom_query */
$args = array( /* custom args */ );
$_query->custom_query = new WP_Query( $args );
}
}
Like this, the `custom-template.php` will be loaded with the `$_query` object
containing a `$_query->custom_query` attribute to be used.
custom_query->have_posts() ) : ?>
custom_query->have_posts() ) : ?>
custom_query->the_post(); ?>
$_query->custom_query has no posts.
## Rules
So, using these guidelines also implies in some rules for developers:
1. Never make queries or any theme logic outside the `_query_processor`. Always
use an attribute of `$_query` to pass data to the templates.
2. Always use the `$_query->template` attribute to define wich template will be
loaded, and set it in the `query_processor` to be explicit wether you want
WordPress to choose it or not.