The ‘default’ wp theme does this already, but only gives a single option for an image upload vs. an array of uploaders which would give theme designers the ability to have multiple uploadable images in the theme admin for use. (background,logo,etc). Also the default uploader does not allow a user to select an existing image from the theme’s image folder.

This really comes into play for those of us who use ‘mu’ to host multiple client sites as we never give ftp access anyhow. Uploaders would give the admin the ability to let users change images in the theme without having to email the master admin to ftp up an image and change the css.

The image upload functionality is possible, but it’s a double edged sword for us… those that don’t know how to upload an image via ftp and change the css will most likely end up uploading wrong size images etc and create more support. I do think there is such a thing as TOO many options, although some themes might fit the bill better. Digital farm has the ability to upload your own header background, so we might incorportate similar options in new themes

I host a number of sites on my wpmu install and it never ceases to amaze me how many questions I field on a daily basis. Like everyone else I used to rely upon a lot of plugins like the navigation you built. The problem was in trying to explain to the customer that they had to go into ‘another area’ to edit their navigation then simply having it in the theme admin panel.

Once I started moving everything into a central location ‘theme’s functions file with nice ui’ the questions really slowed down.

Not only is it more elegant, but it also means I do not have to add yet another link to the wp-admin bar for the person to remember. Doing it this way, the customer can control everything via the panel itself. Basically what I end up delivering to the customer feels more like a custom cms than wordpress when I do this.

I do have a suggestion for a future addon:
How about an array of image uploaders to be used throughout the theme?

Every theme has images like backgrounds, logo’s etc, yet we still force the user to use ftp should they want to change an image. And they have to change the css or theme file itself.

It seems to be a great idea to allow a user to either upload a new image or select an existing image in the theme’s image folder for use within the theme. I know that wp has the engine for a single image, but I have never seen an admin panel with an array of uploaders for multiple images. And those themes that do have image upload ability for backgrounds, do not allow the user to select an existing image for use, nor do they allow the user to crop the image to fit the given area.

anyhow, that’s my idea for the day lol

Custom navigation is very helpful! Excellent idea. Great work.

So I love the slight shift and suggest you keep going forward.

So whilst it is still a manual process at the moment, we will be building something to auto-update within the next couple of months. This will be a major new addition to the WooFramework, which is why we’ve delayed it until now: it needs to be perfect before we make this available to all of our users!

As someone who often makes massive changes to the themes (beyond css) I am worried that I won’t be able to properly upgrade the theme – to gain awesome new backend features – with out loosing my added functionality, or hours of redoing / fixing what was lost.

BUT I’m excited that Magnus mentioned being able to update the woo framework without updating the whole theme in the future. So I am hopeful… I think.

The idea is to build it in a way that the theme works with or without the framework’s functions.

The downside of this approach is making sure your functions are updated when WordPress functions become deprecated. Also, if not careful you end up having to rebuild themes to support newer versions of the framework

Everything that Woo creates works together. That means certainty. It’s the overall “Woo enviornment” that is important to me, not its individual bits or a particular theme. The “richer” that environment is, the more certainty I have, the more promises I can make to clients without having to test beforehand, and the more time I save.

That’s why I love the new nav system ! When the rollout is complete I won’t have to study a theme and wonder about pages and categories, deleting the second nav bar, tweaking the code to add a category, renaming “blog” to something else.

Many sites I build are also not substantially changed for at least a year after I make them. I use WordPress because it’s easy for clients to add content and maintain their own site. What clients don’t do is upgrade WordPress or the widgets. And I’m certainly not going to spend time updating those elements and take the risk that something breaks.

On the other hand if I can deploy a new element with 100% certainty it will work, not break anything, can be rolled back if needed, and gives the client some wonderful new ability, then that’s fantastic! That makes me look good and makes the client happy.

What that means in terms of theme code vs plugins, I’m not sure… But you guys have certainly got things spot on up to now with the evvironment, compatibility and easy updates

The whole is greater than the sum of its parts.

I think you are selling yourself short by not taking it and turning it into it’s own standalone plugin. It has tremendous use outside the scope of the WooFramework. It’s cool enough to be it’s own product.

I think that is where the line is for me. If something makes sense as a standalone product, why not do so? It deserves more attention than just being one of many features.

Even if you gave it away it would be a great marketing tool for WooThemes itself.

It’s the user that will have a bit harder time updating the WF for now, until we build in the auto update functionality similar to what plugins have.

We had this discussion with ourselved in the beginning when we thought of pros and cons of having the WF as a plugin and decided it was best to go for the integrated approach.

I don’t see why themes are trying to do to much is a bad thing if we bundle it into a package like our WF where everything works. As I said earlier, offering addon options as plugins will not be as user friendly as having it bundled with the theme.

But anyways thanks for your opinion, and as I said, we have discussed this internally many times, but come to the conclusion that the bundled package is best for our users.

It is far easier to maintain functionality such as this from a plugin standpoint than a theme standpoint. When you make changes you now have to come up with a way to push them out to users. As of right now that means manually manipulating files, not very friendly. With plugins the auto upgrade capabilities are far more robust… they are built into how plugins work.

When you make a change to the navigation functionality now you have to update all your theme packages to reflect that changes. If it was a plugin, you would just make a change to that plugin and be done with it.

I think the functionality you have built with the navigation would be better suited as a standalone plugin that you make available to your users.

Themes are trying to do too much these days and are blurring the line between theme and plugin by bundling plugin like functionality into the theme itself. This isn’t a good thing from a maintenance and upgrade standpoint.

I know you guys are trying to push the boundaries and make your themes more attractive… but you can accomplish the same thing by offering certain functionality as an optional plugin and do so in a way that makes more sense from a WordPress architecture standpoint.

the first time I saw “custom navigation” as a built-in feature for a wordpress theme was on one of themeforest themes and I should say it wan’t so exciting.

I think it’s not a good habit getting into plugins area. You’re just changing the behind idea of WordPress themes which I think isn’t a positive movement.

Anyway I appreciate your hard work

The custom nav is off by default, and if you want to remove it for a client it’s simply removing one line from your functions.php which is theme specific, so next time you update your WooFramework functions folder, the removed Woo Nav will still be removed.

Making it into a plugin means that our users have to first be aware of the plugin, and secondly download and install it. Having it built in is a much better option overall.

Although I agree that plugins are easier to upgrade because of autmatic upgrade functionality, I disagree that this is the correct way for us to do it. There are two main reasons for this:

1. The framework is easy to update and will not disrupt your theme. We will be looking for an auto upgrade of the WF in the future version, so it essentially does the same as a plugin upgrade.

2. Downloading and installing plugins is one more step in the installation, and it is much easier to have it already included.

Why can’t our framework focus on functionality whilst our theme focuses on design