Increasingly the web is moving away from jQuery. The library that came to be a part of the majority of the entire internet, is now seen largely as a relic. And that’s because faster methods for doing most of the same things have been developed. Plain JS, or vanilla JS, isn’t so plain anymore. Nearly any of the main functions we might really use in jQuery can be done without jQuery and without any library.

Many of the apps and major sites that you use everyday now use either React, Vue or other Javascript frameworks. Yet WordPress still loads jQuery by default, and unfortunately it will take years to remake all the themes and plugins that rely heavily on it.

Starting in WP 5.x with the new Gutenberg editor, came the emergence of the shift toward modern JS in WordPress. React is now baked into WP and available through a global wp.element. Both React and React-Dom are automatically available in any WP site. Developers just need to load them, and learn some of the unique aspects of using React inside a WP environment.

Removing jQuery from your front-end is actually easy to do. The problem is on most WP sites it will likely break your theme, and most if not all of your plugins. Other than this, you’ll be fine. Removing jQuery at this point, probably isn’t practical for most sites. But if you’re a developer working on a new site, if you have the luxury of building a custom theme, you just might be able to entirely eliminate reliance on jQuery and build your front-end features from either straight JS or a modern JS framework such as React or Vue.

// remove from front end only 
if ( !is_admin() ) wp_deregister_script('jquery');

// remove everywhere (not recommended because it may break the WP Admin
wp_deregister_script('jquery');

Credit to the thread below for the code snippet:

Font Awesome is pretty awesome, but it’s also pretty heavy. We could call it Font Heavy, but then it might not be quite as popular. The problem with loading a lot of stuff you don’t need should always be obvious. This is probably one of the simplest ways to approach optimization, is just ask yourself how much of what you use do you actually need? With Font Awesome thankfully they have a way of giving us their great fonts without loading the entire library. We can load only the icons we need by downloading their SVG’s.

I highly recommend doing this despite the work involved because it can make a real difference in speed. You’re eliminating a large JS library, and replacing it with lightning fast loading SVG’s. Win/win.

The allure of being able to build without coding is strong. Even among coders. After all so much of programming involves repetition, and we often think wouldn’t it be better if we could have this done for us, automatically. This thought process happens to me a lot. But in reality I find when we try to automate too much, we end up with much more complex problems. For example wouldn’t it be better to rely on JetSmartFilters plugin to handle the complex task of filtering records? Building filters can seem daunting even to seasoned developers. It’s also a full stack adventure, you need to make the interface, you need JS to do AJAX calls, and then you need to query and return results using PHP. And if you don’t handle the CSS well, what’s the point?

This leads us down that rabbit hole of relying on OPC (Other People’s Code). And in a different way than relying on WordPress. After all WP, probably doesn’t get enough credit for this, but it’s very light-weight and fast out of the box. It’s all the stuff (themes and plugins) that get’s layered over top that can make it both slow, and super complex to work with. Ironically doing simple things in a lot of WP sites ends up being more complicated than building a Node.js React-powered modern app. There are just many moving parts, and there is so much code layered on top of other code. It’s that challenge of trying to make modular pieces that fit together, which is both immensely powerful in WP, but can also be it’s achilles heel.

We started with Elementor. Then Elementor Pro. Then we discovered JetEngine. Then we tried JetSmartFilters. The dream of being able to snap your fingers and viola a powerful data-driven site emerges… the dream seemed to be real. Except it wasn’t. We used JetEngine to power our portfolio here on this site, and then to power our listing of services and WP plugins, and the site become the slowest site to ever exist. We looked at how to resolve this. Bigger server, check. We’re on AWS, we upgraded our server a couple of times. Roll in the optimization plugins. None of them really work, optimization is too specific and nuanced of an area for a plugin to suddenly fix everything. Especially if your site is just wacked. And that’s the conclusion we reached, our site was just loading to much junk OPC. Other people’s code, it was saving us time in coding, but it was now costing us time in fixing and debugging and optimization. And also, an important point here, while we were distracted by the worries over our slow site, and any users who dared to load it were haunted by it’s painfully slow churning… during that time, we were not focused on marketing and improving the UX and doing the dozens of other important things we needed to do to grow our agency.

