WordPress.org

Ready to get started?Download WordPress

Forums

Structural/opinion question (2 posts)

  1. jgclarke
    Member
    Posted 2 years ago #

    Hi all- I have a question about high-level/structural theme organization I'd love to get some feedback on. Here's my issue:

    * I have a site design from a client that has 4 unique page styles:

    1. A one-column right-hand layout
    2. A one-column left-hand layout
    3. A one-column full-width layout
    4. A two column left-hand layout

    And, to make things more complex, there are 8 total pages: 1 page uses style #1, 5 pages use style #2, 1 page uses style #3, and 1 page uses style #4.

    The way I see it, I have two main options for creating the structure to empower the relationship between these layouts and their pages:

    1. I can create a custom template (pagename.php) for each of the individual pages on the site, and then combine styles in the CSS file (so I don't repeat myself) to
    2. I can inject the page slug into the body tag, so that I can write things like body.pagename [styles].

    The downside I see to each of these options is that the HTML structures are based on variables that are user-surfaced; ie, if an end-user changes the page template or the page slug on the edit page, the front-end website will immediately break.

    That being said, I don't know of a way that I'd be able to define the structure *without* using a user-editable setting. So if that is my constraint, I think my *best bet* is to use the page slug, since that requires less custom templates (and therefore less duplicated code).

    Does anyone have any other ideas or feedback? Thank you in advance!

  2. jgclarke
    Member
    Posted 2 years ago #

    Quick update: I decided to use custom fields as the solution.

    • I think they're more safe and reliable than either calling the slug or the template, since I think users are less likely to mess with them; even if they do, they can look at other page examples for context (though they can also do that with custom templates).
    • They're more extensible, since I can use custom fields more flexibly than having to tie specific layout styles to specific slugs or custom templates.
    • I added fallbacks for all 3 style instances (layout, background image, and logo) to ensure that if custom fields are removed or inserted incorrectly, at the least the site won't completely break.

Topic Closed

This topic has been closed to new replies.

About this Topic