Rapidweaver 8.1.2

Hello just now I updated Rapidweaver to version 8.1.2 and now it crashes when trying to open. I restart my mac and close all windows etc and it still is unable to open because it crashes. I have put my Rapidweaver back to 8.1.1 via time machine. Any other experienced the same?

Kind Regards

8.1.2? Where did you get it from? I have no update notice (regular or beta) about an 8.1.2 version.

update: it just rolled out. ignore previous post.

Zero problems with 8.1.2. But also zero problems previously.

I believe most of the problems folks have been experiencing had to do with resources. That’s simply a feature I don’t use. I warehouse (FTP) all my resources directly to my hosting area. I do use a very small number of drag-drop images in some stacks: but that process does not seem to have been a problem for most folks.

1 Like

Hello I tried update Rapidweaver again and now it is working. Do not understand what the problem was. Anyway the update is working. I also think that when all the bugs have been ironed out, I will really like Rapidweaver 8.1, actually I already like it but sometimes my weak nervous system cannot handle bugs :-)

1 Like

@kent - v8.1 introduced quite a barrage of new things. and also some significant plugin-api changes. and also a new file format. in my professional opinion, that’s a lot of new for a point release. 😬 so i think if you’re a pro managing a larger project – or several – then there’s solid rational for caution.

in software that i use professionally, i try to wait for:

  • all data-loss bugs to get ironed out
  • the rate of new reported bugs to fall off
  • some stability

so, how’s RW doing?

  • the scary resource-linking bugs in v8.1.0 seem to have been ironed out. phew.
  • the rate of new bugs? there are still quite a few, but it’s slower than it was. it’s a judgement call.
  • stability… well, there was a new build released this morning. and a recent build will trigger a new build of stacks tomorrow. so… not quit yet.
    but with a little luck one of these builds will stick around for a week or two. when that happens, it’s probably safe to say, “come on in, the water’s fine.” 😉

the good news is that v8.0.3 was a pretty solid build. i still use that version of the frameworks when building the release version of Stacks. it’s a good one.


Something against that: backup backup backup your RW projects…

So back ups of Version 8.1.5, Version 8.1.4, Version 8.1.3, Version 8.1, Version 8.1.1, Version 8.1, Version 8.03? And some Version 7?

Why not?

Edit: don’t shoot the messenger. Just trying to suggest ideas.

so, how’s RW doing?

@Isaiah Thanks for this post! My regular readers (rapidweaver.ninja) expect me to review new releases as soon as they become available. As such, I installed to RW 8 as soon as it was released as a Beta. I don’t mind testing beta software, it can actually be fun and I’ve tested betas from numerous LARGE companies, Apple, Adobe, Quark.Inc included.

What I don’t consider fair to the users is when an app is released as “Final” and then continues to issue Beta 0.1; 0.2; 0.3 “Final, Final, Final Releases”.

I don’t mind waiting until an app has reached a ‘final’ stable version before committing to a purchase, or an upgrade.
And if the Golden Master (which Realmac has obviously never heard of) proves to be buggy, I expect it to be withdrawn and will wait for the Golden Master II! Remember OS X GM00.1??

I’ve used RW since it’s earliest beta release and after experiencing several buggy updates (most especially 6—7 and 7—8) I’m becoming disheartened by the products being pushed by Realmac.

In my opinion, it’s unfair to allow regular users to test beta products. Test; test again until the users have finally identified a ‘stable’ product – this is simply not the way that a professional software smithy works.

For my ‘professional’ websites I still use RW7.x.
I’m still waiting for “come on in, the water’s fine”. And this announcement for RW8 doesn’t look as if it 's coming any time soon.

Happy Beta Testing!!


this is a well considered position. 👍 and you are certainly not alone.

and this is why Stacks 4 will include RW 7 support.

hopefully Stacks 4 will be stable a bit more quickly than all that.


As Billy Connelly would say, TicketyF**ketyBoo. Great news.


I know it’s hard to believe, but currently Stacks offers RW 6 support. So moving to RW7 support feels like Mel Gibson yelling: FREEDOM – i can do so much more now.

That said, I have to drop at least one large feature for RW7. Booo!!! I hate doing this. 😡 But there’s just no nice way around it.

We’ll have a nice warehouse image stack that uses RW resources to do the warehousing bit.

Basically an image stack that always references a resource that’s only published once for the whole site, only loaded in memory a single time, and only as part of the project – not each page.

Warehousing AND doing it with resources. It’s a HUGE win for memory, for publishing, for loading time, for preview time, and… well you know… everything.

But RW7 has basically no API for resources.

(╯°□°)╯︵ ┻━┻

So on RW7 that stack just won’t appear. Bummer I know.


So are you saying the new S4 image function to use resources will not be present for RW7 with S4 but everything else will?

@Webdeersign - pretty much. “everything else” is nearly true, but not quite.

there are always lots and lots of tiny differences between different versions of RW. however these are normally either cosmetic or workflow features – transparency, window shapes, button positions, etc.

Stacks 4 will have two big things that are version dependent:

Dark mode requires Mojave (this one is pretty obvious)
Resource Images (warehousing) requires RW 8.

It’s a significant omission, though. And I think the first time I’ve ever included a functionality difference between RW versions. I try really hard to avoid that – but in this case the alternatives were terrible.

either huge extra dev time + schedule delay OR drop feature for everyone. yuck and double-yuck.

1 Like

Thanks for this information. Neither the dark mode or resources are of any interest to me, so that’s perfectly fine.

@isaiah OMG! This is fantastic!

My question: there’s at least 3 ways to get images uploaded:

  1. drag and drop into a stacks window (or whatever is the official word)
  2. use resources
  3. directly FTP yourself and copy relevant URL link with Transmit or other app

Does this new capability change anything about drag/drop types of image stacks? Will it be possible to “drag” a resource into a drag/drop area? Sorry, I don’t use resources at all. Just FTP. But there are some image based stacks I use once in awhile that only offer drag/drop options. Would be beautiful if they could also take advantage of this new feature. If so, that solves a LOT of problems/workarounds.

  1. I hope I am able to get Repository Stack to make this happen also (either with clipboard link, or drag and drop a icon to the Stack)
1 Like

@Jannis That would be sweet! Repository is a “must have” stack already. That would make it even better.

1 Like

I won’t be able to answer this question with confidence until after I let the developers have Stacks for a bit. And currently only a tiny few have seen a very alpha version. So I don’t really know.

Obviously if a stack only exists in one location at one size, this lops off quite a few stacks image api features. lets see… transforms, scales, crops, shadows, borders, retina-export, format-conversion, jpeg-compression… i think that’s probably all of them.

3rd party stacks that rely on those features obviously can’t use these new images. but there are actually not that many of those, to be honest. and for that reason, i’ve left this very open for now. i’m basically going to give the stuff to the stack developers and see what breaks. then see if we can find the most minimally invasive fix.

there are lots more caveats i could go into. but the hope is that it will work in “most” places. what “most” really is, i don’t quite know yet. give me a few weeks and i should have an answer.


1 Like