WordPress options - wordpress

Today I'm on an asking spree :P
Anyhow... Right now I am developing a free WordPress theme. The problem is that I want to make it as flexible as possible so that is why I will use some theme options to set some CSS colors, widths and so on. My question is this:
If I assume that one of this themes will be used for a heavy traffic blog, how this will affect server performance? I will have an increase of SQL queries? Or something else (wrong) ?

I do not think there will be an increase in the number of SQL queries. Unless, of course, you decided to extend the worpress functionality by making the theme somewhat data driven.
However the size of your templates/images/CSS/javascript files may have some impact on the performance of the application.
As a general rule of thumb, if you are concerned about the performance of a web based app, it is always good to keep your files as light as possible.

Anyone using WordPress for a high-traffic blog is almost certain to be using WP Super Cache, which means almost all pageviews will cause (depending on whether the super bit is being used) either 0 or 1 SQL queries, regardless of what your theme does.

Wordpress isn't renowned for being gentle on the database - although I guess there might be intentions to improve over time.
So you're not causing big problems by adding an extra query.
But keep it to one query: have all your options so that one SELECT will get them all, and call that once per page load.
Alternatively, don't store the options in the database. Have a config file that lives in your theme directory.

You shouldn't really be adding anything that does anything but provide styling to your theme, if you want to keep database loading low. (Of course, I mean other than the default data retrieval functionality found in pretty much all themes.)
The only parts of your theme that should really be doing any significant querying are:
The regular bits and bobs in the loop (for the main blog page and archive pages)
The comment retrieval (for single-view posts)
The sidebar (presuming you're going for a widget-enabled sidebar)
I'd suggest leavingextra functionality (and, therefore, extra DB queries) to plugins - a theme should focus purely on aesthetics.

Related

What is the difference between building a site on wordpress vs hand coding?

So I'm a beginner to coding and I am wondering what is the difference between building a site using wordpress (which I am not familiar with) as opposed to just hand coding from a text editor like sublime and then hosting it. Should I be using Wordpress? What exactly are the benefits? Thank you.
It all depends on what you want the website for.
I've both hand coded and used Wordpress (and before that Moveable Type) over the past 15 years. When I was doing infrequent updates to my website then hand coding was perfect. I could make it look exactly as I wanted, it had only the elements that I needed and nothing heavy in the backend to slow it all down.
When that all changed to being frequently updated Wordpress was much easier. The ability to schedule posts was one of the big things that got me into using it. If you're doing frequent updates, which, say need to post at the same time every day or multiple times in a week, but you're not necessarily available, then it's great. If you're short on time, then it's also useful because you choose once how you want the site to look then type your information and publish it. You don't need to amend any code or use FTP.
What you do lack is the personalisation. Unless you're also going to learn how to make Wordpress themes to properly personalise a Wordpress site, then you're stuck with the templates available for download. Some are great, some are mediocre and some are very simple.
My next project is to get my sports team online properly, and because there are about five or so people who would need to edit it Wordpress works for this. I can give people limited access to allow them to post/edit posts but know that because they're restricted, they're not going to break it all, unlike if I allowed them FTP access, which could be a massive disaster with people who aren't familiar with that.
You need to consider what you're really trying to achieve. If the website is really you and needs to reflect you and you don't update it relentlessly, then hand coding would be my first choice. If other (perhaps inexperienced) people are involved or you need to do things quickly, then I'd choose Wordpress.
If you want to create your first website, you should use a CMS like WordPress, because it will be easiest for you to publish content online and you will find many free plugins and themes at the wordpress website.
The main difference between a CMS like WordPress and a hand coded website is the first is not create for you. WordPress can be used in many way, but you will have to learn the WordPress codex to create your own themes and plugins.
With the hand coded, you will create a website optimized for what you need.
But you have to consider, you will have to code again each time you want to edit something, and for some features it will be a lot of work.
WordPress already include many "must have" features like seo friendly URLs, categories and tags etc..
But you can also look for another CMS, smaller than Wordpress

Did i reached the limits of wordpress and woocommerce?

I know the question sounds a little weird, but, please, read along. I have a store based on wordpress, woocommerce and wpml - currently in two languages but with plans to add another 3. The theme is quite huge with a lot of custom integration like Infusionsoft, Xero and more. About 50 plugins, 1100 product and 1700 posts. The number of posts and products will most likely double in the near future once we add another 3 languages. The overall setup is already kind of slow although we have enough server resources: 12 cores and 31 GB of ram. On top of this, I'm looking to integrate some sort of multi store and multi domain functionality. The multi store functionality will also require to be multilingual (wpml). There are two solutions to create the multi store functionality and none of them seems to be ideal and easily replicable without hacking more into woocommerce and wordpress.
1. Another install of wp, woocommerce, wpml and then using the woocommerce API to transfer the orders, stock, etc. back to the main site.
2. Wordpress multisite - from what i read is quite buggy with woocommerce and wpml.
As a developer myself, I feel this is a overkill for the wp, woocommerce and wpml. Especially if we take into consideration that Opencart or Prestashop comes with this functionality by default - without any kind of complications. But maybe, just maybe I am missing something really clever. Did anyone faced a similar setup ? What are your thoughts about developing such a complex setup in Wordpress and Woocommerce? Do you guys think it's imminent to move to another solution like Opencart, Prestashop or Magento ?
I would really appreciate your feedback about this!
Cheers
What i would do here is investigate why the website is slow first before adding hardware to the issue. Wordpress is a great base to start with but the same as all db driven websites needs optimization as the website grows.
There are many techniques for the below so ill just point to ideas and you can re-search them yourself and decide whether they suit your website.
Test here:
http://www.webpagetest.org/
To test your server code:
Use something like microtime to measure processes especially wp queries. http://php.net/manual/en/function.microtime.php
Where possible use caching (server caching) - possibly use varnish to cache product pages and serve static pages in place of dynamically created pages.
For expensive queries like post-archives use wp-transients or your own object caching.
To test browser code:
This is probably where you will see the greatest timesavings if you have 50 plugins. Unfortunately dev's love to hook js files, css files to the footer/header. This can be a significant load time. Investigate what you can remove from your templates (un-used js scripts, css files, etc) and de-queue them. For more savings see if you can isolate the css / js actually needed for the page out of the files present - combine into 1 file of each. Most of the time you will need the header/ sidebar css and some text styles but you are loading an entire themes stylesheet.
Pretty essential:
investigate your browser caching strategy.
https://developers.google.com/speed/docs/insights/LeverageBrowserCaching
Fun project:
Did you know you can load images/js/css to the cache using js? Pre-loading!
Maybe look at post-archives that require a lot of images and see if you can preload the "above the fold" content - your user will get a pretty quick browser load time and by the time they navigate below the fold the next batch of images should be cached (if you are combining with lazy load techniques)
This might save you the need to use extra servers but if you have to look at sharding rather than using a api to transfer data using php (i presume woo commerce api uses?)

Non-theme based Drupal development?

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.

How can I improve working with Drupal?

For about a year and a half I used Codeigniter to build my sites. Then a client begged me to build theirs in Wordpress. I soon found the joy of using a CMS (if Wordpress can be called that). So for about the last 8 months I have been using Wordpress as much as possible to buld my sites - I made the content fit the design.
Well, I began to grow very tired of the limitations of Wordpress - I needed more control and flexibility over my sites. So, I have recently started using Drupal 7 (not 6.x - I really like the admin panel).
After working with Drupal now for a little under two months - I have begun to feel like I'm using Stone Age Tools to build Space Age equipment.
So my question is: does Drupal get any better? Do you really have to use Views to display your content? Asking for help on the forums is just a shake better than asking a wall. I feel like to do anything requires a module. Why? Is one better off sticking to a framework?
"After working with Drupal now for a little under two months - I have begun to feel like I'm using Stone Age Tools to build Space Age equipment."
Well, my intiial reaction is that this is what you're going to feel like you're doing when you're working with Drupal 7, which isn't out of alpha yet. A good number of the folks who maintain modules haven't started upgrading to 7 yet, and that means that you're missing out on one of the great features of Drupal, which is it's wide and deep space of premade modules.
Try 6.
Do you need to use views to display all content? No, not at all. You can go in, create a new module, and write the sql and presentation that you want. Or you can find a module that will display things for you. Or, depending, you might be able to get the effect you want just by adjusting the theme you're using.
(As a side note, using an admin theme really pretties up the Drupal experience. I'm fond of rootcandy, although Rubik is nice too. Problem with Rubik is that it's not on drupal.org.)
The strength of Drupal is that by using modules, you don't have to re-write code that someone else has written - you can instead take that code and modify it (with hooks) to do what you want. This means you don't have to write an authentication/autherization system again - it's there in core. You don't need to write up openid handlers - it's in core. You don't need to write code to integrate with twitter directly - there's a module that contains an api that helps out. You don't have to write an xmlrpc server from scratch - you can use the services module.
You don't need to write a website from scratch. Instead, you can start with Drupal, add most of the functionality you need, and then spend your time making it fit what your client wants.
Firstly, you can install the Admin module to pretty up Drupal 6 admin. You don't have to use 7. 7 is still in alpha, by the way. Garland sucks, but, Garland is just a theme- its not 'the' admin itself. The Drupal admin can take the form of any Drupal theme, which is useful in its own right, depending on the use-case.
In Drupal, you can create content types clicking through the interface in Drupal 6 or 7. As far as I can see in WP3, you have to script it. A few clicks vs scripting, the choice for me is not hard there. The first way is a lot more efficient, and a task you can hand off to a non coder to get done.
You don't HAVE to use Views to display content.
You -can- use Views to make the display of content easier, by telling Drupal to gather data and provide a Page, Block, or Feed to display . This lets you create specific sections of content for areas of the site. Otherwise, you would have to create a node, and hijack its template, run a direct sql query yourself AND write the pager functions just to show something easy like the latest 10 "Press Releases" content type. Then, if someone added a new field to that content type, you have to update all that SQL code and display code. Views makes your life easier in that respect. In minutes you can flesh out site sections and arrange content in a myriad of ways. In Wordpress, this method of arranging content without functionality of Views is/was a modern nightmare and a reason I do not want to use it at all unless its a blog and nothing more.
The Drupal Support Forum is tricky. Not all modules are as active as say, Views or Pathauto (being two of the most popular modules). However, SO is also at your disposal. I answer a lot of Drupal questions here. The trick to the Forum there is you have to ask it in the right spot. True, sometimes you may have to wait a few days to get an answer, then again no one -owes- you an answer for a free product. Thats the nature of open source.
Every developer has their favorite modules to use with Drupal, and more often than not, its the same 20 or so modules. It depends on what you are doing, what you are trying to implement. It's not that 'everything needs a module' its that Drupal is such a vanilla install because Drupal does not want to assume your purpose nor overwhelm with options. The UX is something they are trying to improve anyway, and popular modules are making their way into core.
Well, I began to grow very tired of
the limitations of Wordpress - I
needed more control and flexibility
over my sites. So... I have recently
started using Drupal 7
Why not go back to CI? Drupal certainly has it's strengths, but I don't think Drupal will give you any more "control and flexibility" than Wordpress.
If the standard modules/plugins, themes/templates, from WP, Drupal, or Joomla, fill your needs, then using a CMS can be a lot faster than building a site from scratch. But, if those CMSs do not fill your needs, you could find yourself "fighting the framework" and never really getting what you want.
You're just coming out from WordPress, which has great support and is relatively easy to extend to overcome what you call its limitations, if you know basic PHP, HTML, CSS & JavaScript. Every framework has its own potential/limitations.
As a user of WordPress my humble opinion is that you should have stayed with it.
As of you last question, It depends, to stick with one and only one framework has its advantages and disadvantages, the best of all is that you get to know it very well and eventually learn how to extended it. The bad part is that very often frameworks lose popularity and you are left to you own without an active user community and support.
Regards.
All of the popular CMS products (I'd maybe add Expression Engine to the mix) are great for 80% of what you want to accomplish and a huge pain to handle the other 20%.
That's just the nature of the beast.
On the plus side, it's OS so there's lots of people hacking away at it just like you which opens up the potential for someone else already having invented the wheel.
And with bulky enterprise CM solutions like SharePoint I find that you have to reverse the equation to 20/80 (ugh!).
If you're discouraged with Drupal and prefer to stick with WP, WordPress has many thousands of plugins, including ones that can overcome the limitations you're running into and make WP behave more like a normal CMS.
Just do a Google search for "top Wordpress CMS plugins." There's a lot of articles out there that can recommend ways to get WP to do exactly what you want.

How to Build WP Site with Hierarchical Content and Using Custom Design?

A client asked me to redesign her web site, built several years ago in WP by another developer. Although I've never worked with WP before, I'm pretty comfortable with html, css, and php, and I more or less understand how WP stores content and dynamically builds pages. But I'm wondering how to approach these challenges:
My client's site has about 75 pages. There are about 25 that are static (i.e. the content changes infrequently if at all; things like "about us" and "faqs") and there are about 50 pages that are more "blog-like", except that instead of posts, the content contains directory-type info (e.g. 12 DJs in the area) or event-related info (e.g. upcoming shows at local theaters). Both of these categories contain many sub (and sometimes sub-sub) categories (e.g. medical services > pediatric > kid allergy specialists) and the content updates fairly frequently.
I understand the difference in WP between "pages" and "posts". But I need to find out the best way to structure the static content. Should I just set up a parent/child hierarchy of pages, changing the permalinks to something that makes sense? Or is it better / easier to just build the static pages outside WP and somehow link to them from the common navigation?
As a web designer, I want to "wow" my client with a great design. While there are loads of wonderful WP themes available, I really need to create something unique. But I'm wary of breaking something, so what's the best way to take an existing theme and just tweak it enough to make it look a little different?
Finally, other than mounting a massive "copy and paste" effort when the new site is built, is there a way to transfer content from the original site to the new one?
By reading your question, it seems to me that choosing WP for this kind of website was a bad choice.
Redesigning it, though, won't be that hard if it's using page templates for pages.
And yes, there's a import/export tool in WP to tranfer content. (see administration panel)
I, really, advise you to read this great tutorial about creating WP themes.
I've a blog-like WP site myself (contains RPG development articles). Here's what I did. Nested static pages simply have parent-child hierarchy: /about/mingos - that's easy to understand and i value this kind of content organisation (personal opinion).
As for themes, there's a no-brainer tool that, while not exactly apt for real business, has the capability of letting you see how stuff will look in seconds, and can sometimes give you great ideas. It's called Artisteer and there's a demo on its site that you can have a look at. Try your design ideas with it, see how stuff will look like. I'm sure you can come up with some great ideas for a "wow" design :).
Exporting content, as Soufiane Hassou remarked, is possible from within the admin panel.
Don't rule out using categories to create your hierarchy. That way you'd get the benefit of cross categorization of DJs and venues by location to create a robust cross reference system. Pages don't get this benefit without extra work.
To make this in to a directory, though, is gonna either be heavy work on managing the pages or heavy work on creating a solution that will cross reference everything and bring the content together in a usable way on the front end.

Resources