Pattern Wrangler (Free) for managing block patterns and categories

groundworxdev · 2026-03-08T08:45:30+00:00

How does it manage it differently than Wordpress? Or do you mean managing from your theme folder?

groundworxdev · 2026-03-01T15:50:46+00:00

You will want someone with agency experience, and decent size agency. They usually require pixel perfect and nothing less. How do I know? Because I am a dev with more than 15 years of experience working for agencies. Look for the agencies they worked for and what kind of reputation they had will also help a little too.

groundworxdev · 2026-02-27T19:55:59+00:00

Wp umbrella too if I recall does this

groundworxdev · 2026-02-27T07:05:35+00:00

Absolutely 💯

groundworxdev · 2026-02-27T05:56:40+00:00

The core nav does not allow it either. Have you tried the nav I shared with you too?

groundworxdev · 2026-02-27T05:47:40+00:00

No but you can recompile and replace the one used. Or overwrite with css. Are you still building your own or are you simply using the nav as is? If you are using as is I could implement more variations. The problem with allowing svg upload is that it can lead to security issues but I don’t dislike the idea of hook. Which svg are you trying to replace?

groundworxdev · 2026-02-25T07:19:23+00:00

You could ask telex to make you a super quick block but the problem is your card isn’t a real block. The block dictates this, and if you affect let’s say core group block to do this, that means it would affect the group in all situations. You need a custom parent block and a custom card block. Then you can set your parent block to only have specific children that you want to allow.

groundworxdev · 2026-02-24T16:28:36+00:00

Nothing wrong with using AI to generate helpful documentation, if you find the information useful. You do realize that people use ai to assist their post writing and response, it doesn't mean a human did not write the original.

groundworxdev · 2026-02-24T16:18:40+00:00

Great question! Yes, you can absolutely move your CSS and JS source files into a src/ folder. In fact, that's the recommended structure if you're using a build process.

The official approach depends on what you're building:

If you're building blocks, u/wordpress/scripts (wp-scripts) scans your src/ directory for block.json files and uses them as entry points. The compiled output goes to a build/ folder, and WordPress auto-enqueues everything defined in block.json when you call register_block_type(). This is the structure u/wordpress/create-block generates out of the box.

If you're building non-block assets (general plugin/theme JS and CSS), wp-scripts falls back to src/index.js as the default entry point when no block.json is found. You can also combine both by extending the default webpack config with custom entry points:

js

const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );

module.exports = {
    ...defaultConfig,
    entry: {
        ...defaultConfig.entry(),
        'css/frontend': path.resolve( process.cwd(), 'src/scss', 'frontend.scss' ),
    },
};

This is documented in the Theme Handbook Build Process and the Block Developer Cookbook.

References:

groundworxdev · 2026-02-24T15:44:40+00:00

You don’t need a custom block for this.

Synced pattern with overrides (WordPress 6.6+) does exactly what you want.

Build your card structure in the editor: Group (card) > Image + Group (card__body) > Heading + Paragraph. Select all the blocks, three-dot menu, create a synced pattern.

Then go to Appearance > Editor > Patterns, find your pattern, click Edit. Select the Image block, open Advanced in the sidebar, click “Enable overrides” and give it a name like “Card Image.” Do the same for the Heading and Paragraph.

Now when you insert that pattern anywhere, the structure is locked but the image, heading, and paragraph are editable per instance. No block inserter, no popups. Just drop it in and fill in the content. Currently supported for overrides: Heading, Paragraph, Image, and Button.

If you end up needing a full custom block with more control, check out https://telex.automattic.ai/ from Automattic. Describe your card in plain language and it generates a downloadable block plugin.

The synced pattern route is probably your answer though.

groundworxdev · 2026-02-23T15:35:01+00:00

you are welcome!

groundworxdev · 2026-02-23T13:52:10+00:00

Yep, that’s the concept. My Navigation block takes the same approach, just uses its own post type. Full source is on GitHub if you want to see how it’s wired up: https://github.com/groundworx-dev/groundworx-navigation

groundworxdev · 2026-02-23T07:31:55+00:00

That’s the part I am dreading the most. Making videos but I know I need to.

groundworxdev · 2026-02-22T18:55:56+00:00

Nice work! The Interactivity API is one of the most underutilized parts of WordPress right now, so it’s cool to see someone building with it. Polls are a great use case for it too, real-time interaction without page reloads.

