tacowordpress/taco-theme

A bare theme for WordPress that uses TacoWordPress

Taco

WordPress custom post types that feel like CRUD models

See the wiki for complete documentation.

Setup

1. Add Taco and Util to composer.json

{
  "require": {
    "tacowordpress/tacowordpress": "dev-master"
  }
}

2. Include Composer’s autoload in wp-config.php

// Composer autoloader
// Add to the top of wp-config.php
require_once realpath(__DIR__.'/../vendor/autoload.php');

3. Initialize Taco in functions.php

// Initialize Taco
\Taco\Loader::init();

Usage

Once you have Taco setup, you can start creating your custom post types. Follow the getting started instructions for a simple example.

PHPUnit tests

If you want to contribute, you should create corresponding PHPUnit tests for your functionality or fix. You will need to create a database and configure db-config.php with your database credentials. Then pull down the latest Composer updates which includes PHPUnit, and run the PHPUnit tests:

$ composer update
$ cd tests
$ ../vendor/bin/phpunit

If you want to login to the WordPress admin UI for the test suite, you need to:

1. Create a hosts entry:

    127.0.0.1 taco-phpunit-test.vera
   

2. Create an Apache vhosts entry, modifying the path as necessary. If you are having trouble, make sure that your vhost file is being loaded by Apache.

    <VirtualHost *:80>
      DocumentRoot "/path/to/taco/tests/lib/wordpress"
      ServerName taco-phpunit-test.vera
      <Directory /path/to/taco/tests/lib/wordpress>
        AllowOverride All
        Order allow,deny
        Allow from all
      </Directory>
    </VirtualHost>
   

3. Visit http://taco-phpunit-test.vera/wp-admin/

    u: admin
    p: admin
   

Changelog

v1.0

• Updating to work with PHP 7

v0.9

• Tagging last version of Taco to run on PHP 5

taco-theme's Issues

Automatically creating AppOption post doesn't work

At the bottom of AppOption.php, we have this:

// Make sure a record exists
add_action('plugins_loaded', 'AppOption::createDefaultInstanceIfNecessary');

This is never fired, because the earliest hook available to themes is after_setup_theme. However, I question its usefulness. If we changed the hook to after_setup_theme, this method would be called on the front-end as well as in the admin, and it in turn calls getCount(). That seems a little wasteful in exchange for the convenience of automatically handling a critical piece of functionality being missing.

I would be in favor of removing this action and its method. Thoughts?

Page.php getFields and getFieldsByPageTemplate buggy with current version

Yesterday I had to replace what's currently on the Page.php in the taco-theme, with this below recently, because the current version of getFields didn't seem to be working for me. @lofiinterstate something we might want to look into and test when we get a chance.

public $loaded_post = null;

/**
 * Get the fields for this page type by merging the default template fields
 * with page specific ones
 * @return array The array of fields
*/
  public function getFields() {
    $this->loadPost();
    return array_merge(
      $this->getDefaultFields(),
      $this->getFieldsByPageTemplate(
        get_page_template_slug($this->loaded_post->ID)
      )
    );
  }


  public function getDefaultFields() {
    return array();
  }
  
  
  
  public function getFieldsByPageTemplate($template_file_name) {
    // setup empty array to return at the end
    $template_fields = [];
    
    // all pages except the home page get these default values
    if($template_file_name !== 'templates/tmpl-home.php') {
      $template_fields = array_merge($template_fields, array(
        // fields by template in here
      ));
    }
    
    return $template_fields;
  }

Mr. Spicy example may be buggy in taco-theme

This issue probably belongs on the Mr. Spicy repo,
but once the issues with the contact form are resolved, didn't the issue have something to do with creating and rendering the form at the same time?

We can fix our boilerplate example on this file:
https://github.com/tacowordpress/taco-theme/blob/master/src/templates/tmpl-contact.php

Undefined function in Taquito

In Taquito.php, there's a reference to get_image_id_from_url(), which appears to be undefined. Is this left over from a specific project, or something that used to exist in the standard functions-app.php?

Consider options for template-specific fields

Our current method of defining template-specific fields is messy. Here are some options for how to define them in different ways. Please note that none of these provide a clear path away from the current method of loading the post to figure out what its template is, which might remain necessary.

Anyone want to pitch ideas on how to improve this?

1. Our current approach, with all fields defined in one class

class Page {
  public function getFields() {
    // Bunch of logic for figuring out what the current template is
    return [
      // All fields for this template only
    ];
  }
  
  public function getFieldsByPageTemplate($template_file_name) {
    // Giant list of conditions for each template
  }
}

Pros:

• Easy to share fields across an arbitrary number of templates

Cons:

• It can get unwieldy very quickly
• Too much visible boilerplate code that no one understands or wants to see

2. Move sorcery to separate class

// Parent class that we never touch
class _Page {
  public function getFields() {
    // Bunch of logic for figuring out what the current template is
    return [
      // All fields for this template only
    ];
  }
}

// Child class that only contains the stuff we actually edit
class Page {
  public function getFieldsByPageTemplate($template_file_name) {
    // Giant list of conditions for each template
  }
}

Pros:

• Gets the boilerplate code out of sight, makes it clearer what to edit

Cons:

• Still has a huge mess of conditions for gathering fields

3. Give each template its own class

// Parent class for all pages
class Page {
  public function getFields() {
    return [
      // Fields that are shared across all templates
    ];
  }
}

// Child class for specific template
class About extends Page {
  public function getFields() {
    return array_merge(parent::getFields(), [
      // Just the fields specific to the About page
    ]);
  }
}

// Child class for specific template
class Contact extends Page {
  public function getFields() {
    return array_merge(parent::getFields(), [
      // Just the fields specific to the Contact page
    ]);
  }
}

Pros:

• Everything nice and tidy, neatly organized into separate classes in their own folder
• Allows templates to inherit fields from parent templates
• Makes it obvious what templates actually exist
• Allows for nicely organizing template-specific methods
• Potentially shorter lists of field definitions

Cons:

• Workflow might be unclear if unrelated pages share only a subset of common fields
• Ian's idea

4. Specify applicable templates on each field

class Page {
  public function getFields() {
    return [
      'field_name' => [
        'templates' => ['about.php'],
      ],
      'another_field_name' => [
        'templates' => ['about.php', 'contact.php'],
      ],
      'field_for_all_templates' => [
        'templates' => [], // Or omit entirely
      ],
    ];
  }
}

Pros:

• Tidy

Cons:

• Unclear what templates are available
• Still has a long list of field definitions

5. Move field definitions to separate class

class Field {
  public static function all() {
    // All field definitions
  }
}

class Page {
  public function getFieldsByPageTemplate($template_file_name) {
    $fields_by_template = [
      'about' => ['field_name', 'another_field_name'],
      'contact' => ['another_field_name'],
    ];
    // Return just the fields needed for the template
  }
}

Pros:

• Easy to see what fields are being used where in a compact array
• Could perhaps be combined with option 3

Cons:

• Not sure how to handle fields that apply to all templates
• Seems like I just typed this out without really considering its merits or how it would actually work