Breaks Field Group Settings when active

[vlaskiz]

Describe the bug When the plugin is active it breaks field group settings page when it contains WYSIWYG Editor field. Seems to conflict with ACF Extended Pro. Seems something related to WYSIWYG toolbars.

To Reproduce Steps to reproduce the behavior:

1. Activate plugin
2. Go to edit a field group that contains WYSIWYG Editor field
3. Page breaks (PHP fatal error)

PHP Fatal error:  Uncaught Error: Call to undefined method stdClass::get_toolbars() in \wp-content\themes\theme\lib\acf-extended-pro\pro\includes\fields\field-wysiwyg.php:293
Stack trace:
#0 \wp-includes\class-wp-hook.php(324): acfe_pro_field_wysiwyg->render_field_settings(Array)
#1 \wp-includes\class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array)
#2 \wp-includes\plugin.php(517): WP_Hook->do_action(Array)
#3 \wp-content\themes\theme\lib\acf-core\includes\admin\views\acf-field-group\field.php(197): do_action('acf/render_fiel...', Array)
#4 \wp-content\themes\theme\lib\acf-core\includes\api\api-helpers.php(350): include('D:\\laragon\\www\\...')
#5 \wp-content\themes\theme\lib\acf-core\includes\admin\views\acf-field-group\fields.php(90): acf_get_view('D:\\laragon\\www\\...', Array)
#6 \wp-content\themes\theme\lib\acf-extended-pro\pro\includes\fields\field-wysiwyg.php on line 293

[johannheyne]

Hi,

thanks for reporting me that bug. It should be fixed in the new version 1.2.4. Please get the get latest plugin version from you account page and try.

Thanks Johann

[vlaskiz]

Hi,

that solved the issue with fatal error, but now plugin generates 13 PHP notices (and does not seem to display the table in the backend, when editing the post, but displays the output in the frontend).

wp-content/plugins/advanced-custom-fields-table-field-pro/acf-table-pro-class.php:116
JHeyne\WP_ACF_TableFieldPro\acf_tablefield_pro->get_dir_url()
wp-content/plugins/advanced-custom-fields-table-field-pro/acf-table-pro-class.php:160
JHeyne\WP_ACF_TableFieldPro\acf_tablefield_pro->define_class_vars()
wp-content/plugins/advanced-custom-fields-table-field-pro/acf-table-pro-class.php:96
JHeyne\WP_ACF_TableFieldPro\acf_tablefield_pro->__construct()
wp-content/plugins/advanced-custom-fields-table-field-pro/acf-table-pro.php:85
{closure}()
wp-includes/class-wp-hook.php:324
do_action('acf/include_field_types')
wp-content/themes/theme/lib/acf-core/acf.php:331
ACF->init()
wp-includes/class-wp-hook.php:324
do_action('init')
wp-settings.php:700

[johannheyne]

the warnings should be fixed in 1.2.5

[vlaskiz]

Sorry, but it seems that they are still there (same ones).

Also tables are not visible on admin pages (while editing a post or in a field group where you can pre-define one).

Installing older version fixes table display on admin pages editing screens, but brings back fatal error to field group settings of course.

I also see following errors in console:

/wp-content/plugins/advanced-custom-fields-table-field-pro/styles.css?ver=0.0.1 net::ERR_ABORTED 404 (Not Found)
/wp-content/plugins/advanced-custom-fields-table-field-pro/script.js?ver=0.0.1 net::ERR_ABORTED 404 (Not Found)

Also might be related to these scripts missing or not:

jquery.min.js?ver=3.6.0:2 jQuery.Deferred exception: ACFTableFieldProModules is not defined ReferenceError: ACFTableFieldProModules is not defined
    at ACFTableFieldProMain.t.initModules (/wp-content/plugins/advanced-custom-fields-table-field-pro/js/main.js?ver=0.0.1:3383:5)
    at HTMLDocument.<anonymous> (/wp-content/plugins/advanced-custom-fields-table-field-pro/js/main.js?ver=0.0.1:3452:25)
    at e (/wp-content/themes/theme/assets/js/dist/jquery.min.js?ver=3.6.0:2:30038)
    at t (/wp-content/themes/theme/assets/js/dist/jquery.min.js?ver=3.6.0:2:30340) undefined

Uncaught ReferenceError: ACFTableFieldProModules is not defined
    at ACFTableFieldProMain.t.initModules (main.js?ver=0.0.1:3383:5)
    at HTMLDocument.<anonymous> (main.js?ver=0.0.1:3452:25)
    at e (jquery.min.js?ver=3.6.0:2:30038)
    at t (jquery.min.js?ver=3.6.0:2:30340)

[johannheyne]

Hi,

I found another possible issue. Please try version 1.2.6

If that doesn't help, then I will also integrate a filter to set the plugin path and URL manually.

[vlaskiz]

Hi,

couple suggestions:

You check for '/wp-content/' in get_dir_url and get_dir_path but some environments have it '\wp-content\' so that was contributing to my issues.

Additional checks would be nice (some possible overhead is better than generating fatal errors in some cases)

function localize_acf_toolbars() {

    $wysiwyg = acf_get_field_type( 'wysiwyg' );

    if ( $wysiwyg && is_object( $wysiwyg ) ) {
        $wysiwyg->acf_enqueue_uploader();
    }
}

In all modules init $GLOBALS['acf_tablefield_pro']->get_dir_url(__FILE__) should be replaced to a simple plugin_dir_url( __FILE__ ) This fixed all notices

But I still do not understand why the table is not being rendered in the backend.

[johannheyne]

Yes, the problems certainly have to do with the Windows paths having backslashes. I hadn't taken this into account. Version 1.2.7 may fix that.

Now I provide wp_normalize_path() on paths to fix Window paths issues.

I think, I will stick with the get_dir_url(__FILE__) method to enable future embedding of the plugin into themes and other plugins.

To may adapt or fix somehow broken plugin asset URLs, I integrated the filter 'acf_tablefield/settings/url'. So in accordance with the terms of use of the purchased license and upcoming licenses, the table field plugin could include in plugins or themes the same way as the ACF plugin.

Thanks for your help. Johann

[vlaskiz]

Okay, I've removed some code in my theme which I wrote to get around some issues with your plugin and it seems all good in the admin area. EDITED - actually happens in admin too, so I just adjusted my code to eliminate dependancy errors but to not break table editing.

In front side of the website, however, I am getting scripts and styles missing dependacies errors: acf-input, acf-table-pro-main (missing)

I use this code in my theme to get around the issue:

    if ( isset( $GLOBALS['acf_tablefield_pro'] ) ) {

        wp_register_script( 'acf-table-pro-core', $GLOBALS['acf_tablefield_pro']->plugin_dir_url . 'js/core.js', array( 'acf-input' ), '0.0.1' );
        wp_register_script( 'acf-table-pro-main', $GLOBALS['acf_tablefield_pro']->plugin_dir_url . 'js/main.js', array( 'acf-input' ), '0.0.1' );

        $all_modules = [];
        $modules = scandir( $GLOBALS['acf_tablefield_pro']->plugin_dir_path . 'modules/' );

        foreach ( $modules as $key => $item ) {

            if (
                ! defined( 'ACF_TABLE_FIELD_PRO_DEVELOPER_MODE' ) AND
                $item === 'developer'
            ) {
                continue;
            }

            if ( $item[0] != '_' ) { // Modules with a trailing lodash in the foldername are ignored.

                $module_script_path = $GLOBALS['acf_tablefield_pro']->plugin_dir_path . 'modules/' . $item . '/script.js';

                if ( file_exists( $module_script_path ) ) {

                    $all_modules[] = $item;
                }
            }
        }

        wp_localize_script( 'acf-table-pro-main', 'ACFTableFieldAjax', array(
            'ajax_url' => admin_url( 'admin-ajax.php' ),
            'plugin_url' => $GLOBALS['acf_tablefield_pro']->plugin_dir_url,
        ));

        wp_enqueue_script( 'acf-table-pro-core' );
        wp_enqueue_script( 'acf-table-pro-main' );

        wp_register_style( 'acf-table-pro-main', $GLOBALS['acf_tablefield_pro']->plugin_dir_url . 'css/input.css', array( 'acf-input' ), '0.0.1' );
        wp_enqueue_style( 'acf-table-pro-main' );
    }

But it would be nice to have no errors as such :)

[johannheyne]

I assume the Windows path problem is solved. The scripts and styles source paths in the sreenshots looks correct.

First, the table field main script should be depending on the core script like in this example: wp_register_script( 'acf-table-pro-main', $GLOBALS['acf_tablefield_pro']->plugin_dir_url . 'js/main.js', array( 'acf-input', 'acf-table-pro-core' ), '0.0.1' );

I don't understand why the table field scripts and styles are embedded in the fronend. These styles and scripts are integrated by wp_register_script() depending on the ACF scripts and styles. This means that ACF also loads its scripts in the frontend in your situation, which it normally doesn't do. Do you use the acf_form() functionality for frontend forms?

I have some questions: Did you tested the version 1.2.7 and cleared all caches and removed all fixing code? I also have had some strange experiences with changes that did not take effect immediately. Sometimes changes only took effect after turning the ACF Extended Pro plugin off and on again.

I hope we can get a little further here. But I need more precise information to understand the remaining issues.

[vlaskiz]

Hey

• Do you use the acf_form() functionality for frontend forms? I personally do not use acf_form fields or functionality.

• Did you tested the version 1.2.7 and cleared all caches and removed all fixing code? I did, yes. No cache plugins on my test environment.

• I also have had some strange experiences with changes that did not take effect immediately. Sometimes changes only took effect after turning the ACF Extended Pro plugin off and on again. I have both ACF and ACF Extended Pro included in the theme via php files, not enabled as a plugin. I did comment it out, refresh a window, and include it once again, errors are still present.

So main scripts are not loaded, while modules classes are instanciated into your globals variable and you also hook that in add_action( 'acf/init', array( $this, 'init_modules' ) ); hook, so I assume these modules just load everywhere and anywhere, be it frontend or backend (except maybe not in comment and forms, which you outlined in the code comments) but following functions which would execute your plugin main scripts are not loaded anywhere it seems (acf extended for example, do hook these functions where needed it seems):

field_group_admin_enqueue_scripts
input_enqueue_scripts

I think it's a matter of loading things where they don't need to be loaded or not loading core scripts where they are needed. Might be wrong about some things, but maybe that gives you some ideas around the issue.

[johannheyne]

Yes, very good tip. I did not used the ACF action 'acf/input/admin_enqueue_scripts' to enqueue the module scripts. I fixed that now.

For some reason, I didn't get any errors on my local environment and I assumed that the dependency definition of module scripts in wp_register_script() meant that the module scripts were not loaded if the main script was not loaded. The main script was included using the ACF action 'acf/input/admin_enqueue_scripts'.

Please try plugin version 1.2.8 if that fixes the issue.

Thanks a lot, Johann

[vlaskiz]

Seems good now with v1.2.8, no notices or errors of any kind and that's without my custom code to fix issues.

Thanks again.