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
Please post your feature requests below (however big or small), and we’ll see what we can do!
Dan & Tom
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.
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.
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
- 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:
- 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
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.
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
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.
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