Problems with links Since Upgrading Stacks 3.6.6

Hello- Not 100% positive its since upgrading stacks, but I upgraded stacks last night and the problem started appearing today:

Creating links creates “unstable” links

Create a blank stacks page, ad a text stack, add some text and make that text a URL link, it does not convert that text to a link in preview until I go in and out of preview for about a minute. Eventually rapid weave recognizes the text as a link but in some cases, I have to quit RW and open the project again.

Once it recognizes it as a link, the link address is added the to the end of the URL of the site.
Example: my site is - I create a URL link of and when I open in a browser and click the link, it tries to go to

The only way I can find around this is to quit RW immediately after creating the link (don’t click it!), reopen the project, and then that link works. I’ve never had this problem until today.

2018 MBP with 10.14.2 and RW 8.0.3 and Stacks 3.6.6 - I’m just using the built in stacks stacks came with. Multiple restarts and the usual troubleshooting.

Anyone else seeing anything similar?



1 Like

Tagging @isaiah

There is no
I would bet that your website address on the site is:


Hi Bill,

Thanks for the bug report. I think you’re right, there is definitely a bug in Stacks that is causing those links not to be recognized until you stop editing the text box.

And it’s worse that that too – it actually causes some of the other text editing toolbar buttons (like Bold, Italic, etc.) to misbehave – again, until you click outside of the text stack – or quit RapidWeaver, that obviously gets things back on track too.

Your problem was kind of a two-parter though. So I think I should break it down a bit and answer each part separately.

This is the bug that I see too. It isn’t a very new bug, however. After a bit of testing it seems like I introduced the problem around August of 2015. What is new is that the RapidWeaver preview window behavior has changed quite a bit since RapidWeaver 8 and this bug has become a lot easier to spot.

So, I suspect if you go back to Stacks 3.6.5 you’ll see the same problems – but if you go back to RapidWeaver 7 – it will be a whole lot harder to make this bug happen.

But, it is a bug and I’ve got a fix on the way. Yeah! I’ve filed the bug to my public bug tracker here.

If you’d like you can sign in there and follow it’s progress. It should get fixed fairly quickly a week or so if all goes well.

In the meantime you can simply click anywhere outside of the text stack – just in the white part is fine. Once editing stops then the Preview window will recognize the new links you’ve added.

I’m afraid I was not able to find any bug quite like this. Nor has anything related to links and their creation changed in the last version. So I suspect this may have been a combination of a slightly confusing link-box combined with the confusion created by the other bug.

but try this: when you want to link to some place outside of your website, just make sure to enter the http:// or https:// before the link. If you don’t enter that part then RapidWeaver assumes the link is to your own site and adds your site’s URL in front – which would create the crazy links like the ones you wrote about. I don’t think the link panel has changed much recently – but the link panel is actually part of RapidWeaver the app and not Stacks – so I’m not 100% certain.

But give that a try and see if you get some better links. And look for the new version of Stacks in a week or so.

Thanks again for the good bug reporting! You can’t imagine how rare that is, how much time it saves me, or how much I appreciate it!



Hey- No prob… it’s a community of software.

I know I’ve run into this url link butted up against a page link before… But years ago and I can’t remember how it was happening. I’ll keep playing later today and see if I can create a solid way to reproduce.

Thanks for the quick attention.

1 Like

Hey @Isaiah - I got the url “merging” to reproduce but its hard to get it to do so and I’ve only been able to get it to reproduce 1 time after about 20min of trying. May/may not help, but this is what I had to do:

  • Steps to setup as drafted in original post.
  • Instead of clicking outside the text box or restarting RW, go in and out of preview (monotonous, I know)
  • After awhile, the link is recognized, but RW seems to be combining what looks like a page link with a URL link

Not sure I’d make this URL merging thing a high priority. Its hard to reproduce and its probably somehow related to the other bug.

Also, in case it helps (and I didn’t mention this earlier), I’ve been making sure to add the http:// and https:// in the full URL. I just quickly setup the snapshots for reporting purposes.

Hope all this helps.

the key piece of info here is how you’ve set up that situation. there are a lot of ways to set up a link – and set the your site-url.

of course, normally you’d never ever expect a link like that to come out of RapidWeaver – but if you had accidentally set up the link in a crazy way or accidentally set up your site URL in a crazy way – then that crazy URL might be the crazy-correct output.

i’m not saying that you did set up things in a crazy way – but without more details it’s hard to tell for certain. and when talking about bugs that only show up after clicking the preview button the 20th time – all possibilities have to be considered, because that’s pretty crazy! :crazy_face:

if you gave me a file that has one of these sorts of links in it – i can probably say, with a lot of accuracy and detail, exactly why the link looks that way and if it’s a bug – or just a bit of accidental craziness. if it’s a bug i’ll make sure it gets fixed along with the other one you found.

it shouldn’t be too hard. once you get the link to preview that way, just save the file. that should freeze everything in place. then zip it, and put in dropbox (or your favorite file sharing tool). then post the share URL (or send in a private message if you like).

How offensive you’d suggested I did something in a poor way. Just kidding. Its a perfectly fair assumption especially since even though I’m a very long time RW user, its not my profession and I only dig in part time.

I’ll post a RW file, but it really is just 1 page with 1 stack. Very bare bones.