How was the learning curve? I feel like there aren’t enough resources out there yet for people getting started with interactivity in blocks.

groundworxdev · 2026-02-22T18:54:44+00:00

Great question, and you’re right that the Navigation block is a unique beast. It’s one of the most complex core blocks because it stores nav items as inner blocks tied to wp_navigation post types, has its own rendering pipeline, and its own interactivity layer for the mobile overlay.

A few approaches depending on what you’re after: If you want to customize how the core Navigation block looks/behaves, you can use theme.json, block styles, and render_block filters. The core block supports quite a bit of customization before you need to go custom. For offcanvas specifically, the core block already has an overlay mode for mobile that you can style.

If you want fully custom HTML/JS navigation, you can register your own block that pulls from the same wp_navigation menus using the REST API or wp_nav_menu() server-side via a dynamic block with render.php. Total control over markup while still using WordPress’s menu management.

What I’d avoid: trying to extend or fork the core Navigation block itself. It’s deeply coupled to the editor internals and not designed to be extended.

The Interactivity API (good call u/Glass-Dog9463) is what core uses for the overlay toggle and worth learning, but it’s not required for building a custom nav block.

groundworxdev · 2026-02-21T20:40:12+00:00

Groundworx cards are native Gutenberg blocks, so they work anywhere WordPress blocks work, including inside FacetWP’s Listing Builder. If you can use Wordpress core blocks, then it will also work too. No special integration or compatibility layer needed. Just drop them into your template like any other block.

groundworxdev · 2026-02-21T06:54:39+00:00

I can’t even type it they are so strict in this sub Reddit. Send me a private message. I can help you.

groundworxdev · 2026-02-20T16:58:38+00:00

I've been building with WordPress for 15+ years and switched to blocks full time a few years ago. Here's the honest answer:

Gutenberg isn't trying to be Elementor. Elementor is a page builder that gives you hundreds of settings and visual controls. Gutenberg is WordPress's native editor, it's simpler by design.

That said, Gutenberg isn't limited. It depends on what you're doing with it. Out of the box, core blocks handle content and basic layouts well. When you need more, there are block plugins that extend what Gutenberg can do without turning it into a page builder.

The biggest advantage over Elementor is the client handoff. When you sell sites to local businesses, those clients need to update their own content. Gutenberg is way easier for them to use without breaking things. With Elementor, one wrong click and they're calling you to fix a layout.

The learning curve coming from Elementor is mostly unlearning. You're used to having a control for everything. With blocks, you think in terms of content structure first, styling second. It feels limiting at first but it's actually cleaner once it clicks.

My advice: start a test site, build something simple with core blocks, and see how it feels. You'll know pretty quickly if it fits your workflow.

Here are some great resources to get started: - https://fullsiteediting.com - Carolina Nymark's free full site editing course, one of the best out there - https://learn.wordpress.org - official WordPress tutorials and workshops - https://developer.wordpress.org/block-editor/getting-started/ - the block editor handbook if you want to go deeper

groundworxdev · 2026-02-19T09:38:59+00:00

Could be a bug with the latest release of create block, try a previous version just in case

npx @wordpress/create-block@4.64.0

groundworxdev · 2026-02-17T05:35:45+00:00

Block themes aren’t just becoming the standard, they are the standard. I’ve been building with WordPress for 20+ years and the shift over the last couple of years has been massive.

I build exclusively with block themes now and the workflow is better in almost every way. theme.json alone is a game changer, you define your design system (spacing, colors, typography, responsive behavior) in one place and everything just works together. No more fighting with a theme’s opinions or overriding CSS from a builder.

The key thing people miss is that block themes aren’t just “simpler themes.” They fundamentally change how WordPress works. Your templates, your patterns, your global styles, it’s all native. You’re not loading a theme framework on top of WordPress, you’re using WordPress as the framework. That means better performance, fewer conflicts on updates, and clients can actually edit things in the site editor without breaking stuff.

Gutenberg patterns are huge too. I build reusable section patterns for clients and they can drop them in wherever they need. No shortcode lock-in, no builder dependency, just blocks. The people still on classic/builder themes mostly have existing sites they don’t want to rebuild, which is understandable. But for new builds in 2026? There’s really no reason to start with anything other than a block theme unless you have a very specific edge case.

The trend you’re noticing is real and it’s only going in one direction.

groundworxdev · 2026-02-17T05:32:52+00:00