So we dumped JetEngine. We decided to go back to what is simple and effective when we want custom post type content. That is a CPT with ACF fields, and fully custom templates to render the content. The next step is to tear out Elementor, which means we have to replace the Elementor forms… and we’re not sure what we want to use in place. We might just build them ourselves! After all, how much OPC is in Gravity Forms or other options? We could use ACF front-end forms, but it’s massive JS load provides poor options for creating a good user experience.

Bottom-line is we’re done cutting corners and compromising. WP remains our go to for a building framework, even as we start to work a lot more with NodeJS/React. But we’re questioning everything now. We’re question WooCommerce which feels bloated, slows down sites and requires a dozen extensions just to make a decent experience for the user.

At the end of the day, web development and application development is about valuing the user experience. It’s about building the best possible experience for real living people that need to gain value from what you create. So why settle? Why are we settling for inferior load times, inferior UX’s, inferior user flows, all because Other People’s Code promises to slam features into place quickly? I don’t have a good answer to this question, so for me that is the answer.

Earlier this year we registered a real estate domain. It turned out to be a winner! We got an offer out of the blue for $750 from GoDaddy a couple of weeks ago. I was surprised. I even Googled “is domain sale offers from godaddy a scam”? I found the person who emailed me (claiming to be a broker with GoDaddy). Found him on LinkedIn and realized okay, this is the real deal. I countered with an offer of $950, and the buyer went ahead with the sale.

Unlike every single other encounter I’ve had with GoDaddy, this one went smoothly. I still stand by what I often say about GoDaddy, that they are the worst host to ever exist… which is based on my years as a developer watching GoDaddy hosted sites crawl along the ground on their knees. But what’s always been the most frustrating to me, was trying to use their admin tools. Which they built themselves, presumably from spare parts they scrounged at the landfill. Yes there is no love lost for the sleazy marketing junk sellers GoDaddy. But it is nice to get some payback for the years of pain and suffering. I guarantee you like many developers, I’ve lost plenty of time and money dealing with this company. So $950 USD is a bit of compensation that I do appreciate.

By the way are you hosting your site on GoDaddy? Are you brain damaged? It’s okay if you are, no judgement, but in case you haven’t heard… GoDaddy is a marketing company posing as a host, and their by far the slowest least reliable host to ever exist. You’d be better off hosting your site on your laptop.

There are a lot of great widgets and other features available when you get Elementor Pro. Nothing in our view compares to the power of dynamic tags. In this post we’ll give you a solid introduction to using Elementor Pro’s dynamic features.

What is a dynamic tag? It’s a way of sending data into Elementor widgets from stored fields. It allows us for example on this site, to use ACF Pro (Advanced Custom Fields) to setup field groups that provide an image field for our posts and pages that we call the “Header Image”. Then when we create a new post or page, we add an image for that one specific post. Our page and post single templates that use that image as the background for the header area. This is important because if we used the same image on every page and post, visitors would be bored out of their trees and leave us without spending a penny. Moral of the story: dynamic features make stuff better, and help us engage visitors.

We’re in the code management business. Our customers are agencies that rely on us to fix complex coding problems and code-related issues. So why are we sold on the “No Code Movement”? Because we don’t love code problems, code conflicts, bugs, security issues and upgrade issues and everything else that can go wrong. We deal with, grapple with those issues and have a system for solving problems involving code. That doesn’t mean we want to invite those issues to occur on either our own projects or yours.

Websites obviously are made of code. This hasn’t changed, this will never change unless in some far off future there is some form of internet that doesn’t use current technologies at all. So when you do a “no code solution” it means no additional code, no custom code. And this has both advantages and drawbacks. The obvious drawback is if you want to do something that the tools available can’t do, then you are SOL (Shit out of Luck)!

