Dev Diary 96 - Import Classic Projects into Elements

Yes good move … removes a lot of friction for a lot of people !!

@barchard is currently working on GridIron for Elements fyi

Thank you. Also, regarding Sitelok, we are not married to that system.. we just need an integrated membership capability.

Thanks again,
Howard

What’s stoping me you ask?, Elements and it’s CMS will need to mature quite a bit before I’d change. It’s still in it infancy with numerous issues that I have read about.

You can use Sitelok already - here’s a link to another user’s experience Subscriptions - #2 by Heroic_Nonsense

Also, at the bottom of this page there’s a custom component for Sitelok with Elements Buy Membership Software and Systems Online UK | Vibralogix

Useful as is if you ask me this will save me re jigging SEO on a site I am looking at rebuilding. Next week and was dreading rebuilding the folder structure an page layouts

That’s exactly what I meant in my post. Thank you, Dan. This will certainly help a lot of people and make starting a project in Elements easier.

I think you shouldn’t try to recreate the entire stack; perhaps it would be possible to import text. Simply create it as text elements. Then you don’t have to do much drag and drop, and the text is already on the page where it belongs.

This import function is already GREAT.

This looks good - helping a lot already. Importing content is of course very important, when having more than 20 pages. Small sites I can do manually, but a large one? I don’t have the time for that.

Also important - and you started this way back - is a Stacks-converter.

@dan that would be extremely helpfull to rebuild my website Https://weaverpixel.com. It is still made with Classic and Foundry 3.

I could keep all my SEO stuff, my site structure and all the resources and can start rebuilding page by page. Sounds great :clap:

Good news, @barchard is working on GridIron for Elements… and @vibralogix has already built SiteLok for Elements :tada:

We thought this might come up!

If we did add support for importing content, we have some choices to make.

Here’s my current thinking on it all. Please remember this is not a guarantee of adding such features, we’re just discussing it at this point. We need to balance the work required with fixing issues and adding new features in Elements:

HTML and Markdown Pages would be simple to import.

Styled Text Pages: We could import Styled Text pages and place the content into a Text Component, might get tricky with some of the styling. But we could certainly extract the text and images, and place them into the page using Text and Image Components.

Blog Pages: We could convert blog entries into Markdown files for use in the Elements CMS.

I’m not sure it’s worth spending the time to convert Photo Galleries, and Contact Forms, as they are VERY fast to re-create in Elements.

Stacks Pages:. While it’s not feasible to convert all stacks like for like… We can easily extract text and images. As with the Styled text page, we could extract the text and images and place them into the relevant components.

We do have the possibility to convert a specific stack into a specific Element. So for example if you were using a Foundation Image stack we could map it to the Elements Image Component, and while it wouldn’t retain the styling, it would use the image and be ready to work with in the page.

Just remember, whatever we imported, it wouldn’t be designed and in the same layout as in Classic. You’d still need to do the design work. This feature is essentially a shortcut for dumping content into the pages, it really just saves the back and forth of pasting content.

So, what do you think, is this better than copy and pasting text?

Is it worth investing the time for us to support all of this? What’s most important to you?

Let us know!

Hey Dan,

Yes PLEASE!! This feature would save me a world of grief when recreating my Classic websites on Elements. I’ve been procrastinating every since moving onto Elements.

Thanks,

Namir

If you look at weaverspace today the first twelve posts are about problems except for one “selling” a new stack. STACKS6 beta is full of problems and missing bits quote Joe workman which they are working on. Also there are lots of problems with every software thats why they do updates. If I read about the problems of everything I wouldn’t even get in my car to drive. The proof is in the eating and rather than read about it download the free version and see what’s its like rather than reading about it.

SEO is “dying” and by that I mean AI search is growing, So your old SEO methods need updating going forward.

Dan, I think your assessment of the options is spot on.

With regard to stacks plugin pages, in addition to text and images, it would be helpful to preserve the stack hierarchy, if only to provide a bit of context when re-designing around the retrieved content. Having the skeleton of the original page’s design would be helpful.

As I mentioned previously, where you can’t convert a stack to an Elements component, replace it if you can, with a placeholder component that has a drop-zone so that they can be nested and follow the original stack nesting hierarchy. Grabbing a meaningful name from the stack for the component name would be helpful too.

I think this is where having the component hierarchy view in Elements will pay dividends. In a wysiwyg-only editor such a structure for a complex page might produce a confusing picture (literally!), but the component hierarchy view will faithfully reflect the stack structure of the original page. Re-design work can then focus initially on the component hierarchy view (substituting placeholders for Elements components or templates, re-configuring/simplifying, etc) before moving to the wysiwyg view for layout and styling.

Importing and reproducing the page structure of the site and the structure of each page in the site has a pleasing symmetry about it…

The only really unfortunate issue I see with the proposed solution is the very high risk of recreating bloated code. So many things are for more efficient in Tailwind and Elements. Trying to retain the hierarchy, which I understand and appreciate, risks bringing over a lot of divs that aren’t necessary in modern code like Tailwind.

If you’d build something that:

  • extracts all the text and images, and perhaps some of the layout and CSS generated by the stacks in the project, then convert that output to Elements specific markup and then import that - that would be a BIG time saver.

I understand that not all output can be captured exactly like RapidWeaver+Stacks would render it, and that some stacks offer very specific functionality that you can;t just copy (for technical and legal reasons I imagine). But text, basic markup and images to pop over on import would be BIG.

Cheers,
Erwin

Importing Classic projects would make transitioning to all an Elements workflow so much easier. Bringing in content would be a big plus.

I don’t know if this is even possible - being able to upload the converted Elements project in place of the old Classic project with the extraneous files and folders removed. IE Elementify a Classic project, make any required adjustments etc, then hit publish and bingo the new project replaces the old one.

I think, fundamentally, this could become a useful tool. The problem is, at least for me, it just comes too late.

This tool really should have been available from the beginning. If I’m honest, when I look at it more closely, it doesn’t make much sense for me now—because over time so many things change, new information comes up, and the overall zeitgeist shifts. For me, it was better to just build a completely new site from scratch.

Another challenge is that using a tool like this means I end up working across two different systems…

From my perspective, you should invest more time and energy in helpful video tutorials—similar to what you did with the Bento video. These kinds of videos would be far more useful as guidance for building sites with Elements.

Besides that, when starting a “new construction site,” I do have concerns that fixing the especially annoying bugs (and there are still quite a few) might end up being pushed far into the future…

Right now, with both the CMS and this tool, it just feels like there are too many “work in progress” projects at once. But given how much attention and enthusiasm this tool is getting, I guess we’ll just have to be patient—bug fixes and CMS improvements may take a bit longer.