When Custom Hooks Are Not the Solution<\/h2>\n\n\n\n
When mentioning \u201ccustom code,\u201d I don\u2019t mean quite harmless CSS custom rules, but PHP functions or PHP + JavaScript solutions hooked into WordPress to control behavior, output, or dynamic interactions. However, hooks are not as bad, if not overused, but the worst scenario is hardcoding theme files directly. <\/p>\n\n\n\n
Writing such custom code snippets might seem like a flexible solution, but it often comes with hidden drawbacks. They can conflict with plugins or theme updates, break silently when WordPress changes its core behavior, and are harder to debug, especially when multiple snippets interact in unexpected ways. Maintaining them over time becomes a burden, especially in larger projects or when working in teams. Plus, what starts as a \u201cquick fix\u201d often turns into a tangled mess that’s difficult to scale or hand over to another developer.<\/p>\n\n\n\n
Let\u2019s talk about such drawbacks more specifically.<\/p>\n\n\n\n
Drawbacks of Custom Code Snippets<\/h2>\n\n\n\n
Using custom PHP or JavaScript snippets in WordPress is a common way to add dynamic functionality, but it\u2019s not always the best long-term approach. Here\u2019s why:<\/p>\n\n\n\n
- \n
- Conflicts and compatibility issues<\/strong> can arise, as custom code can easily clash with plugins, themes, or even core WordPress updates. What works today might silently break tomorrow.<\/li>\n\n\n\n
- Debugging <\/strong>gets complicated because when something goes wrong, it\u2019s not always obvious which snippet is the culprit. Especially in projects where multiple devs have added logic over time.<\/li>\n\n\n\n
- Poor scalability<\/strong>. As your project grows, what started as a simple piece of code can turn into an unmanageable web of dependencies and conditionals.<\/li>\n\n\n\n
- Not easy to maintain<\/strong> and client-friendly. If you’re handing the project off to a client and their maintenance team is less technical or just can\u2019t track all your custom snippets, it will be a big issue if something needs to be changed. <\/li>\n<\/ul>\n\n\n\n
As you can see, tweaking WordPress functionality using code snippets is not really a sustainable solution, unless it\u2019s just a couple of things to be changed. And, if such a need arises, here are some recommendations.<\/p>\n\n\n\n
What If You Still Need Some Custom Code?<\/h2>\n\n\n\n
Sometimes, custom code is unavoidable, especially for very specific functionality that no plugin covers. In that case, here\u2019s how to do it right:<\/p>\n\n\n\n
- \n
- If your snippet relies on specific plugins, post types, or user roles, clearly indicate this in the code comments,<\/strong> readme file, or website documentation<\/strong>.<\/li>\n\n\n\n
- Use dedicated plugins<\/strong> for code snippets, so you can clearly see what is working under the hood, debug, and deactivate them.<\/li>\n\n\n\n
- Wrap bigger code chunks into custom plugins<\/strong> instead of dumping snippets into functions.php. This keeps your logic separate from the theme, making it portable and avoiding accidental loss during theme updates.<\/li>\n\n\n\n
- Stick to WordPress best practices and use actions and filters<\/strong> (hooks)<\/strong> instead of hardcoding things into templates. This keeps your code flexible and easier to troubleshoot.<\/li>\n<\/ul>\n\n\n\n
Meet the Crocoblock Tools: No-Code Powerful Solution for Dynamic Websites<\/h2>\n\n\n\n
<\/figure>\n\n\n\n
Crocobloc suite<\/a> is 20 plugins plus the JetFormBuilder form plugin. All of them have an accent on dynamic content. Most of the plugins are premium and can be purchased separately; however, the most profitable method is to opt for the All-Inclusive plan, which costs $199 per year for one site and $399 for unlimited sites. Lifetime deals are also available. <\/p>\n\n\n\n
Most of the plugins are made for dynamic content, filtering, bookings, and forms that work with the Block Editor, Elementor, and Bricks. In the future, Divi compatibility will also be available. And, there are also Elementor add-ons that extend the builder\u2019s functionality. <\/p>\n\n\n\n
The key plugin that adds a lot of functionality under the hood is JetEngine <\/strong>\u2013 it\u2019s, as the name suggests, comparable to the powerful jet engine that puts your website on steroids. The module system, which allows you to switch components on and off, makes the website lightweight, plus, the Performance settings provide full control over builder-support loading. <\/p>\n\n\n\n
And, of course, it has seamless compatibility with the rest of the plugins, extending their functionality. Using it, you can create custom post types, custom fields, taxonomies, relations, or compact content types called Custom Content Types that are perfect for a performance boost.
But the uniqueness of this plugin comes at the point when the data should be queried \u2013 the unique Query Builder tool can do it for you using a friendly visual UI. <\/p>\n\n\n\nThen, to display it on the front end, you can use the template editor and your favorite builder, from Elementor or Bricks, to the Block Editor or even Twig, if you prefer the lightest DOM structure. There are calendars, tables, sliders, and maps available to display your content on the front end with no effort. <\/p>\n\n\n\n
Not to mention that JetEngine\u2019s REST API functionality offers more features than even dedicated premium plugins. <\/p>\n\n\n\n
This is just JetEngine<\/a>, and I will talk more about the details later. <\/p>\n\n\n\n
But there are more plugins: the feature-rich JetFormBuilder, powerful and user-friendly JetSmartFilters, JetBooking and JetAppointment for flexible booking functionality, JetSearch offers flexible and controllable search functionality, JetThemeCore is responsible for Theme Building for Elementor and Block Editor, JetWooBuilder will help you to edit Elementor WooCommerce templates, and much more in the full Crocoblock toolkit. <\/p>\n\n\n\n
So, here are some of the use cases when custom code can be easily replaced by the fully visual functionality of Crocoblock plugins.<\/p>\n\n\n\n
Modifying WooCommerce Templates in Elementor<\/h2>\n\n\n\n
Crocoblock plugins involved: JetWooBuilder, JetThemeCore (optional)<\/em><\/p>\n\n\n\n
While WooCommerce is a very powerful tool, it lacks flexibility in template editing, and to hide or move some sections in any of its templates, you will need to write a hook to first hide it, then (if you move it), display it but with another priority. In case you want to change the visual appearance of elements, you will have to find their CSS classes and add custom CSS to make the changes. But if you want to add animation or change behaviour requiring JavaScript, you have to be careful and make sure that the script will not affect other elements. <\/p>\n\n\n\n
Here is where JetWooBuilder <\/strong>comes to the rescue \u2013 it\u2019s a more in-depth and flexible solution than the similar functionality of Elementor Pro, not to mention that, if you use free Elementor, this functionality is not available. <\/p>\n\n\n\n
For example, this is the code you need to move the \u201cAdd to Cart\u201d button a bit higher and place it under the title:<\/p>\n\n\n\n
\/* Unassign the old priority *\/\nremove_action( 'woocommerce_single_product_summary', 'woocommerce_template_single_add_to_cart', 30 ); \n\n\/* Assign the new priority *\/ \nadd_action( 'woocommerce_single_product_summary', 'woocommerce_template_single_add_to_cart', 6 );\n<\/code><\/pre>\n\n\n\nWith JetWooBuilder, you can do it just by dragging and dropping elements wherever you want them to be. In combination with JetThemeCore<\/strong><\/a>, you can also add custom headers and footers and different templates for particular user roles, devices, query variables, etc.<\/p>\n\n\n\n
Fetching Any Content From WordPress Database<\/h2>\n\n\n\n
Crocoblock plugins involved: JetEngine<\/em><\/p>\n\n\n\n
Let\u2019s say I have the Event custom post type, and want to fetch values of custom fields \u201cdate,\u201d \u201cevent name,\u201d and \u201cevent description.\u201d It\u2019s a very simple query, just for demonstration, but this is how it looks as a code based on the WP_Query PHP class:<\/p>\n\n\n\n
<\/figure>\n\n\n\n
To show the data on the front end, I can wrap the code in a shortcode and use HTML containers around each field so I can style them later with CSS.<\/p>\n\n\n\n
But what if I want to show only events by a specific author? Or filter them by category, or display only the ones where a certain custom field has a specific value? That\u2019s where it starts getting tricky. I\u2019d need to write a new custom query for every case, and those queries can get long and messy fast. Plus, I wouldn\u2019t be able to control anything from the WordPress dashboard. Every time something changes, I\u2019d have to go back to the code.<\/p>\n\n\n\n
Sure, page builders like Elementor Pro or Bricks let you show posts and users with some filtering, but they hit a wall when things get more complex. For example, if I want to get a list of users who published something last week, or people with birthdays coming up next month, or if I want to filter inside repeater fields, that\u2019s not something WP_Query can easily handle. And at that point, I\u2019d need to write raw SQL.<\/p>\n\n\n\n
That\u2019s exactly where JetEngine\u2019s Query Builder comes in. It lets you build those complex queries visually \u2013 combine different conditions, filter by anything you want, set the sort order, and even create multi-layered queries without touching code. <\/p>\n\n\n\n
After querying, you don\u2019t have to worry about HTML and CSS \u2013 there\u2019s a visual Listing Templates builder, so you can design every loop element and then display it as a grid, list, table, calendar, slider, or on the map.<\/p>\n\n\n\n
<\/figure>\n\n\n\n
Collecting Data From Different Websites on One Site Using REST API<\/h2>\n\n\n\n
Crocoblock plugins involved: JetEngine, JetFormBuilder<\/em><\/p>\n\n\n\n
Imagine a scenario where several websites are collecting registration data for an event using forms, and all that data needs to be gathered and displayed on a central website. Why use multiple sites instead of redirecting users to one? There are plenty of practical reasons \u2014 separate campaigns with unique user flows, regional discounts, or different language and location-specific versions.<\/p>\n\n\n\n
In this setup, you have a Central <\/strong>site (where the data is collected and displayed) and sites A<\/strong> and B<\/strong> (where users submit their registrations). The communication between them is handled via the REST API. And even today, if you want to build something this connected and dynamic, you’re still going to need custom code.<\/p>\n\n\n\n
This is an example of code just to send data from sites A and B, where you should connect the submit event of your form so it would trigger the sending process:<\/p>\n\n\n\n
<\/figure>\n\n\n\n
Then you will need twice as many lines of code to register a REST API endpoint on the Central site and, finally, write a query to fetch it and then somehow display it on the front end. <\/p>\n\n\n\n
There\u2019s also an additional layer of coding and testing to control security, so your website would not receive some random spam instead of registrations. <\/p>\n\n\n\n
Goot news that JetEngine can handle it fully visually<\/a>, in three simple steps<\/strong>:<\/p>\n\n\n\n
- \n
- On the Central site, create a \u201cParticipants\u201d CCT (custom content type that stores data on a separate DB table, not to bloat your wp_posts table) and switch the REST API endpoint toggle to the ON position \u2013 you will get the endpoint URL generated. You can configure security settings right there. <\/li>\n\n\n\n
- On the A and B sites, create JetFormBuilder forms. Choose REST API Request on the post-submit actions on the form settings, and paste the endpoint URL from the Central site. <\/li>\n\n\n\n
- Congrats! The form records will be saved on the Central website in the \u201cParticipants\u201d CCT, which you can display on the front end by creating a Listing Template by JetEngine fully visually. <\/li>\n<\/ol>\n\n\n\n
There\u2019s a second way to display, not only form submission, but any data from website A on website B. On the website B, go to JetEngine > JetEngine<\/strong> and open the REST API tab. There, insert the API endpoint for the post type from site A that you want to display on site B. For example, you have \u201cDoctors\u201d post type on website A. The URL will be:
<\/p>\n\n\n\nhttps:\/\/website-A.com\/wp-json\/wp\/v2\/doctor<\/a><\/p>\n\n\n\n
Insert it there, adjust the security, and test the connection.<\/p>\n\n\n\n
Then, go to JetEngine > Query Builder<\/strong> and choose the REST API query type (yes, you can query even data from remote sites using Quethe ry Builder) and define what exactly you want to display \u2013 you can choose among all available fields. <\/p>\n\n\n\n
And, finally, create a Listing Template based on this query.<\/p>\n\n\n\n
Other Cases When You Don\u2019t Need to Code If You Have Crocoblock<\/h2>\n\n\n\n
Show or hide blocks based on user status or role, device, time of the day, time period, etc.<\/strong>
Use JetEngine\u2019s Dynamic Visibility<\/a> to control whether a section appears based on whether the user is logged in, has a specific role, or even based on their custom meta fields \u2013 no PHP IF <\/em>statements or role checks needed.
In case you want conditional visibility on the post level (header, body, footer), use a variety of conditions by JetThemeCore.<\/p>\n\n\n\n
- Use dedicated plugins<\/strong> for code snippets, so you can clearly see what is working under the hood, debug, and deactivate them.<\/li>\n\n\n\n
- Debugging <\/strong>gets complicated because when something goes wrong, it\u2019s not always obvious which snippet is the culprit. Especially in projects where multiple devs have added logic over time.<\/li>\n\n\n\n
![\"\"\/](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXfqx040ULCrxyWSHhNbbjH8YJRwWPDpWOrdVaNC5lx0brdr_VOvQS5TqnrYV5k2Mmwq5NnSk_IgM3HxccP4YATmdGgwdQWQKWqSjiI2F4b0gxfv90ZwlzrqIg81vnfEb7fJDVETSw?key=BpZNX4pqn3kVyQw9dRWEdQ\")
<\/figure>\n\n\n\n