Can I bind in-page “triggers” to “actions” natively in WordPress?
Yes – depending on what you mean by “natively.” Whether implemented in a theme or a plugin, using blocks or shortcodes or neither, all of these things are perfectly possible and have been done using WordPress.
But the question is if this can be done “zero-code” in WordPress
Yes and no.
All of the functionality you have described is general front-end interactivity, and WordPress core is not really responsible for such things. It provides the systems on which to create nearly any functionality and end-user experience, but does not provide some bloated “standard library” of every imaginable behavior from which to build every front-end experience by itself. This is the responsibility of themes and plugins – to extend and tailor a WordPress installation to fit a specific project’s needs.
More than likely you could achieve all of the listed effects without code if you put the legwork into finding appropriate extensions. The realm of what’s possible in WordPress thanks to extensions was already fairly substantial, and the new Block and Site Editor functionality is rapidly expanding that realm even further (but both are still in active primary development – it will take a while for their ecosystems to catch up).
Given the simplicity of the features described, if you are comfortable working with JS/PHP/HTML (and brownie points for React), spending a little time learning to use a few of WordPress’s foundational APIs could well pay dividends – coding those features from scratch may well prove faster than finding themes or plugins to satisfy them.
Basic CSS/JS Loader Plugin Example
To get started with plugin development, you’ll want to refer to the Plugin Developer Handbook and the Theme Developer Handbook. There’s sort of some cross-over in scope between the two as both leverage the same core APIs to achieve their goals – so if something you’re looking for isn’t in one it may well be in the other. The Code Reference can assist with more general documentation on functions and “hooks” (callbacks attached to “actions”/”filters” – general lifecycle events and events providing points to modify values before they are used, respectively).
Below is an example of a super-basic plugin to load some frontend assets. Placed in it’s own directory within wp-content/plugins it will be available for activation in the Plugins screen on the dashboard.
<?php
/**
* Plugin Name: WPSE406402
*/
function wpse406402_enqueue_scripts() {
// Enqueue a local JS file to be loaded on every page.
wp_enqueue_script(
'wpse406402-global', // A handle to identify this script.
plugins_url( '/assets/js/index.js', __FILE__ ), // The URL to the script.
[ 'jquery' ] // Script dependency handles - WordPress will make sure this script loads after these.
);
// Use conditionals to enqueue a JS file only on the home/front page.
if( is_home() || is_front_page() ) {
wp_enqueue_script( 'wpse406402-home', plugins_url( '/assets/js/home.js', __FILE__ ), [ 'wpse406402-global' ] );
}
}
// When WordPress fires the `wp_enqueue_scripts` "action" (event), execute the callable to enqueue our scripts.
add_action( 'wp_enqueue_scripts', 'wpse406402_enqueue_scripts' );
function wpse406402_enqueue_styles() {
// More or less the same procedure as for scripts!
wp_enqueue_style( 'wpse406402-global', plugins_url( '/assets/css/index.css' ) );
}
// Counter-intuitively, style files are also enqueued on the `wp_enqeue_scripts` action.
add_action( 'wp_enqueue_scripts', 'wpse406402_enqueue_styles' );
As a footnote, wp_enqueue_script() also accepts a version number used for caching and a boolean to load the script in the footer instead of <head>, and wp_enqueue_style() accepts a version number as well. For cache-busting in development, I like to create an enqueue function wrapper which will use the modified time of the file as a version number if WP_DEBUG is enabled, or a constant plugin version number if not – a small convenience which saves a lot of hard-refreshing.