Here is the good news, and the reason we changed our views on in the last couple of years since the rise of Elementor and related technologies. What you can do today, using WordPress, WooCommerce, Elementor, JetPlugins and other leading technologies, is unprecedented. Elementor page builder is so good it convinced us that in most cases writing custom templates is pointless. Elementor is a faster way to create page templates, it allows focus on design, it’s just plain more efficient and enables reuse of designs elements via JSON template exports, which actually results in elements being reused. Whereas we know that although custom code templates can be reused, they almost never are in practice.

Today no code solutions can produce websites that have dynamic features by using plugins such as ACF (Advanced Custom Fields), JetEngine and other related technologies. Items can be shown or hidden based on user status and roles so that you can show public visitors one view and logged in members another. Many websites driven entirely by 3rd party plugins are now being crafted with features that make look as if they were engineered with custom code.

We’re still at the relatively early stages of what can be done without writing custom code. Elementor is not alone despite being overwhelmingly the top product in it’s category today. Oxygen page builder and others are also competing for this lucrative market. We think of these as “modern page builders”. Then there is Gutenberg, which is striving forward with rapid releases of new features, and already has it’s own ecosystem of integration plugins that might someday rival the capabilities of the page builder market.

The future is bright for all these directions. Will there still be a place for custom coding? Of course, because websites will still be invented that cannot fit into the mold of off-shelf solutions. Sites that have specific feature sets that cannot be found through any combination of plugins available. That scenario though becomes less common as new features emerge. Take for instance JetEngine, one of our favorite no-code plugins that provides a turnkey approach to making custom post types, taxonomies, option pages, fields and listing grids. In other words it’s a toolkit that provides tools for building. It doesn’t on it’s own provide anything, instead it gives the user the tools to craft content types and display them using Elementor. These kind of versatile tools bridge the gap between coded and no-code solutions, allowing developers and non-developers to work toward unique features.

Dynamic sites or data-driven websites rely on stores of data and focus heavily on rendering data. A smaller size dynamic site might have only dozens or hundreds of records. Most have thousands, or tens of thousands.

Part of the power of the dynamic site is the efficiency in terms of cost and value creation. Once the site is built, adding content is relatively fast and cheap. You don’t have to go through a process of designing a unique new section, instead the site grows by repeating an already documented process. Sometimes this process is simple enough that low-cost offshore labor can be employed to do most or all of the steps involved.

Now for those not clear on the difference, let’s make mention of the other type of site, the informational site, the branding site, the relatively non-dynamic site. Now we have to use a few descriptors to distinguish these type of sites because actually any website today other than a fully “static site” is technically dynamic. If you run a WordPress blog with 10 posts, that’s technically a dynamic site. But for our purpose, we’re also measuring the scale of the site. We’re also thinking in terms of content types that are not just blog posts or image galleries, but also have other meta data that make them a unique record.

The main problem with building information sites, is that they have such a limited capacity to drive visits. People may land on them, they see it, they scan over the text, see some images, and they on with their lives. You can try to convert them, you can try to convince them, but the reality of the situation is there isn’t much there of substance. These type of sites certainly can be effective when they fit the purpose, but there are also millions of these sites built every year that make little or no money. Often they only serve the purpose of a business being able to say they have a site and provide some basic information. This does not really lead to any significant results despite what a lot of marketing and branding people like to say.

In reality the internet is dominated by data-driven websites. All the largest websites you visit regularly, social media sites, YouTube, Google search, these are all big data-driven sites. Smaller data-driven sites typically dominate in their own niches as well. People love being able to find a treasure trove of whatever it is that interests them. This motivates them to stay, to come back, to tell their friends. The discovery of something they want, and lots of it… and guess what, there isn’t much room at the top, if they find a better selection of what they want from another site, wave goodbye!

Okay so you’ve bought a pile of Crocoblock’s and installed them into your site? What next?? I hope this RAPID FIRE GUIDE helps you move forward quickly in mastering the JetEngine and JetSmartFilter plugins.

