Saving styles for project reuse?

I’m finishing up another site built with Cwicly. It seemed to me that getting started was very slow. There is the need to set the font, fluid typography, colors, elements, settings, and so on.

In another thread it was mentioned that @owynter Orrett Wynter uses a style sheet with a lot of these variables set, and I can see the appeal of that. However, that is separate from Cwicly and you might lose some of the benefits of Cwicly by working that way.

Is it possible to export all of the global styles and global classes in one file to import as a helper in starting the next site? Or what about saving a “style” template or something that can be imported on a new site? Thanks.

You now can also upload your global related styles/settings to the design library, so they are available from everywhere on demand.

As far as I know, the mentioned global export isn’t available yet.

4 Likes

Thanks. I’ll check to see what is included in that.

@David, I still use my stylesheets for some utility classes and variables that I use across projects. But have taken to using more Cwicly global classes and the native block styling more now.

It would be nice for a one-click copy/paste or download of ALL styles. What I do now is copy colours, typography, stylesheets and elements. It’s not the worst thing, but that’s multiple operations.

What I have, though, is a boilerplate site set up that I clone for new builds. It has all of the styles and classes and elements that I use, which I then update on each project. Saves a lot of time that way, instead of starting from scratch each time.

2 Likes

Hi @owynter - Thank you for sharing your approach. I agree that a one-click solution would be nice.

I have starter sites for other types of projects but for some reason Cwicly doesn’t work well on localhost for me. I’ve tried Laragon and Local. I don’t have a convenient location online for this purpose only. If I was making sites continuously then I could find something. I may get a Mac at some point and can try Local on that to see if Cwicly works better there.

Hey @David.

Could you share more info on what’s not working on your side?

There were some discussions in the past in regard to local environment issues when using Cwicly and a solution was provided by the team:

I didn’t test with other tools myself, but it was stated that it’s a Gutenberg problem and not specifically Cwicly related.
Hopefully this will improve your situation too.

1 Like

Hi @Marius - I installed the Log HTTP Requests plugin and saw some errors. If I recall correctly they might have been related to curl, but SSL in any event. I added this code snippet:

<?php 
// ONLY USE THIS WHEN LOCAL
$hostname = $_SERVER['SERVER_NAME'];
if (stripos($hostname, "local")) {
	// development
	add_filter( 'https_ssl_verify', '__return_false' );
	add_filter('https_local_ssl_verify', '__return_false');
}

That cut the time down from 2+ minutes going into the Cwicly settings page to about 40 seconds. It is still slow. Not too bad in the editor, but navigating the Cwicly menus, in and out of the Site Editor and the post editor is slow. I don’t have this issue or need this snippet for other Gutenberg plugins that work in the site editor or content editor – my other local sites are normal.

This is a general issue for me using localwp.

There is a workaround which I use for years now, maybe you want to give it a shot and see if it helps.

You also could contact support and provide a live link, so they can see what’s going on in detail on your side.

I think there is nothing wrong in general, as quite a few users work with Cwicly locally without issues, whether it’s Windows or Mac. I also did a test drive on ChromeOS without issues.

@Marius - Thank you for the suggestions.

I used to use Laragon because Local was slow, but the Local team made some changes / released a new version and I’m not having that issue any more, just with Cwicly.

I excluded the LocalSites folder from the antivirus scan / watch (old .net trick) and had the xdebug disabled. I saw this video when troubleshooting, but commenting that out didn’t make a difference.

With the Cwicly plugin activated it takes 20 seconds to open a new page. With it deactivated it takes 2 seconds. On a live site it takes 2 seconds to open a new page or go to the Cwicly settings area.

If it is a problem that other users have also then I’m willing to troubleshoot it more or enable live link, but if it is just me I wouldn’t bother.

Thanks for elaborating @David.

That’s interesting, as on my side this update didn’t change anything.

I’m out of ideas now, as I don’t experience it myself and didn’t read about similar issues here from other users.
I assume this happens without any other plugins activated to exclude any potential conflicts.

Did you try things out on a 2nd device to confirm this behavior?

@Marius - No, I haven’t used my laptop for a long time. I’m considering getting a Mac at some point.

Stepping back a bit, I have the impression that getting started with Cwicly can be intimating. For example, when using the Kadence theme and Kadence blocks, you can start very quickly because there are default styles and templates. Oxygen is kind of in the same boat, you are starting with a blank slate, but there are those design sets that have pretty complete “starter” sites with globals defined. One way typically in WP would be to have child themes, but I have the impression that creating a child theme would not work for providing predesigned templates and settings. I noticed when you install Bricks there are “implicit” templates defined so when you look at the home page or a single post a design has been applied. What have been the thoughts on helping users get a quick start?

  • using the incomparably high-quality designs, provided by Cwicly via Design Library
  • creating a blueprint site, as @owynter suggested here already
  • waiting until the Design Library supports starter sites, templates, etc.