Two things that would really make RapidWeaver a top-notch tool are a way to import a site, and having develop-time access to the stacks IDs so they can be used for CSS, etc., manipulation.
Import
As more and more people are wanting control over their sites, keeping a locked, one-way, site management system is getting harder to justify. Tools like Dreamweaver that can “import” sites make dealing with user-spawned changes (such as with Contribute) much easier, and, frankly, more attractive than RapidWeaver as a solution.
Please, somehow, figure out how to do this!
Stacks (div) IDs
I know the first item just may not be possible/plausible, but maybe this one is - can we developers have ID control over the stacks div ids that are generated??? Pretty please? With sugar on top???
THANKS for entertaining my perhaps impossible requests!
on div IDs:
there are two solid reasons why this will probably always be infeasible:
PlusKit users need all IDs within a document to be guaranteed unique. Making them user-editable would remove this guarantee and make the any bugs users created because of that very very difficult to find.
3rd Party stack developers rely on IDs to be predictable, valid, short, and unique. The Stacks API currently guarantees all of these things. Making the IDs user-customizable would mean not meeting those guarantees – which would likely result in broken things.
over the years i get this request a lot. nearly all the time i find that it’s for one of a few reasons:
SEO
i can assure you that element IDs have nothing to do with SEO. google just doesn’t care if/what/how you name your DOM elements.
a way to connect some custom CSS/JS
if you want to add a bit of custom CSS or JS – then Stacks does guarantee that any stack that you create will have an ID that, although its computer generated, will not change over the lifetime of the document and is pretty easy to type. You can go ahead and just use the ID that’s provided.
a way to connect a JS library or jQuery plugin
in some very rare cases there are some (poorly written) libraries that require DOM elements to be given very specific IDs. In this case I usually recommend attaching those JS events (or whatever) to an element inside of your stack – rather than the stack container divs. You can use a 3rd party stack like Joe’s Box stack do create a dummy element for this purpose.
3rd part stack development
the API provides nice IDs that meed all the previously mentioned guarantees so that stack developers don’t have to. they’re available through the %id% template. use them!
Just put the things that went wrong in an error container and let the site developer deal with it. 'Tis common practice for many things.
What I mean is, and I should have said this earlier, if a site was developed with RW, then it should be importable. This will allow people to use 3rd party tools to manage their sites, such as Contribute, and provide more than a one-way solution.
Regarding item #1: RW can facilitate unique ID’s (and I don’t mean just by the generation algorithm) - not too hard to programmatically check and make sure the ID isn’t being used anywhere else (for example, it is done with file names). This also addresses #2 - if the IDs can be generated, they can be manipulated, pretty straight forward.
In the reasons section, #2 & #3 are THE reasons to know those IDs and are perfectly valid “wants.”
If the IDs can’t be modified, at least expose them at develop time so there’s no need to publish, check just to find out the ID, then go back to development.
Question: and I’ll look for this in the docs, is %id% anything like the %resource% macro, in other words, how is it used - can it even be used at develop time?
BTW, in case this wasn’t clear, by “develop” I meant site construction, not stack/tool development.
…but i can point you in the right direction for some docs on the ID and other things too. the stack element ID is fully exposed for stack developers. you can not only get the id of the current stack – but of the parents, of the page, the paths and URLs to those things – and lots of other cool stuff.
I don’t tend to talk about dev stuff and code on the forum very much – it tends to send novices in the wrong direction. Instead I usually ask that folks interested in code and the stacks api post questions on the stacks slack channel here: http://slack.yourhead.com
