How do I find out what is in control over a certain part of a website?

by

However WordPress does it, it can’t peer inside BuddyBoss if BuddyBoss decides to implement its own system ( and almost all the pagebuilder plugins or bespoke systems do ).

Fundamentally responsibility on the frontend falls into these buckets:

  • the theme
  • filters
  • blocks/shortcodes/widgets
  • nav menus
  • plugins generated UIs such as ACF field layouts, WP Bakery, Elementor, Learndash, WooCommerce etc..

The theme is a free for all, there’s several functions and filters common to most themes (but not all) that plugins etc can hook into to add extra content. Themes have a template hierarchy, and any template can load arbitrary files via get_template_part. This can load templates from a child theme too if that is in use.

Keep in mind that a theme may ignore most of this and present a barebones frontend with a script tag that loads a headless application using Vue or React.

Filters give any code opportunity to insert itself into a location or to modify something being filtered. For example, your post content might have a large chunk of additional content on the end, which can be added by any plugin or the theme in any location. There is no neat logic that ties it to a specific place.

Blocks/shortcodes/widgets, are the closest to what you’re used to, and going forward WordPress output becomes more and more block oriented as block based themes become more common. Shortcodes and widgets are still going to be around for legacy reasons but they are being de-emphasised heavily and replaced with blocks, e.g. the new block based widget editor.

Nav menus display their HTML via a walker class, and these are usually represented by a wp_nav_menu call. A lot of themes override the walker to implement bespoke menu HTML, especially bootstrap UIs.

Plugin generated UIs are individually unique and bespoke. E.g. There are themes and plugins that load Laravels blade templating system. I’ve seen sites that use Twig to generate HTML output. Some plugins re-use shortcodes in a custom interface with custom filters. Custom is the key word, they all have unique and individual implementations and do not have generic shared solutions.

For example a form from Gravity Forms and a form from Ninja Forms are incompatible, they don’t use a common framework, they’re totally bespoke independent codebases with different approaches to how they render their HTML. They might provide a block or a shortcode, but the internals and what gets outputted in that location is a blackbox with its own documentation and APIs.

P.S.: My question is not just about Buddyboss. My question is about understanding how wordpress manages elements on a page on a more basic level.

Unfortunately, the general answer is not going to be very useful to you, and unsatisfying.

  1. Inspect the code of the item you’re interested in for clues. HTML class names can give big hints, e.g. if it has the class name wp-popular-posts-widget, well it’s probably the popular posts widget.
  2. If there is no obvious culprit, then you need to search your entire codebase for parts of the HTML. Think grep or the right click Find in folder in Visual Studio Code.
  3. If that gives no results, try other fragments, otherwise it’s likely that the code was either generated dynamically, or is in the database

Having a quick look at BuddyBoss’ main product website, the likelihood that any of these are the fastest route for you are vanishingly small. By choosing to ignore BuddyBoss’ support routes documentation and community you’ve made your task 100x harder and longer.

The probability that the HTML you’re looking to change or add is inside a BuddyBoss file or can be changed via a BuddyBoss API or modification is overwhelming. You need BuddyBoss help, not WordPress help. It may even be that you will never find the HTML from the site you’re copying because they hired a developer to write custom code specifically for them.

The closest WP’s templating system itself will provide is:

  • if your theme is built correctly it will call body_class which will put hints of what WP tried to load from the template hierarchy e.g. post-template-default or archive
  • A plugin such as query monitor will give more information about which files were loaded via get_template_part

Neither of this will tell you which parts of the page map to which parts, and not all parts of the page come from templates, assuming a template did anything at all. It’s even possible a plugin or themes code bypassed the templating system completely at an early point.