Now, to answer your question: I selected the text, click the link button at the bottom of the RW window to the left of Style. Have played with clicking the box ‘open external window’. Doesn’t seem to make a difference. Otherwise, just quick and dirty click link button, select URL, enter URL, click ‘ok’.

Feel bad clogging up the RW forum with this. Let me know if there’s an easier way to get you info, but don’t mind this method if it works for you.

Talk soon.

  • Bill

For a link with a typed in URL there are three important details that govern how the link gets generated:

  1. Settings > General > Web Address:
    the first is just the URL for your site. it’s in the General settings and labeled Web Address. in some cases this is used to help generate URLs.
    to give us a concrete example to work with, i’m going to pretend you entered in something reasonable like:

  2. Settings > Advanced > File Links Are:
    This is a setting that can alter how RW formats the URLs it generates. The basic URL is the same – it’s just written in different way. Or at least that’s the theory. In practice, when the URL is crazy enough not to be a real URL, the formatting that RapidWeaver chooses might be equally crazy.
    For the sake of example, let’s pretend you had it on one setting and you changed to another and see how it affects the URLs. We’ll start with the default setting Relative to Page and then change to the last setting (also popular) Relative to Website Address

  3. The URL
    The last is how you write the URL. And the devil is in the details. Which parts you include matter. If you make a typo that matters too. So, let’s see how four typed in URLs get handled:

    • Fully qualified:
    • A newer way of writing a fully qualified domain name that drops the http so it can either be http or https: //
    • An absolute path URL – this is not a valid url – but a common mistake for novices – and an easy typo from the one above: /
    • Just the domain name – this is not technically a URL but many web tools accept this and try to do the right thing

OK, so here’s what you get if export any RapidWeaver page (doesn’t have to be Stacks) with the URLs above and the default Relative to Files link format: ==> :white_check_mark:
// ==> //
/ ==> ==>

That’s pretty much like you’d expect, I think. Only one modification is made. It’s to the one that really doesn’t make sense. The first two work, the last two look ok, but they won’t actually work. You really need that http:// to make a real external URL in RapidWeaver.

OK, same URLs, but this time let’s switch to Relative to Website for the link Format setting: ==> :white_check_mark:
// ==> :x:
/ ==> :x: ==> :x:

OK, now we’re getting CRAY CRAY :crazy_face:

The first one look great. That’s clearly how RW expects things to work.
And the bottom one – well that’s just like the first example. I’m not sure why RapidWeaver doesn’t tack on the http:// – maybe there’s a corner case where this is important?

The middle two tho… those look remarkably similar to your original post. That’s probably more coincidence than anything – but I can’t say.

What I can say is that it’s really really easy to make RapidWeaver generate some pretty crazy URLs. Depending on your settings – it’s not even hard.

But if you share that file with me, then I can tell you exactly what RapidWeaver is doing. And we’ll know for sure.


Hey- Ok, to make it more symmetrical, I added it to the one and only web site I work on. It still does the same thing intermittently which is good from a troubleshooting perspective.

My settings>general has the correct web site and settings>advanced is set to relative.

Happy to send over project file. Where do you want me to send it?


  • Bill

If you can send a file that has one of these bad links saved into he file that would be super.

Without it, it seems like there are still too many possible scenarios.

Oh man… I don’t have one with the bad link. I’ll try to reproduce and if I do, will send 'er in.


ok. i think i’ll let this sit until we can get a bit more data. until then there isn’t quite enough info available for me to give any specific advice.

but look for a new stacks version with the other bug fix at the end of the week.

Howdy- Sorry, forgot to reply yesterday. I was able to make a file that reproduces it. Think I found what causes the problem: If the URL lacks the http:// and has a path.

Example: doesn’t seem to cause a problem is ok off and on always creates a link path relative to the site (the problem)

The example has 3 links: top is fine, middle is broken, bottom is fine.

In the end, this may technically not be a bug, but might cause people problems who don’t really know to add an http://

File is here:

Thanks and enjoy!

  • Bill

@wphall - i think at this point we should flag @dan to mention this.

the link generation, the UI of the link panel, and how that panel displays the URL to you – all of that is part of RapidWeaver and works the same on every page.

I suspect that these things haven’t really changed much recently. if anything i think the link panel has gotten a bit simpler in the past few versions of RapidWeaver. but i’m saying this more as a user than as a developer – since that panel is part of RapidWeaver.

and, as an aside, i think that means that the other bug you pinpointed (with the link button in stacks) i should probably just go ahead and release that fix.

Stacks v3.6.7b1 has been was sent out to beta testers a day ago and no one has reported any issues – so I think I’ll just move ahead and roll that fix out to everyone tomorrow. Let me know if it helps out with the linking. :slight_smile:


@dan – just to fill you in… i think some of the confusion arose when “” (or similar) was entered as a URL (without http://) – RW accepts that URL without complaint – but depending on other settings, can generate garbage URLs from this. basically treating what is clearly a domain name, as a path. i think the bug is only that there should maybe be some “validation” done on this URL input-field or some feedback given when the input is likely to cause issues.

1 Like

Kewl. All makes sense. Thanks for the attention and keep up the great work.

  • BH

Ah yes, that makes sense, we’ll get some validation in there in the next build or so. Thanks for the heads-up :+1:


:+1: Thx!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.