Color pallet styling issue on multisite projects

[RoblesRob]

Hello, Log1x ,

I wanted to inform you, that faced with issue related to the styles broken for the color palette in admin panel after updating the plugin to v1.1.8.

The problem affects multisite projects, non-multisite project works as expected.

Additionally, there is present following error in console: Refused to apply style from '.../plugins/acf-editor-pallette/public/css/field.css because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

Notes:

• non-multisite projects load the file field.d1c65e.css without any issues with plugin v1.1.8.

• with downgrade plugin version to v.1.1.7 no such issues detected.

Versions comparing https://github.com/Log1x/acf-editor-palette/compare/v1.1.7...v1.1.8

For additional info: the projects are using roots versions 3.3.1 and 4.3.

Thanks you for you support.

[Log1x]

It's strange that the console error for field.css (which would 404, thus the text/html MIME type) is getting called without the hash.. Despite changing to Bud, looking at the code, I'm not seeing where anything has changed in how the URI/Path is pulled for enqueueing the assets. The code was pretty lightly changed from how I handled the Mix manifest unless I'm completely overlooking something. Could something be cached somehow?

Is there any more info you could give me or debugging you could do? I don't currently have a multisite environment for quick testing.

[codepuncher]

Happy to try any suggestions @Log1x you may have. The issue is not dependent on the environment (same issue on local where there is no caching).

I've had a look through the changes between 1.1.7 and 1.1.8 but can't spot anything either, but something between them has caused the issue.

[Log1x]

It'd help if you could just dump() or dd() around in https://github.com/Log1x/acf-editor-palette/blob/master/src/Concerns/Asset.php and see if you can spot what is not getting the correct value.

Can also dump the asset calls at https://github.com/Log1x/acf-editor-palette/blob/master/src/Field.php#L280-L282 to see if you can spot the inconsistency.

Any help on this is appreciated, I'm really busy right now. :(

[codepuncher]

No worries, will get you those outputs.

[Log1x]

https://github.com/Log1x/acf-editor-palette/blob/master/plugin.php#L62-L63 are where the uri/path come from btw

[codepuncher]

https://github.com/Log1x/acf-editor-palette/blob/99a609a01c512ae0424a8879a6cc1de7f096fc02/plugin.php#L62-L63

<?php
$this->uri = plugin_dir_url(__FILE__) . $this->path;
$this->path = plugin_dir_path(__FILE__) . $this->path;
dd(
    $this->uri, // "https://bedrock.test/app/plugins/acf-editor-palette/public/"
    $this->path, // "/path/to/bedrock/web/app/plugins/acf-editor-palette/public/"
);

Looks fine there to me.

However, the other places you've asked for output don't seem to be getting called! Seems like the Field class and Asset class are not being used; can't see any output anywhere regardless of using wp_die() or dd().

Not sure where the "disconnect" is coming from.

[Log1x]

Field gets registered with ACF here and has the Asset trait on it.

Might need to dump that stuff a different way. Maybe ACF is catching your attempts at debugging internally or something. Otherwise, all of that stuff is just cookie cutter boilerplate for registering a custom ACF field type off of their acf_field class.

[codepuncher]

This is now happening on non-Multisite installations. When I can find the time I will do more debugging.

[Log1x]

Looking forward to hearing what you find out. I have this in production on 6 sites right now without any issues. All are loading the proper hashed field.css and field.js from public.

[codepuncher]

OK, silly mistake on our end; we had log1x/acf-editor-palette in both Bedrock and Sage composer.json. Removed it from Sage (which was on the version prior to the asset refactor, hence field.css) and now the issue is resolved.

Love a good PICNIC!

[Log1x]

glad you figured it out