Opinions on RW Features not required in Stacks App

I wanted to start a thread about what RW features we don’t need in Stacks App, in the hope that this may be useful for Isaiah.

@isaiah Don’t feel any pressure to comment at this stage.

Rather that turn this into a I would like this feature thread, list what RW features you DON’T want and explain why.

My list would be:

  1. No FTP facility. The follow on feature is there would only need to be a requirement for a Publish to a folder function. This has been a major source of issue for RW users since I started using it, and I abandoned the inbuilt FTP early on, after many issues. Significantly, I never had an issue issue since using an FTP App. Supporting the RW FTP has been a support sink hole for RM, judging by the many FTP problems reported on the old deleted forums. FTP Apps are not expensive and you can even use your cPanel to upload for free. You can setup a folder as your published folder that will be auto uploaded to your site by most FTP apps.

  2. No local Preview. The new Preview button could preview directly into your browser of choice, such as Safari, that will give the latest Inspector and Responsive Design Mode preview tools.

  3. Abandon the joke GDPR facility. Users who want to implement a proper GDPR solution can use the various stacks available that cover GDPR.

  4. Abandon the Unsplash feature. Unsplash has changed and could disappear at any moment or the free licensing could change. I’m sure there are far better ways to load 300dpi unoptimised and oversized remote images.

  5. Abandon the scattergun approach to locating settings, code, SEO, etc. all over the place. The Blocs solution is ideal and most current Apps do it that way.

  6. Resources. A dreadful idea from the start. Why not create a fixed structure so that a folder called resources is a sub folder of the main publish directory.

  7. Forget all Page Types except Stacks and maybe Offsite Page. A navigation manager like the Wordpress facility would be a far better way to deal with navigation and could include the “Offsite Page” URL. The current navigation restrictions that exist in RW are one of its worst features IMHO.

  8. Abandon the resources, snippets, themes managers. These can be better elected from simple drop down lists. We can use Finder for everything.

  9. Abandon the Page List. No need to see the pages if they are implemeted in a way similar to most other web creation apps such as Blocs.

  10. Abandon the Master Style. Replace with a “Use XX theme for all pages” setting and add an individual page option to chose a different theme, if this is really required.

  11. Abandon the feature that doesn’t send the RW Crash reports to the plugin developers. Oh wait, that won’t apply anymore.



  1. The Htaccess eitor. This is ticking time bomb IMHO that has the potential to end in a lot of tears. It is very much a Pro level feature, yet presented to users who don’t want the learn how to use an FTP app.
1 Like

I do use this feature for Mobile & Tablet, for small text adjustments.
I had always thought it would be great to have an inspector and responsive design tools baked into the preview.

1 Like

These tools are baked into all main browsers.

In RW8, you can’t easily make small changes to the screen width. For example if you need to check resopnsive behaviour at 599, 600 and 601px, the RW preview is not good at allowing this. It is far easier in Safari. IMHO this is the single reason that many RW sites are not debugged well enough on mobile.

RW preview does have Inspector but it is years out of date from what I can tell. By using Safari, you always have the latest Inspector.

I do rely on the publishing system of RW for all my sites. It makes my life easier. So that is one feature I would not like to live without.


Safari is a good free way to preview - I use Solis for live previewing and have found it to be invaluable for fine-tuning different viewports at the same time. It’s less than £30 and has a free trial… https://solisapp.com


Thé one thing I’d did like about RW preview was the option to set it as custon and drag the preview window width to see where a design would « responsively » fall over and not look good. Was great for spotting things that were out with the presets.

Agree publishing is best left out of it, there are many other/better tools for this.

That’s exactly what you can do in Safari Responsive Design Mode. Select this in Safari and RW will Publish to Safari in the screen width you have setup. It doesn’t take any longer to do this than use the RW Preview. Will also display webP images.

Solis is excellent too and does an amazing multiple smooth scroll that RW8 doesn’t do.

My point being however, is that Preview would fall into the “maybe something to consider further down the road” feature.

Thanks, I’ll have a play and see. I do look at the preview speed of the likes of Blocs, compared to RW, with envy.

No FTP facility.

