RapidWeaver 7.1.3 Now Available (Fixes Export Crash)

Hey Guys,

Good news!

I know a lot of you have been experiencing crashes since upgrading to RapidWeaver 7.1.1, and I’m sorry for that. However, I’m pleased to announce that we just shipped RapidWeaver 7.1.3 and yes, this fixes the crash on export issue!

I tested this with almost 10 different customer projects and it fixed the export issue in every case!

Check for updates or download the new build directly from here:

Right, I must get back to it as we’re busy working on RapidWeaver 7.1.4 - We won’t stop until RW is perfect for you all.

Happy Weaving!




Is RW 7.1.3 is JUST for Sierra…?

Thank you

@Fitz @dan The link above downloads (at the moment of writing) build 18333.
That one does not run on El Capitan.
I just restarted RW and got a message that a new version was available.
Having a back-up, I updated and after installing and restarting it appeared to be build 18338, which does run on El Capitan.

@Macmenno Thank you for your an answer…

Nope, sorry. Updated the link and the new download will work on 10.11 and upwards. Sorry about that!

I had some trouble with the 7.1.3 update at first. 2 recent projects opened with the RW startup, and the update notice appeared, then the program crashed. This happened a few times before I got the update installed.
Now the program freezes when I try to save progress. I forced-quit, and lost 30 minutes of work. (typing in the blog)
Ah well. Never give up. Never surrender.

Oops. I just tried to save again without making any changes. It froze even though I had not typed anything new.

I’ve spent the last 2 hours trying to find a fix. I can open a new project and twice I was able to save the new one. But not always. Existing project always hangs on save.

No problemo… everything is working well now!!!

I believe I found my problem. I tried deleting pages one at a time. After I deleted the Pluskit plugin, everything worked fine. I will see if the same thing happens with other projects that have plus kit.

Hi guys,

We’re researching a crash with PlusKit. We know it exists, it’s just been hard to track down. It appears that the crash involves some interesting corner cases.

I have one example file from a customer (thanks for that, if you’re listening) – but it’s about 400 pages long – I haven’t even been able to locate the pages where PlusKit is being used. :stuck_out_tongue:

It will take me a solid week to sift through all it. No joke. :cry:

If anyone has a small case that demonstrates the crash succinctly then it will expedite a fix for this one immensely. Would love to get this nailed down much sooner.


1 Like

I just tried putting a new PlusKit page into the same RW project that had the problems before. Then I got a warning that all my blog posts were corrupted. I didn’t have time to click okay on all the warnings, since there are so many posts. So, I did a force-quit. I reopened it and deleted the PlusKit again. Now all the blog posts are empty. The titles are still there. But the content is gone.

After spending the day researching crash reports we have managed to get to the bottom on one significant crasher. However I should warn some of the bug reports are pretty diverse, so it’s likely there is more than one.

We’re going to release a Stacks update ASAP (hopefully before bed tonight) but in the meantime, if you’re experiencing this bug, there may be something you can do to work around it.

The bug we found is this: some folks were using PlusKit to import one Stacks page into another Stacks page. While this should definitely work (and will after the little update to Stacks) it’s not the best way to solve that problem. A simpler (and working!!!) way to do this is to use a Partial.

Partials are faster, more efficient, and much more flexible. And best of all, today… they don’t crash. :stuck_out_tongue_closed_eyes:

If you don’t know about partials, you can learn more about them here in this video: https://vimeo.com/136154079

Also, keep your eyes peeled for a beta version (probably just for 12-hours to make the rounds with a few testers) then we’ll get this new build out ASAP.


1 Like

I’ve posted a beta to developers and testers. It’s very bleeding edge, but if you’d like to help test, I’d encourage you to do so ON A COPY of your file. Please keep bleeding edge beta builds well away from your mission critical work.

###Stacks 3.2.4 beta 1

Hopeful fix for problems with PlusKit in RapidWeaver 7.1 when importing Stacks pages into other Stacks pages.

Note: PLEASE DO NOT DO THIS. Use partials to import content from page to another. It’s much more efficient and less prone to errors and side effects.

Download: http://yourhead.com/appcast/RW6/beta/Stacks3/Stacks_3.2.4b1_3863.zip
Release Notes: http://yourhead.com/appcast/RW6/beta/Stacks3/release_notes_3.2.4b1_3863

BTW: if you’d like to see more betas (not just of Stacks) we have Slack channel: http://slack.yourhead.com you can find out more about it on Twitter http://twitter.com/yourheadsupport or on our blog: http://blog.yourhead.com

1 Like

Doing so allows you to put the same stack on all pages, not just stacks pages. I use a lot of styled text pages and accordion plugin pages. Pluskit lets me add a stack in a Blog page, a DateLoom page, a FormLoom page… etc.

I would always encourage people to do the opposite: put an accordion page’s content into a stacks page, rather than the other way 'round.

The reason is simple: Stacks content is much more complex than any other plugin – a stack can add content to all parts of the page – PlusKit only has access to limited parts of the page to inject its content. This means that when you inject a stacks page you run the risk of missing important parts.

As with all things PlusKit, it works most of the time, but YMMV and it is mostly left to user’s discretion.

And I think it should go without saying: never put a Stacks page into another Stacks page. We try to make this work as best we can, but it will almost always cause more problems than it solve.

Plus, partials work much better. :slight_smile:



Thanks Isaiah.
Unfortunately for me, the large volume of changeable content in my site makes stacks impractical. While the versatility of stacks is great for small sites, it is just too awkward and time consuming for large sites like mine. I tried building my site with stacks, but I ended up replacing hundreds of stacks pages with styled text and Accordion pages. The Accordion plugin is awesome, BTW. If it ever stops working, I will stop working. There is no way that I could do what I do using stacks unless I were 10 well medicated people.
This is my last post for awhile. I will be in Switzerland till November.

I believe I’ve had a look at this attempt – by way one of the crash reports I’ve seen. And I would agree that hand crafting hundreds of pages in Stacks for a single site is probably the wrong approach.

Your pages are largely the same – or at least similar – but each with their own content/data – you would do well to look into a CMS style solution – where the data is separated from the site’s design. That way you could build a few page designs and and have the CMS inject the correct data dynamically to fill out the hundreds of pages.

Check out Easy CMS, DropKick CMS, and Total CMS – there are more too. Everyone else feel free to chime in with some other good RapidWeaver CMS solutions (with or without Stacks).


Oh, I almost forgot to mention it: There’s a new version of Accordion that should be coming down the auto-update wire very soon (a day or two tops). Just has a few fixes for Sierra and a crash-report we saw for RW 7.1 this morning.

I’m sorry to have to tell you that it does NOT fix the export issue in every case.

Had you tested it with our project for which we have provided logon credentials you would have found that it crashed.

As you know, we have had issues with uploading ever since ‘upgrading’ to v7 - months and months of agony.

We have updated to Sierra, applied the latest upgrade (7.1.5) and RW export still crashes every time after having uploaded just 500 or so of 2,400 odd files to our site.

Export will only Test ‘OK’ on “1 - Slowest (Compatibility Mode)”, starts uploading and crashes.

No problem uploading the site manually using FileZilla and 3 connections, but that is a pain, very inefficient, fraught with problems and not the way RapidWeaver was designed to work.

Are you willing to do what’s necessary to get this fixed?


I apologise for an error in the previous post.

Testing connections 1,2,3,4,5 and 6 ALL test OK but none other than connection 1 will upload even a single file.