Please note that this RapidFire Guide is designed to be a fast introduction, it presumes you are reasonably intelligent, that you mainly need direction on “where to go” and less of the “click exactly on this button”. This is about learning the process quickly, and if you get stuck, ask me for help or head over to one of the supportive Facebook groups.

Ready? Let’s begin.

First we presume you’ve installed BOTH JetEngine and JetSmartFilters. First thing we’re going to do is create a CPT (Custom Post Type). Head to JetEngine > Post Types and click Add New.

This is pretty easy so I’m not going to detail it much, choose a name click save and you’re done. Use “portfolio” as your CPT name.

Next step, add fields to your CPT under JetEngine > Metaboxes.

Now you have a CPT and fields, and of course later you can adjust those fields or CPT settings. This classic combination is similar to what many of us have done before JetEngine using ACF and CPTUI or the code equivalent.

Now that we’ve got that basic setup done, we get to do something cool that starts to showcase the power of JetEngine. We’ll make a “Listing”. Now this is a pretty generic title so it trips up some new users of JetEngine. The “Listing” is a template that will be used in a loop. Later we’re going to setup a page to see all our portfolio items, and we’ll be using a widget called “Grid List”, and the first option will be “Listing”.

Go to JetEngine > Listing, click Add New. Fill out the form. Use the exact post_type name “portfolio”. Save it. Now you have a listing setup that can be used to power a grid.

Now we head over to the Elementor Pro theme builder. Click add new template, choose Archive Template. When Elementor loads we want to search for “grid” to bring up the Grid List widget. Drop this into your page and choose the Listing template you just made in the previous step. You should now see your portfolio items appear.

Reminder now of the general process for a CPT-powered listing:

1. Create CPT (JetEngine > Post Types)
2. Create meta fields (JetEngine > Meta Boxes)
3. Create Listing for the CPT (JetEngine > Listing)
4. Create Elementor Archive Template with Listing Grid widget

I recommend doing this process again (now or sometime soon) to get very comfortable with that process because you should know these basic steps off by heart and be able to do that process in about 15-minutes or less.

Now I promised you filters, so here we go. Compared to what we’ve done so far the filters are more complex so we’ll go a little more in detail but keeping with the RapidFire Guide approach this is mainly process-oriented.

Head to Smart Filters > Add New.

Let’s start off with some basic questions. We want to think about users of the site and the primary method they use to interact with the site. Are they logged in or not?

Does the site provide a registration and membership features? Yes/No.

If the site provides registration, what are the features of the registration page? Basic form registration, or social media login account registration?

• Basic form registration
• Social media login

Will there be a transactional eCommerce component to the site? Will we use WooCommerce or an alternative?

Crocoblock is an epic creator of Elementor plugins, featuring one of the largest collections of widgets and some of the most powerful dynamic features available on the market. I’ve been debating buying the Crocoblock product after hearing a lot of good things, and decided finally to go ahead. And in a fashion that is normal for me, I have dived head first with the $200 investment into an “Unlimited Sites, All Plugins” yearly subscription. So it had better be good!!

While I’m learning I decided to start with a local site under construction called ACFLX, which is being built into an exchange (X) for ACF and Elementor components. And now of course, it might also become an exchange for JetPlugins skins or integrations. Part of my interest as a developer, is seeing how Crocoblock stacks up as potential competition for some of the related Elementor plugins we’re thinking of building which similarly focus on dynamic, data-driven solutions.

First difficult decision, what type of install to choose… I went with “Full Install”, which I think means it comes with templates and demo data but I’m not sure what the difference is exactly.

I decided to install “Investalum” which is a non-dynamic template kit. It’s for some kind of app, so I think I can convert into something suitable for ACFLX. If not I think it’s easy enough to import other template kits or just build from a canvas instead.

Next after finishing the demo import and other automated setup from the Crocoblock Wizard I found about half the plugins available were installed. But seeing as I want to try them all, I went ahead and manually installed the rest.

