RapidWeaver 8 - We need your help!

Hey guys,

We’ve been working on RW8 for a while now.

I hope to put out a developer alpha later this week or maybe next, here’s what we have so far…

RapidWeaver 8.0

  • [NEW] New App Icon, and refreshed UI icons.
  • [NEW] New Resources Browser; support for local files, folders, FTP, photos, and Unsplash.
  • [NEW] Added automatic (& manual) support for Facebook Open Graph.
  • [NEW] New Add-ons manager in the Preferences Window, includes support for searching, enabling and disabling.
  • [NEW] Added an option to allow the Web server to start automatically when a project is opened
  • [NEW] Server port can now be specified on a per project basis under “Advanced”.
  • [FIXED] Server name is more clearly shown as editable.
  • [FIXED] Fixed an issue where SSL certificates don’t correctly present the trust window.
  • [FIXED] SSH publishing now allows a pem file to be selected. Public key is now optional.
  • [FIXED] Improved handling of changed files when publishing.
  • [FIXED] Many other bug fixes and improvements.
  • [DEV] Added a new method to allow plugins to insert code just before the closing body tag: - (NSString *)extraBodyHTML:(NSDictionary *)parameters

And of course a whole host of other tweaks and fixes.

I was wondering what other features/fixes you guys think we need or would make our faithful users happy, please let me know and we’ll do our best to include what we can!

Speak soon,


Any chance we’ll see an update to the Blog page style? Or a new sort of Blog page?

@Elixir possibly, what would you like to see?

My main interest would be for a blogging solution that was importable into a Stacks based page, but allowed the nice editing UI and controls of the current blog page. Perhaps a new or update blog page that combos with a specialized stack that pulls the blog into a Stacks page, or some other way to insert the blog into a Stacks page – RW template variable for the blog content and a separate one for the archives? Not sure of all the details, but something to integrate the Blog page with Stacks.

I know many people would be asking for a CMS style blog page, but I think that is a lot more work than people realize.

Yay!!! I can’t wait to test this out. :grin:

1 Like

Hi Dan,

Sounds great so far. A few from me again, some of which you have no doubt heard many times before!

  1. Make %last_published% user editable - i.e. ability to change the date format; dd/mm/yy, mm-dd-yy etc.

  2. Expand on the choice of custom controls available in the theme API for developers to use. Input types like text / number boxes are desperately, desperately needed. A typical usage example would be letting a user type a number in a box, to change the width of their theme or font sizing (instead of the developer needing to provide 10 or more presets from a select menu).

  3. Users sometimes like to add more content to their footers, beyond normal ‘copyright’ info. Content like privacy policy links, legal information, social networking links and other useful bits and pieces. Currently ExtraContent is about the only way to do it. It would be great if %footer% could become a rich text / HTML input (like %sidebar% presently is), with a much bigger editable box. This would make the footer area in many themes much more flexible and more useful.

  4. A ‘nice to have’ feature would be the option to apply some simple Instagram-style filters / effects, on images or banners dragged and dropped into RapidWeaver. Analog within RapidWever! http://mac.appstorm.net/general/analog-simple-and-fun-retro-photo-processing-on-your-mac/

  5. I’ve thought RapidWeaver could do-with a couple more simple page types included, to add value to the core product. Ideas like multiple responsive columns, HTML table, nested list, video embed, embedded maps etc. Certainly nothing on the same level as what many addon stacks can do - I am mostly thinking basic page types geared towards the novice user market who have not purchased Stacks yet.

  6. The blog. I’m not hugely dissatisfied with it, but I sometimes see posts on the forums from people saying it lacks the features they want. If there were options to pull-in content from other blogging services or aggregate social media postings, I think that could quench quite a number of the criticisms / CMS requests. Share buttons would be handy too.

  7. Could the ‘preview in browser’ window be made bigger, with options to remove the browsers that can’t actually preview RapidWeaver pages? I’ve got dozens of apps listed in there that can’t preview pages! Things like Adobe help agent and Android file manager. I’d only want to see Safari and Firefox listed there.

Please can I also ask an extra big favour! Don’t shout me down for suggesting this one: when RapidWeaver 8 is released, please have it available localised in a couple of different languages from day 1 and a free PDF manual available for download. These are both things your wider users will greatly appreciate!

1 Like

Same here. Especially with a feature request I made for Stacks!

This would be welcomed for sure.

Perhaps just an additional RW variable in addition to the %footer% variable. This way past themes aren’t negatively affected. Maybe %footer_content% for example?

Fun. Maybe in the Media Editor, which would allow it to be accessible from just about anywhere you can edit an image in RW.

I know I’ve requested these in private already, but just to let everyone else know in the thread:

I’d really like to see RW manage more of the settings/assets/libraries/frameworks that are site-wide. These things are very difficult (like, close to impossible) to do with a mostly page-centric API.

these things could then be shared via API / templating to themes and plugins(pages). that way the user’s overarching site-settings could stay the same even when they changed themes or added/removed pages.