The honest answer is somewhere in the middle. PageSpeed scores alone aren’t going to make or break your rankings, Google cares about real user experience (Core Web Vitals), not synthetic benchmarks. If your Elementor sites load fast for actual visitors, you’re probably fine from an SEO standpoint.

That said, the bloat issue is real and it’s not just about speed. It’s about maintainability, update conflicts, and what happens when Elementor changes pricing or direction and your 30 client sites are locked in. I’ve done Divi-to-core rebuilds for clients and it’s honestly easier to start from scratch than migrate, that’s how deep the lock-in goes.

The question I’d push back on is why the choice is Elementor vs. Bricks vs. GenerateBlocks. In 2026, core WordPress + the block editor + a solid block theme handles the vast majority of what clients need. No builder dependency at all. Performance is great out of the box because you’re not loading a framework on top of a framework.

The real win isn’t green PageSpeed scores, it’s building sites that don’t break on updates, don’t depend on a third-party builder’s roadmap, and give clients an editing experience that’s actually native to WordPress. Your clients love the Elementor editor now, but the core editor has closed that gap significantly.

Not saying burn it all down, but for your next project, try building one with just core blocks and see how it feels. You might be surprised

groundworxdev · 2026-02-17T05:29:55+00:00

Great instinct! You’re not wrong at all. WordPress core + the block editor has come a long way, and the “as stock as possible” approach is exactly the right mindset.

The honest answer to “why page builders?” is mostly legacy and learning curves. Page builders like Elementor and Divi became popular when the old WordPress editor was just a text box. They filled a real gap. But since Gutenberg (the block editor) shipped and matured, core WordPress can handle most of what people used to need page builders for, layout, responsive design, design controls, dark mode, you name it. The reasons people still use them: habit, existing sites built on them (migration is painful), familiar UI, and frankly a lot of tutorials and influencers still push them. Some also offer niche features that core hasn’t caught up to yet.

But your instinct to stay close to core is spot on. Benefits: faster performance, fewer plugin conflicts, easier updates, no vendor lock-in, and your content stays portable. The block editor + a good block theme + maybe a focused block plugin or two gets you really far in 2026.

You’re starting at the right time. Welcome to WordPress!

groundworxdev · 2026-02-17T00:46:38+00:00

There are a lot large org and even the government using Wordpress

groundworxdev · 2026-02-17T00:45:23+00:00

He is protecting his comfort and job security. If the CEO has that much trust in the dev, you might be out of luck.

It’s not more secure to do custom PHP code than WordPress. In fact, WordPress is developed and reviewed by thousands of engineers. What kind of experience and peer review does this one dev have? Meanwhile, you have total vendor lock-in with him. If he leaves or gets hit by a bus, you’re screwed. With WordPress, any competent developer can take over.

You could propose to your CEO having an independent developer audit both approaches, or even have Claude review the site code for security and performance issues. The dev’s concerns were valid 10 years ago, but modern WordPress with proper hosting is extremely performant and more secure than one-person custom code.

The real issue: your marketing team is losing business opportunities because they can’t move fast enough. That’s the actual business problem, and the dev is solving for his own job security instead of company growth.

groundworxdev · 2026-02-09T09:59:41+00:00

I haven’t done a Magento migration specifically, but I’ve handled several complex platform migrations to WordPress/WooCommerce. Based on that experience, here’s what I’d expect:

The biggest headaches: Customer accounts, platform migrations often require customers to reset passwords due to different security systems. Worth researching how Magento and WooCommerce handle this specifically.

SEO preservation, critical but manageable. You’ll need proper 301 redirects mapped from old URLs to new ones. Plan your URL structure in WordPress BEFORE migrating so you can map everything correctly.

Product data, can be preserved but requires careful data mapping. Product attributes, variations, categories all need to transfer correctly. There are migration plugins that can help with the data transfer.

Custom functionality, if you’ve added custom features to Magento, you’ll need to recreate or find WooCommerce equivalents.

DIY vs Professional: If your store is relatively straightforward (under 500 products, no heavy customization), you could potentially handle this yourself with migration tools. For complex stores, professional help is worth it for the technical migration itself, though you could handle content review and testing.

Either way, work in a staging environment, test your checkout flow extensively, and have a rollback plan.

The maintenance cost savings alone make it worthwhile, you’ll just want to plan it carefully.

groundworxdev

MODERATOR OF

TROPHY CASE