RapidWeaver 9 Developer Feature Requests!

Hello you lovely Developers,

We’ve finally started work on RapidWeaver 9, and we’re wondering (again), what you’d like us to add to it?

We plan to make this an open beta from fairly early on, increment slowly, and get user/developer feedback as we go.

We have a build of RW9 up and running, but don’t worry though that’s not the final icon, it’s just something we threw together so we can tell it’s RW9 in the dock :wink:

Please post your feature requests below (however big or small), and we’ll see what we can do!

Cheers,
Dan & Tom

Hi Dan,

sounds great!

What’s about this basic plugin page you developed for RW8 Beta? Will this have a chance to get into RW9? This was quite neat.

Cheers, Jannis

1 Like

Hmmm. I’ll have to think on this a bit. Wasn’t expecting a new version yet. Will try to mull it over and present some ideas if they strike me.

Obvious

  • a caching strategy. currently contentHTML is called for Preview, Publish, and Export – often at the same time!!! there’s no hint to the plugin what if any part of the params dictionary has changed – so the whole of the content must be generated from scratch. i’ve made this request more than a few times over the years i’ve proposed a bunch of ways to improve that. but really anything that’s backwards compatible and involves not generating the whole page from scratch in real time would great.

  • make a workable public API so that this bummer stops. currently very few of my plugins actually work because the api methods used by older plugins have been marked private. and now keep fluctuating, breaking all my stuff, and making it hard to stay in business.

These first two groups are dev specific API stuff

API Stuff

  • add notifications to let plugins know when resources are added/removed/relinked/whatever
  • the current resource api makes it difficult/impossible to do basic things (e.g. create, delete, duplicate, rename, get info) without a lot of boilerplate and use of private methods. seems like working with user data should be simple, bullet proof, and easy to figure out (since it’s not documented beyond a few header comments).
  • an ExtraFiles method for site-files that isn’t a class method.

Resource Specific API Stuff

more resource types. we can refer to a single project-wide file by using a resource %macro% – i’d like to see the same for other kinds of website building stuff too:

  • colors
  • links – so you can change a link in one spot and then everywhere it’s used around your site gets updated
  • text snippets
  • code snippets

The rest of these are more user-facing features

Page Specific Stuff

both the user and the API should be able to easily place content/code at more specific places:

  • top of the body

  • bottom of the body

  • page prefix (for php)
    Yeah, some of these are possible by the API or by the user or at the discretion of the theme – but it would be nice if it was standard and consistent.

  • instead of plugins having their own linked CSS file, RW should have a CSS api method and append, (sass compile?), then compress all both css files together.

Site Specific Stuff

  • dark/light mode detection for themes

  • other built-in open-source compression/tidy/validation stuff

    • compress CSS
    • Sass
    • Javascript minimization
    • Tidy
    • Validation
  • a window (or whatever) full of quick access bookmarks – both project specific and global.

    • project specific: for your site, test-site, store page, c-panel, host-support-site, etc.
    • global: markdown ref, javascript docs, your favorite stack developer, rw-forum
1 Like

In addition to the requests by @isaiah a clear strategy regarding JavaScript loaded at the end of the body tag.

I know that theme developers are able to define where this is loaded currently, it should really be changed to body bottom.

If this were implemented I think it’d be wise to have this only happen if a theme opts into this in the info.plist file, otherwise existing themes could be borked, and hence screw up users sites.

Yeah, I know the implications. Good idea :+1:

Couple of Site Wide Things:

• CSS minimization
• JS minimization
• Async loading of JS. Using async property at a minimum.
• Async loading of CSS. Great article: https://www.filamentgroup.com/lab/load-css-simpler/
Solution is just: <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Great suggestions, please keep them coming — I’ll be sifting through them over the next few weeks and working out what to add!

@tom is away on a well deserved holiday for the next few weeks, but once he’s back we’ll be kicking RW9 into overdrive.

Happy Weaving!

Cheers
Dan

It’d be great if we had access to the current preview server URL, and perhaps a way to turn it on if it is not currently running.

The Emporter plugin I’m working on could definitely use a more formal API to address this rather than me monitoring the processes that RapidWeaver forks :slight_smile: