Elementor Accordian Field

Thinking a bit more on this, there are likely two ways one could go about it:

1. One could use a Pods relationship field to make a relationship to a post type which has the layout managed by Elementor. This would cause the related post type, even if it is a post type related to itself, to appear in a modal dialog with the default WordPress admin interface, which Elementor extends. Displaying the content may be another thing, as when an Elementor layout displays, it also enqueues scripts and styles, so simply displaying content from the related post may not be enough for an accordion to behave as expected.
2. The source code for the Elementor classes which output an accordion can be found at modules/nested-accordion/module.php and modules/nested-accordion/widgets/nested-accordion.php, both within wp-content/plugins/elementor.
   
   The module managed the widgets, which get instantiated with various configurations. One might think one could simply call something like $accordion = new \Elementor\Modules\NestedAccordion\Widgets\Nested_Accordion();, but there are several challenges with attempting to render that user interface element outside of an Elementor page builder context:
   
   – The render() method is protected. Therefore, one would have to write another class extended Nested_Accordion in order to render it in unexpected contexts.
   – Settings for rendering a module come from get_settings_for_display() from the abstract Controls_Stack, which expects settings to have been saved from their panels. One would either need to override this method, or find a way to filter the widget settings.
   – Elementor modules enqueue JavaScript files on the elementor/editor/before_enqueue_scripts action in order to provide animation and interaction for things like accordions. In a normal workflow, whichever scripts are required is determined early in the page load. When this happens, one typically needs to detect which scripts are needed for cases of unexpected workflows.

The challenge with Elementor is that its modules expect to be rendered in a context which completely replaces the normal WordPress frontend and backend workflow. A Pods field controls a single field in a meta table or a single posts’ content display. It works inside page editors:

Pods can be loaded within Elementor or the Block Editor or many other page builder contexts, but it is challenging to load Elementor et al within a Pods context, because such page builders expect to be in a context where they take additional control over the full page rendering and editing process.

For that reason, unless I am missing something in the Elementor Developer docs, most workarounds for displaying Elementor content within the context of a single field, such as what Pods provides, will typically involve maintaining Elementor’s isolation in its own context: things like loading the rendered content as an entire page within an iFrame, loading the editor within a modal pop-up using a relationship field, or more advanced trickery such as injecting Elementor scripts onto pages when they reference sub-content from Elementor, but do not actually use Elementor as the primary page renderer.