I’m thinking things like:

  • settings

    • color palletes
    • responsive breakpoints
    • default file extension (php, html, htm, whatever)
    • routing for Apache and/or Nginx
    • .htaccess
  • assets

    • web fonts
    • icons (font awesome or whatever)
    • images (we already have that. yeah!)
  • libraries and frameworks

    • jQuery
    • Bootstrap
    • Foundation
    • Mustache
    • CakePhp
    • Laravel

That’s a big list – but even just adding a few of them would be huge.

With these types things handled at the site-level and exposed via the API, pages and themes could rely on them being installed consistently and correctly.

Stacks mostly does this already – but it has the obvious limitations of a plugin – it’s page-specific and not available to themes or other page types.

Or… don’t even build it… just specify and API for new types of Addons and put a hole in the UI somewhere for plugin devs to fill in. I think I know a guy who might be interested in that sort of thing. :wink:



I’d like to see some popovers with Mini-FAQ or direct links to longer FAQ (the little mac os question mark icon) next to some of the more obscure settings in RW, like the icon drop zones, and meta tags template, etc, etc… I my self was puzzled just today about what the meta tags template actually does. It’s on my list to locate some FAQ on that and investigate. Most new users will be baffled about quite a lot of RW settings, and making access to quick help seems like a good idea. Maybe even a preference to hide all the little help icons for those that don’t need them.

the footer population is a good improvement, now I use the Extra Content.
Also the nativity extra content implementation would be a great addition.


I would like a new plugin for managing and editing resources.

It would be amazing if I could structure resources in the page section and be able to edit text based files from within the plugin.

Also the ability to disable the auto completion of file names that don’t have an extension.

I would like to see a prediction for resource location changes.
If for example my resources are not inside the rw sandwich and are located in place x and then moved to y ( folder structure is the same in x and y) then all links to those resources are broken. If I then fix one link it would really be helpful if it tries to check whether all other broken resource links could be repaired using the new base directory.
Hopefully someone understands what I am talking about :crazy_face:

Cheers Maik

1 Like

Shouldn’t that already work when the RW project is open, and you move the files during that?

I would like to have the possibility to edit text files inside the resources folder with the inbuilt HTML editor.

Uh. I am not sure. But my problems never happened when RW was actually open :wink:

Cheers Maik

This is a very popular option. Using Extra Content embedded in RW8 would be a great feature. Available in the theme, as the banner image, defined in the Plist…

…And the same native stack for Stacks :slight_smile:

Sorry for joining the party late here. This is some things that I would love to see in RW8…

Overhaul the Theme API

The theme API right now is really verbose. It requires far too many individual CSS files to accomplish even the simplest of settings. We need to have more types of settings that customers can type/select values in. Those values need to be able to be insert directly into the Theme’s HTML, CSS, JS, etc.

I realize that this is not a small task. But it would be one that would go a really long way. Probably more so than any other feature for RapidWeaver.

new %plugin_header% macro

I have requested this one for years… Right now this is the only macros available for plugins to inside assets onto the page. For example, the Stacks plugin uses this to insert both its CSS and JS files. This isn’t great because we want to CSS at the top inside <head>. However, its better to have the JS at </body>. It would be nice to give plugins a new macro to insert things that could go at the bottom of the page.

Color scheme management

What if we have a global way to manage colors throughout our project? This would give us a way to easily assign the same exact color to many different color settings and then change them all with one single change. If you were to add some sort of UI to manage all of them in one area and it would be magic.

From a code perspective, I imagine this behaving similar to assigning a color variable inside Sass. I want to be able to define my color values centrally. Then inside any color setting inside the theme or plugins (ahem, Stacks) I could choose which color I want to be used. By doing this way, I can easily swap out any color that I want in my entire project simply by changing its value inside the color scheme manager.

This feature would definitely make RW stand out. It would save users tons of time and make RapidWeaver so much more powerful.

htaccess manager

This is a pain point for users. I have always thought that this would make an amazing plugin for RapidWeaver (If only I had the time). However, it would be even better if RapidWeaver could do it for us. At a minimum, it would be great if the user could just add a text page to the project and set it to publish as an htaccess file. Then the user would be responsible for configuring the settings inside of it. It would be nice if there was a UI. But if at least we can manage and publish an htaccess feel from inside RapidWeaver, that would be a win.



However, its better to have the JS at . It would be nice to give plugins a new macro to insert things that could go at the bottom of the page.

Someone didn’t read TFA at the beginning! :stuck_out_tongue:

[DEV] Added a new method to allow plugins to insert code just before the closing body tag: - (NSString *)extraBodyHTML:(NSDictionary *)parameters

But, yes… all of these things are good. I think “overhaul of the theme API” really fits in with what i mentioned before: managing the site-wide settings.

More template locations for both theme’s and plugins. Maybe something like “extra content” but more generallized. Allow the theme to add a new content area and give it a name. That way they could add a “footer”, or second-sidebar, or whatever – and it would automagically put that content into a specific template.

That would be pretty cool.


Oh! What about HTML doc lang as a setting? That would be nice…