I have built WP sites in many different ways over my career, and I am always curious of peoples' methods for building custom WP sites. In the past, I have done everything from hacking together premium themes to do what I want, to building each file in my theme from scratch. Over my evolution as a developer I have currently become mostly satisfied with using a 'starter' blank theme like underscores or understrap. I then use ACF Pro along with custom post types, and that usually covers the majority of what I am trying to accomplish. I have a design background so I design my own stuff sometimes, and I also work with a few very talented designers that push their designs, which I love. This frequently requires highly customized layouts, headers, and footers that I try to couple with an intuitive backend, so the client can change any content on the fly, while having some control over appearances like placement and adding columns.
Second to the Underscores / ACF method, I and surprised how easily I can accomplish the same result with something Like Divi (page builder), where I almost total freedom with code, templates, and custom react modules. Also, the client still gets a drag and drop product that looks very nice on the backend. Sometimes more so than my preferred method. Through both of these methods I always use a child theme so I have very few boundaries when building stuff, but still get to benefit from the theme updates without everything breaking two years down the road.
These are just my own experiences, and since there are many people on this site that have far more experience and know-how than I do. I am interested to here how other people go about always starting with a versatile theme. I am open to trying new types of themes, and also ways to build custom fields, meta-boxes, and taxonomies.
Related
Can anyone help me to get this answer with a small example as I have been trying to be cleared about this two things.
According to, and elaborating on the WordPress Codex:
Plugins
Plugins are ways to extend and add to the functionality that already exists in WordPress. The core of WordPress is designed to be lean and lightweight, to maximize flexibility and minimize code bloat. Plugins then offer custom functions and features so that each user can tailor their site to their specific needs.
So this should be thought of as a way of extending WP's underlying / core functionality. Remember, WP's Roots is that of a blogging CMS, but developers over the years have been hell bent on making it do anything and everything treating WP kind of like a framework, but not to be confused with one. For example, WordPress does not have a contact form built in for users, therefore I can plug in a 3rd party module which will permit the administrator to set up and use such functionality.
Widgets
WordPress Widgets add content and features to your Sidebars. Examples are the default widgets that come with WordPress; for post categories, tag clouds, navigation, search, etc. Plugins will often add their own widgets.
This is not as straight forward due to the concept being quite abstract. Think of a widget of extending the template dynamically by allowing a webmaster to deploy 3rd party plugins (as well as default plugins). Developers tend to use such functionality to display information that is not mission critical, non intrusive and easy to use / manipulate.
However, to clarify, you don't necessarily require widgets to use plugins. In the case you use Akismet, it will simply extend WP to prevent against spam without ever displaying anything to the user.
I have been asked to create an eCommerce website for a client on a strict budget. I figured using WordPress would be my best bet in this case. I am new to both WordPress and developing an eCommerce/online store. I intended on designing and developing my own bespoke theme for the client, however their limited budget does not accommodate the fee I quoted for designing and developing a bespoke theme. Therefore, I thought that a free theme would be the most suitable option in working within the constraints of the budget.
My questions regarding using the free theme are:
What are the limitations to using a free pre-made theme in terms of its styling, look and layout (structure)? For example, could I easily move the logo or other elements and graphics to elsewhere on the same page if I wanted or I am stuck with having those items wherever they are originally placed? In other words, what flexibility do I get in changing the design?
How 'unique' could I expect it to look with some customization?
What are the limitations on features and functionality?
Would I get more design flexibility with a premium theme instead?
There are pretty much no limitations.
You can make a child theme out of the free theme, then you can customise the css and php files which make up that theme, as much as you like. That will allow you to do everything you mention in point 1. See http://codex.wordpress.org/Child_Themes for details.
Wordpress provides a simple web interface that allows you to view and edit the files, or you can just edit them using your favourite code editor.
The idea with a child theme is that any file which you customize overrides the file in the original theme. This means if there are updates to that theme in the future, you can safely download them without wiping out the customisations you've made.
I would recommend you start with something like the twitter bootstrap theme for wordpress, which gives you a neutral design and quite a lot of useful javascript functions. That will help you with point 2 - ensuring uniqueness, as you don't start with something that already has a distinctive look and feel.
re: point 3 - that's the great thing with wordpress. Just add plugins and widgets (or even develop your own). There really are no limits.
To answer point 4: Premium themes typically provide more sophistication in terms of design features and add-ins like scrollers, slideshows and shortcodes. Sometimes they also provide customised interfaces that allow limited customisation such as colour schemes and page layout, but essentially the wordpress interface for customisation is the same, whether you've paid for the theme or not.
This is a serious question, specifically relating to the many frameworks out there for Wordpress and Joomla - Warp, T3, Gantry etc. What I dont understand is how they are different to a starter template and what exactly you are supposed to do with them - simply child theme them or is it a whole other codex to learn? I mean, all of the native codex is there with Joomla and WP anyway to construct a theme simple enough so what good does a whole proprietary app do between your design and the CMS? Are they faster to develop with?
What confuses me is that people seem to love them and claim that they make life easier but I dont get how adding another technology to learn can make things easier. Like I say, it is a serious question, not one for effect to make a point.
Can anybody define the difference between a framework and a starter template? I ask in part because I am one of those anxious developers who always feels like I am somehow missing a trick or doing things the "wrong" way - what am I missing?
This is definitely mostly an issue of definition, and I can guarantee that some cases will not follow what I outline below. Obviously, anyone is free to call the template/framework by whatever they want.
Generally though, a template is comprised of basic HTML and CSS that works with the platform (Wordpress, Joomla, etc) that is used to build the output to the page. In Wordpress, this contains the loop and other constructs to get all the content for the page. In Joomla, it outlines all the module positions available and such.
Typically when you purchase a higher end theme, you will have significant choices on the backend to customize the theme without having to actually code. These parameters let you typically change colors and such.
Some of the theme developers and others have taken this parameter settings system to the next level and made it into a framework. In all the cases that I've seen, "framework" is really the basis for the template parameter system. In this way, you can have consistency between different themes and expect the same settings and features between different themes. This is why they use a different word, because it really isn't a "theme" any more. It really is like a "theme engine" in that it is a backend system for changing things in the theme.
Yes, many platforms offer some basic options for editing the theme out of the box, so in most cases, the framework is really an improvement on the base platform's theme engine.
It's been my experience that a theme will be a visual style along with a set of theme options available in the admin (in addition to Customize if it's supported).
Theme Frameworks on the other hand, like Thesis, are installed just like a theme but have a very vanilla visual style that you build your theme on top of. Usually the framework provides many added features that aren't available in WP core.
tl;dr - Themes frameworks aren't installed and used right away, they are installed and built upon to deliver a site.
I run a design firm and have frequent need for Drupal development. I'm looking for a bit of guidance on a Drupal workflow that will work best for my company.
My experience working with Drupal developers in the past has been great for back-end development, and chaotic for front-end development. Projects end up with multiple and inconsistent CSS styles, and doing quality control on the visual aspect is very time-consuming.
Moreover, I'm a front-end coder, and use HMTL/CSS/JS prototypes for all phases of projects. I would prefer if the front-end coding I do to was used by the developer instead of going to waste.
However, this workflow hasn't been compatible with Drupal dev partners so far. Because they use themes, and retro-fit them to the design I give them, they aren't able to use the HTML/CSS/JS work I do. Moreover, I have a responsive framework that I like (Foundation), and my developers want to work with the standard responsive Drupal theme (Omega). I don't like Omega because it isn't fluid.
Then there's things like my developer telling me they can't do a carrousel that uses CSS (background-image), because the available Drupal carrousel modules are all based on using the HTML img tag. Does everything have to be based on modules?
Going back to the HTML/CSS inconsistencies and the time-consuming design QA, I think this comes from trying to retrofit a theme. The code is very messy and it makes it hard to target elements for styling. It also makes it impossible for me to do my own CSS changes if I want.
So, in short, I'm looking for a completely different design workflow, and I'm looking for feedback on whether it's workable in Drupal without inflating costs.
Is it possible in Drupal to use front-end code (provided by me), throw in some PHP tags, and end up with cleanly-coded pages, instead of relying on themes? Would this reduce costs (because the HTML/CSS/JS is provided), or would it inflate costs (because it's easier to use a theme)? Are there any security issues involved? Are there update issues involved? In short, what's the big advantage with working with pre-fab themes?
I really, truly appreciate your comments.
We usually develop from the backend to the front end. Modules like Views add many div tags, classes and tags so the theme developer can make better use of them and fine tune the design.
I do not think that is a "messy" code unless you are doing all of the work in tpl.php files.
Modules simply processed the data. It should not heavily theme the output. For a better understanding, see the image below (from drupal.org):
If you want to do any database intensive work in the template level, you will have to load many stuff again that you could simply do in a module.
In my opinion, if your developer is not hardcoding the HTML stuff, he is doing it right.
Keep in mind that you can override most of the theme functions so you already have the flexibility if you want.
Is it possible in Drupal to use front-end code (provided by me), throw
in some PHP tags, and end up with cleanly-coded pages, instead of
relying on themes?
Yes. But you can't simply use slider-image.php like files for that. You will have to add necessary theme functions to and pass the variables to it. IMO, it's relatively more work if you need to completely rewrite the theming functions.
Would this reduce costs (because the HTML/CSS/JS is provided), or
would it inflate costs (because it's easier to use a theme)?
I do not think so. If you have multiple backend developers working on code, ask the theming team to make changes to HTML/CSS. CSS can make your site look worse, and a security bug can ruin your business, expose all your user information or even worse.
Are there any security issues involved?
Most likely. Default theme functions tend to come with much better security. Even though few bugs come out, they will get fixed soon by the community.
Are there update issues involved? In short, what's the big advantage
with working with pre-fab themes?
Because there is a whole lot of work that you can simply adopt. That will also block you from adopting others' CSS work though.
I work somewhere with highly stylized well thought out front end builds which are almost not compatible with the way Drupal theming is handled currently. Having front end developers track down bugs is also very problematic. It looks like there's some acknowledgement of this in Drupal 8 at least. At this point we frequently rework Drupal to work as an API and then build a lightweight PHP Framework app on top to pull content when we need it which gives us total flexibility to do anything we want with the frontend. Another alternative is to checkout Expression Engine where you are explicitly telling it what markup you want outputted and how you want your content to be placed in the markup.
The holy grail would be a very lightweight layer that was part of Drupal where we could use Twig to pull the content the way we want it and all HTML output was defined in Twig.
I starting working with WordPress as a CMS, now that the V3 makes it way easier to manage taxonomies and custom post types. My work is mostly focused on developing plugins and themes.
My biggest plugin does some admin stuff (add admin menu items and the related pages and features), but also does some importing and exporting, and hooks some of the base post processing treatments ("when a new post is created").
My biggest theme is pretty small, and all it does is display custom posts in a custom way.
After a few weeks of work, I have several thousands of LoC, and it's getting harder and harder to dig into it. Which leads me to the following question: How do you organize your WP plugins code? And what about your WP themes code?
several thousands of LoC
That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;
Write less, do more!
You might be much better off using Pods CMS alongside WP to cut down your code.
This is how we structure client deployments that include themes, third-party plugins, and custom code.
wp-content/plugins only contains third-party plugins, no code in here is modified, and the site should not be deadlined by any of these plugins being disabled / removed.
wp-content/themes should contain the code related to presentation of the front-end. The trick is not not overload the theme (functions.php and other theme-related files) with code not directly related to presentation.
mu-plugins/ contains all of your implementation-specific business logic. Things in here should never be disabled, and are required for operations.
That is avery brief summary, but in a nutshell that is the logical compartmentalization of code that we've found to be most failure proof.
Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?
There are basically three ways you can do this: prefixed functions, with require_once's including files by functionality, which is quite common.
The other "right" way that's touted a lot is having one giant class with all your plugin code in it. While keeping things nice, as you said, once that file gets into the thousands of lines of code, you're screwed for manageability.
The way I like to do it is a way coming from my C# background - have one main plugin class, and other "worker" classes (you can put them in a namespace to keep classnames short). For example, have a class dedicated to the admin section (it can have its own little "subclasses" too, say one for each page). It'll take a while to refactor all this code into the different classes and files, but it'll be worth it - it'll be much easier to keep track of everything, as well as for example getting people to work on the codebase together. It also forces you to think more of how your application all fits in together, which lends to better thought out code.
I'm actually writing an article series about this, outlining the three different methods. You can take a look at the first instalment here. There are two more coming in the following weeks.
Hope I helped!