Time to try one of the most sought after JetPlugins in the series, JetEngine. Okay I’m about 20-minutes in after firing it up, and so far so good. In fact I’m really impressed by the field system (Metaboxes) that is baked into JetEngine. I’m pretty sure I could use ACF instead, haven’t yet checked if using ACF would mean less support from other JetPlugins like the filtering? For now I’m going to stick with their field system, and look into the difference later… ACF is basically a meta storage system anyway and from what I can see so far JetEngine works similarly.

After adding a couple of fields and making a testing post with my CPT (which I’ve named ACFLX Templates) now I’ve finally reached a point of “what next”. Couple of questions came up, one is what is the “Listing” menu item for under JetEngine menu, I opened the form, filled it out but I’m not sure what it does. I think it’s a form of template or something to do with rendering.

5:15PM / 2020-08-21

I figured out JetEngine “Listings” work, these are Elementor templates, what in other systems might be called a loop template. You set up the basics first like which post type, then you edit the template in Elementor. Then you use the “List Grid” Widget to choose the template and this will display a list of the items. This is how I hoped it worked, I’m super happy with that, the List Grid widget has a lot of query options and styling options, but for now my goal is to keep explore and not dive to deep into anything.

A new discovery for later while researching the Listing and List Grid, is Dynamic Field widget, which sounds like a fairly generic widget for displaying whatever fields might not fit into other widgets.

First moment of being a bit stuck now after trying the “Dynamic Link” widget to render the download link for a file, which happens to be a JSON Elementor template export, and it doesn’t do what I thought it would. I think that widget expects a full URL, not a file reference… so now searching how to display a file download link that is a dynamic field.

Found the solution, from the JetElements plugin, the most fundamental of the Crocoblocks comes the Download Button with full dynamic options to the rescue and sure enough it works! I’m excited I now have a semi-functional listing system.

After tinkering with a few settings and doing some non-JetPlugin setup for the site I’m trying out the JetSmartFilters plugin for the first time. Now this is exciting, because filtering is something I think of as incredibly challenging because when you code it, there is no end to the pain involved. If they are making it as simple as drag-and-drop then that will fantastic to see.

I’ve managed to get it working but I can see the JetSmartFilters being fairly challenging for some users to understand. It helps to know how these filters tend to work and be able to debug, but the options are a bit puzzling at first. I had to read some docs and switch my configuration around because I’d chosen an approach that didn’t work with the way my CPT fields were setup. Anyways got past that, and managed to put a working checkbox filter in place. Overall it took about 20-minutes, but now I feel fairly confident about being able to create a nice set of filters for these Elementor templates.

Day 2 Exploring Crocoblock’s JetPlugins

It’s day 2 as proud owner of a family of crocoblocks. Time to put them to work, chop chop! It’s 7:35AM here in Bogota, Colombia and day 832 of the lockdown (something like that!). Today I’m a little more mission-oriented on what we need from the JetPlugins for the ACFLX site. I’m setting up the hosting on our AWS Lightsail servers for the site today. And I want the site to make at least a decent impression enough that we can launch an early version of it. That means I need to figure out a way to provide a front-end form that users can fill out to send us Elementor templates in JSON format. I know we can do this with ACF if needed, but I’m going to try to use the JetEngine meta fields if that’s possible.

Adding a Search Filter

I’m excited to try out JetSearch at some point which is a separate plugin from the JetEngine, but JetSmartFilters has a search also. I think for right now that’s the one to try out to compliment the other filters being put into place.

As with the earlier checkbox filter, my first attempt was abject failure. No results when searching for a tag that I know exists.

The search filter problem was just wrong meta key used in the Query Variable setting for the filter. Worth double-checking those, I thought it was set to “tag” but it was “tags”. Editing that, and viola immediately the search is working!!

By the way if you found this post and are not already a Crocoblock’s customer but want to dive into learning this powerful suite of tools, please use my affiliate link when you sign up so I can keep producing educational content: Checkout Crockoblock JetPlugins

