85 Pages Down. 1,300+ to Go. Here's what I've learned about Elements

I’ve been rebuilding our 1,300+ page website in Elements, and the first 85 pages are now complete. Working on a project of this size has been a great way to experience the framework beyond a typical brochure site, and overall I’ve been extremely impressed. I’m convinced RapidWeaver Elements is the right choice for us moving forward.

It’s fast, stable, intuitive, and a pleasure to work with. One feature I’ve particularly enjoyed is the ability to move components seamlessly between the page layout pane and the WYSIWYG editor. It feels incredibly natural and has made building complex pages significantly faster.

There is still a tremendous amount of work ahead—RW CMS integration, SEO and accessibility reviews, content refinement, and plenty of cleanup—but I needed to get our new Resource Center, updated pricing and navigation live so customers could begin benefiting from the new content.

Elements has been fast, stable, intuitive, and genuinely enjoyable to rebuild the site with. It’s obvious a tremendous amount of thought has gone into the framework, and it’s been a pleasure to work with.

As with any large project, real-world use uncovers opportunities that smaller websites never expose. Here are a few things I’d love to see in future releases.

Image Alt Text

This one surprised me the most.

The standard Image component doesn’t currently expose an Alt Text field. With accessibility, SEO, and AI all relying on meaningful image descriptions, having direct control over the alt attribute feels essential.

As a experimental workaround, I added an HTML component and was able to recreate the image while adding my own alt attribute. It blended in seamlessly with the rest of the page, but I’d still love to see native Alt Text support added to the standard Image component.

If you’re curious, the California image on this page is the HTML version.

Render Custom HTML in the Editor

Some of our pages include embedded forms and custom HTML.

Being able to render Custom HTML components directly in the editor instead of displaying an empty placeholder would make page layout and visual editing much easier.

Canonical URL Improvements

Two small improvements would make a big difference:

  • Automatically generate canonical URLs by default.
  • Display the end of long canonical URLs in the inspector rather than only the beginning. When working with deeply nested pages, it’s much easier to identify the page by the end of the URL than the beginning. The full url to this page is: https:// oneeleven (dot) surf /resource-center/privacy/laws-and-regulations/connecticut-data-privacy-act/

Better Link Visibility

When reviewing a page, it would be helpful if linked elements displayed whether they open in the same window or a new window without having to open the Link dialog. On larger sites, this would make auditing links much faster.

Search in the Elements Store

As the Elements ecosystem continues to grow, a search feature in the Elements Store would make finding components much quicker.

Thanks to everyone at Realmac for all the years you’ve invested in building and supporting RapidWeaver. It’s been a big part of my business since 2011, and Elements feels like the beginning of another exciting chapter. Keep up the great work—I can’t wait to see what’s next.

When I taught - had some catch phrases…

When in doubt - right click it out…

Make elements could have better, faster access - than going to the inspector for links etc..

Thank you sharing this info and your experience. May I ask how the project is running? Meaning, how is it handling the number of pages you have been throwing at it, fast, slow, link manager speed, screen draw speed, sidebar updating, etc.

The project is running great. The existing site was originally built in RapidWeaver 8 and, because of its size, is split across multiple project files that publish directly into their respective nested folders.

The plan isn’t to rebuild all 1,300+ pages manually in Elements. We’ll be integrating RW CMS to dynamically generate the rest of the website. With the exception of the Resource Center, the first 85 pages represent the primary hub of the website.

Performance has been amazingly fast. Aside from the normal learning curve of moving from RapidWeaver 8 to Elements (which I’ll probably write about in a future post), I really have zero complaints about the application itself.

For comparison, the current Elements project is only 79 MB, while the equivalent RapidWeaver 8 project is 411 MB—and the Elements project actually includes an additional 15 pages we’ve added to the site’s main hub.

Part of that reduction comes from the excellent MultiThemes Parallax component, which allows banner images to be warehoused instead of embedded directly in the project. To be fair, the RapidWeaver 8 project is also warehousing its images, so it’s not the only reason for the size difference.

A shout-out to @MultiThemes for creating such a fantastic component. It has integrated seamlessly into my workflow, and it’s become one of those tools I don’t want to build without.

Most of the items I mentioned are simply feature requests that came from building our own website.

One feature I was especially happy to see was the click-through page link. I requested something similar years ago, and it’s great to see it in Elements. Being able to jump directly from the project to the live page will make reviewing published websites while working in Elements much easier.

We’re planning to migrate around 50 client websites to Elements. The only thing holding us back from moving beyond the homepage templates is native Image Alt Text support. For us, that’s a business requirement rather than a preference. Alt text is included in our proposals and contracts, and it’s an essential part of both WCAG accessibility and SEO. Once that’s in place, we’ll be able to move forward with confidence.

They are fair comments. Thank you for documenting them. My project is around 600 pages ranging from 900-3500 words. The vast majority fall into the 900-1500 word range. Either one image per page or a link to the corresponding Youtube video. So other than the potential go 600 warehoused images, they will all eventually be replaced by YouTube links.

Agreed. I am surprised this is not in there. Is this not it? Image | RapidWeaver Elements Docs

What am I missing here, as the existing image component does have support for alt text?

Is this something different?

I don’t see where it’s at.

That appears to be because you are using a custom image. If you switched to the resource-based image, you would see the alt text field. Strange that they did not expose it for a warehoused image.

Actually, strangely, I just noticed that in the v3 BETA there is an ALT field for both the CUSTOM and CMS options, but there is no longer one for the RESOURCE option; very strange.

Regardless if its Resource or Custom, no alt tag field appears.

I think I might have figured out why I’m seeing it. I have the Elements core dev pack installed and the version in there must have an Alt field in the image, but not the built-in one. Which seems very weird, as they are supposed to be the same.

I see the same as Robin and don’t have the core pack.

I also see an ALT field if I have the image selected in Resources and click on the little i button at top right of screen.

Which Elements version are you using? @jbyfield

2.2.10. Have been slack and let my sub expire. There was some discussion a while a go as to what box is Alt text vs caption -

The screenshot I showed above was for version 2.4.4. But strangely, if I remove the core pack the alt tag disappears entirely.

It is not present in the v3 BETA either.

https://forums.realmacsoftware.com/t/missing-alt-text-field/56488

Went missing last month according to that thread.

I tried testing this by adding the alt text, for an image resource, in the resource inspector, but when I used the image in an image component and inspected it in the browser, there was no sign of the alt text, so I’m not convinced it is working.

I think I’ll continue to keep the core pack installed and use it, as it gives you the field in the inspector, and even if the pack is removed, the text is still there when reenabled.

I’m sure I won’t be able to continue doing this forever, as sooner or later they will update the core pack and get rid of the alt text field.

Alt and title tags are SEO and accessibility 101. I think a bug crept in. I have to believe that will get fixed.

For the images from the resources, the alt-text is defined here:

As @Fuellemann mentioned, the alt tags now go in the media inspector, however there is a bug where they are not being output correctly.

We’re working on a fix and will ship this in an update next week!