I'm looking forward immensely to 1.0 version of Vanilla (maybe soon?) but am a little worried about installation / upgrading.
It was only after I had installed and implemented 0.9.2.6 that I realised there was a newer, beta, version. I tried my hand upgrading to this and failed miserably - it was not within my ability.
So here is my question, how will the upgrade process for V 1.0 work? Will it be simple or will there be lots of messing around in the code to be done?
Basically, will us non-techy types have to start over from scratch?
giginger is right. I haven't written it yet. But I will be setting up all old versions of vanilla locally and then writing a single upgrade script that works on all old versions of Vanilla bringing them up to version 1.
Let me be clear: all Vanilla files will be replaced. If you have made local modifications to your files (other than configuration or language settings), they will be overwritten by the upgrade.
There is no way I can write a script to parse through the files looking for changes you've made to core libraries and maintain those through the upgrade procedure.
good god i am getting very excited over this. a wordpress plugin would be especially excellent. and also, i'm glad to hear that my older beta version won't be a complete nightmare to upgrade.
Lech, can you reveal the monstrosities behind the wordpress curtains?
I haven't used it since I tried TXP, have propably forgotten alot of things in it. I allways liked it's admin interface more than TXP's but other than that, WP loses to TXP.
If you could somehow squeeze the templating styles of WP and TXP together it would rock.
So that you could make and assign separate "page templates" to different sections, and do the same for different sidebars/headers/footers it would be awesome.
The page that I'm admining with TXP has different sections and only thing that changes from section to section is the sidebar (and one occasion the "article form" changes), so I have to have several different templates for the sections.
What I would die for is that you could assign per section (maybe even per page) your sidebars, headers, footers, and the main template (article form in TXP).
This way, I would just have several sidebars and all the rest (header,footer,article main) would be set to default. And when I had to make a change, I would just go to the sidebar and change it, maybe it even could be managed with textile so that someone who doesn't know html or php could add things to it (kinda like in TXP with the tag generators).
You can always split your sidebar code off into an external php file, and include it. Then it's a simple switch statement to determine which section you're in, and include the proper sidebar.
Kosmo, it's seriously one of those things you don't expect a function to have. At least if it does have it, it should be documented saying "if this is enabled for a post, it spits out this"... If I had known this before hand, I wouldn't have used the function.
I'm not entirely familiar with all the ways they do things, but I'm slowly learning to hate some of the predefined and unecessary markup they've injected into the core of this wee-beasty. However I do like the simplicity and flexibility with some of these function calls that really doesn't require me to focus on having to do heavy programming.
Here's just one of the functions in question: http://codex.wordpress.org/Template_Tags/comments_popup_link
Now, the problem with the above function for example is this: if you throw that bit of code into a neatly packed area, all appears well. Until you decide to password protect the post, this is when all hell breaks loose blowing holes in your markup. What was once stored in a nice compliant unordered list expecting to display a link with JUST a numerical count is now torn apart with unformatted text, a form outside of it and the style which you thought was perfect is now fubar.
It's a bit like driving home completely wasted without knowing where the hell you are. Nowhere in the documentation or even the rest of the site for that matter could I find anything relevant pertaining to this event or how to modify it's output without hacking apart the source. I don't want to hack source, because, the moment a new update came out, I would be forced to do it again, and frankly I don't have enough spare time to invest in something of that scale each time a new release comes out. The forums there I've learned don't appear too helpful either and sadly, attempting to contact any dev with legitimate questions go unanswered.
It's easy to work with, I'll give it that, but this applications functions seem to suffer from the same progressive redundancy as php itself does and that doesn't appear too promising. If there's two things I'd love fixed with WP, it would be in the following order:
1. Weed out all the default markup from the core and move it into the template tag parameters. Or only display it if a parameter isn't present. 2. Consolidate all like template tags into one universal tag, even if there are a billion parameters, I wouldn't care so long as I can control every aspect of how things output.
If I had a third wish, it would be to document stupid shit like this in the event I enable something again and next time be prepared for it to break my lovely code.
"giginger is right. I haven't written it yet. But I will be setting up all old versions of vanilla locally and then writing a single upgrade script that works on all old versions of Vanilla bringing them up to version 1."
TXP has include functionality built in using txp:output_form and forms for code or dynamically created sidebars (e.g. linklist-driven blog-roll, recent news, related articles etc.) or txp:article_custom id=## for outputting a certain article with static content (e.g. simple text or hard-coded images).
If you've got a fairly uniform page template with only certain elements that change, you can write each of your sidebar's in a form (dynamic) or an article (static - textile is then usable and articles are guest author editable).
In your page template you can then use txp:if_section to specify which sidebar item should show up according to the name of the section. Use txp:output_form to call a particular form or txp:article_custom id=## to call an article. If you use txp:else you can provide a fallback if none of the if_section calls are met. You're not limited to forms or articles, of course, you can also use normal code, txp:functions or plugins e.g. to include a flickr gallery.
You can use the if_section several times over in your template if you need to change headers etc. per section. As an aside, it's worth putting headers, footers in forms too and calling them from the template via txp:output_form so that if you have to make a sidewide change, you just change the form and it applies to every page template immediately.
If you like conditional tags add some intelligence to the basic page template. It's great for fairly uniform designs that vary slightly.
Other if... conditionals are also possible, e.g. txp:if_custom_field name="myfield" val="xyz". You could use this (or another if) to change how the template behaves on a page by page basis: Create the custom field once in the admin, from then on you need only enter a value for that custom field (e.g. "yes" or "special" etc.) in each of those articles which should appear differently. Again, any guest author can do that. You provide for different display by detecting the existence of the custom field in your page template and determining how it should appear.