Front End Forms with JetEngine

It is time now to embark on a super important part of this project which is to provide a front-end form that users can use to send in Elementor Templates to our ACFLX service. And I’ve found the perfect tutorial that outlines the steps. Quick scan over it (I don’t read stuff are you kidding me!???) and I see the solution is basically “use JetEngine Forms”.

Like an onion (a beautiful sweet onion) JetEngine has layers. It turns out I don’t have JetEngine forms module activated that’s why I don’t see it on the main menu, this and other optional modules have to be turned on. I like this, it means their avoiding the weight of those modules if we don’t use them.

Built a form, setup the “Insert/Edit Post” notification… dropped in a Form Widget and run a test… it works!! Awesome, thinking back to how this is possible, but difficult (requires code or specialized widget) with ACF, I’m super impressed by this workflow. Powerful stuff, I need to add the various fields and map them to the posts before it really works but in the minimal test the form creates a blank ACFLX Template post. Success!

Ran into a snag, that tutorial actually led me astray! Find the writer and have his head brought to me on a stick! Okay it wasn’t that serious but that tutorial was more for “updating current post” which would very cool to do in some cases. However the settings are a bit different when you want a page that has a form that makes a post. See what happened is I made a page /upload/ put the form on it, and then that page actually got updated and converted into an ACFLX Template. That led to some strange puzzling moments because suddenly the slug was different, page disappeared, then appeared in a different place… crazy stuff. But now I think I’ve got it sorted out.

This turned into the first “major issue” I’ve faced on the project but I learned from that how to setup something that might be needed later which is an “edit post” front-end form. What I needed to do with the settings was “not set” the post ID, because we need to generate a new post, not update one. It’s working now and very impressive tool to have.

Setting up a Member Registration Form with JetEngine

I was just thinking what I’ve built so far at ACFLX with the filtering, grid, search, CPT, fields and then the Upload front-end form… in a coded solution would cost in the range of $3,000 or more at typical programming rates. And I am a programmer so I’m pretty confident the project would start at 3K and end up costing 12K, because that’s how coding be.

Next test of the JetEngine system is the registration form. After handling the front-end upload form I know the lay of the land better and can almost picture how to do it myself but I dug up this tutorial linked below as a reference as well.

Setting up the fields for my basic member registration form took about 5-minutes and then I mapped them, have not tested yet but I think it will work and might just need a few tweaks.

I realized after building a Registration Form in JetEngine forms, that I also have a Registration Form provided by JetBlocks. The difference seems to be the setup, the JetBlocks form is a stand-alone widget that you setup in Elementor and it’s specifically for registration… I’m going to try it later maybe on a different site but the JetEngine form works and I’ve already got it setup.

I’m not seeing a way to set the user role after the user registers. Well, it seems like setting role isn’t an option via the JetEngine form, and one way around that is to just use the WP setting “default user role”. I think that will work for now, but I hope we can set roles somehow because on some sites you might want to have 2 or more registration forms for different types of users. Is that the purpose of the JetBlock Register Form widget? Maybe.

This is kind of unrelated to Crocoblocks and the JetPlugins but we do need header and footer so I whipped one together using a color scheme that I found by searching “good color scheme”. #brilliant

This was the result:

After some styling of the Upload and Registration forms, pretty happy with how everything looks. I mean hey, it’s day 2 and I’m not a designer, just a programmer with Google access and here we are with a decently styled set of pages. I’m liking the “NO CODE” movement so far.

Despite a few small issues with the file upload field, I’ve managed to get the remainder of the Upload fields into place. At least for now, because I don’t this will be the final list. For instance I have a “type” field that is meant to be the Elementor template category, and that should be replaced by a taxonomy field.

Day 3 of the Crocoblock Party

Day 3 I decided it’s time to take ACFLX live so I had to do some server configuration to setup the hosting and then while the DNS was updating, I hopped into thinking about how to use some of the JetPlugins here on Eat/Build/Play.