In-app publishing is a very important feature. It’s been horrendously unreliable in RW, though. But I’m sure it could be properly implemented in Stacks app. However, I would be perfectly fine with delaying its appearance in Stacks until version 6.

What I am willing to never ever see again is the RW’s Resources. Unless this feature is completely overhauled in Stacks app.


Not including publishing in the first iteration of Stacks would be a disaster. I completely understand why some folks don’t like it. I get it. But for many many folks the requirement to now buy another app, and learn that app, would be a real pain. Add to that the indignity of it being a wasted purchase if publishing appeared in Stacks 5 about 6-12 months later. Ugh.

Stacks 5 would then lose a massive amount of occasional users (who make up the majority of RW) at the very beginning with their takeaway being; “Stacks 5 is only for advanced users.”


It’s a valid point, but I’m willing to bet that most of potential Stacks app users already have and use some sort of FTP app.

@Webdeersign Yes, a lot of your suggestions for “non inclusion” are good ones. Resources seems to get people in more trouble than it helps. Unsplash is a very bad idea: encourages folks to add non-optimized large images into their project. And so on.

… I suppose I might be open to another way of displaying things rather than the Page List. But I have to admit I’m fond of it and I’m not sure it’s a problem for anyone. Obviously if for some reason it’s a huge issue for Isaiah to implement then that’s different, but all things being equal the page list approach seems to work very nicely.

Sure, put up your $5,000. It would be easy money for me. :)

If Isaiah only wants advanced users then taking out internal publishing will do the trick. But his audience, as a result, will be much smaller. If he’s cool living with that compromise then I’m fine with it too.

He’d also need to really calibrate the selling price.His product would need to be cheaper so folks had the money to also buy an app like Transmit. I love me Transmit … but … And does he really want the burden (which would surely happen) to support folks trying to learn to use Transmit, Cyberduck, or other FTP products? It’s easy to say folks should go to those products’ developers to get help but it won’t always pan out that way.


Abandon the joke GDPR facility.

No question about that.

Abandon the Unsplash feature.

The usefulness of this addition to RW always puzzled me.

Abandon the Page List.

I don’t see any harm here.

Abandon the Master Style.

Master Style? What’s that? (joke)…

BTW, I have zero idea whether implementiing publishing is easy/moderate/difficult/extremely difficut for Isaiah to do. But if it is very difficult then at least communicating proactively will help a lot. Something like, “Sorry folks, Stacks5.app Version 1, does not include publishing. It will … hopefully in 9 months. If you don’t want to take on publishing yourself via an FTP app then don’t buy Stacks5 now: continue to use RW 8.9. We’ll let you know when publishing has been added.”

There is another website builder, which is also able to live without FTP publish functionality.
And better don’t include it than having it not working.

Maybe this is the future direction. RW for dummies, Stacks5 for professionals.

1 Like

And… that’s what everyone here has always wanted for years.

RM uses a weird interpretation of Publishing. It can mean compiling and saving to a local folder and it can also mean compiling and then FTPing the compiled code to a server.

When I mentioned Publish, I meant compile to a local folder.

I anticipate the FTP issue will be hard sell for the Weavers, but if there is a chance of getting hold of Stacks App without an FTP function, that woud be a very good thing. I would imagine that adding a robust FTP would add considerable time to the release date.

If you look at other web creation software, FTP is very rare.

There are other creative ways of providing an FTP function such as licensing some code, etc…

@Jannis Yes, but I think you are talking about Blocs. From what I can discern (based on their extras you can buy and other things) it has substantially fewer users than RW However, if Isaiah wants to make Stacks5 for professionals that’s a perfectly legit way to move forward. Only he knows if that’s a financially feasible route to take. (And if he doesn’t know then he better figure that out quick.) But it’s definitely an option, maybe even a good one, but it has many consequences … some of which are likely to be unknown at this point.

@Webdeersign Sure … there are other ways to provide an FTP function. But amongst the big boys/girls it means doing your designing on the web itself (or via MAMP/Local): WordPress, Wix, Squarespace, etc.

… at any rate if Isaiah does not include some way to easily publish then there are a number of consequences that only he can weigh.

No new app comes out perfect in its first version. No new app comes out with the full set of features, either. We would have to accept that fact and live with it.

1 Like