J B

Just wanted to drop an update here: the tested-up-to version has been updated. I took the opportunity to test it with 4.6 too, so that’s now the version up to which it’s been tested.

Hi anazukov, thanks for your inquiry!

The short story is that, no, the plugin is not going to move from @import to enqueued stylesheets. I went into more detail in my reasoning here.

Regarding support, yes, it works in 4.5.x. I thought I’d bumped the version, but evidently not. I’ll update that in the next day or two. Thanks for bringing this to my attention.

Check out the codex page on installing plugins: https://codex.www.ads-software.com/Managing_Plugins#Installing_Plugins

I can’t debug your hosting for you. This doesn’t have anything to do with my plugin, since it doesn’t handle deleting itself, WordPress does.

Generally, when you can’t delete a plugin, though, it’s usually because whatever user is trying to do the deleting doesn’t have permission to do so. Check who owns the files and make sure you’re trying to delete it as that user.

Generally, when files stop showing up in a child theme, it’s because the parent theme is using get_stylesheet_directory() and get_stylesheet_directory_uri() instead of get_template_directory() and get_template_directory_uri().

Any file you wish to add to the child theme can simply be copied over from the parent theme (presumably using an FTP client).

Copy the file from the parent theme into your child theme (presumably using an FTP client).

Cool plugin, by the way. Just stopped by on a friend’s recommendation and thought I’d chime in. ??

I’m not sure exactly why bedrock isn’t working with plugins_url(), but I’d imagine it has something to do with the non-standard way plugins_url() is being used here. In order to maintain compatibility with the various possible plugin directory setups, you’d normally use it like this:

// First argument is path relative to your plugin file
// Second argument is the absolute path to your plugin file
plugins_url( '', __FILE__ );

That runs your plugin file through plugin_basename(), which will account for all possible plugin directory setups.

?? I’m glad to hear you figured out the issue.

Hi Starr15,

Could you please provide me with a screenshot of the issue you’re having, as well as the version of Child Themify you are using?

Thanks!

Hi green_bug,

Grandchild themes aren’t supported by WordPress, so Child Themify doesn’t expose any UI for themes that are already child themes. I’m not sure if there’s an existing solution for getting grandchild themes to work with WordPress, but either way, this isn’t something this plugin can support.

This is outside of the scope of this plugin’s support. I suggest opening another thread on the forum and seeing if you can get support that way. If you’re still unsure about how to do what you need to do, perhaps hiring a freelance developer to make the changes for you would be the best route to take.

From the child theme documentation page (emphasis mine):

If you want to change more than just the stylesheet, your child theme can override any file in the parent theme: simply include a file of the same name in the child theme directory, and it will override the equivalent file in the parent theme directory when your site loads. For instance, if you want to change the PHP code for the site header, you can include a header.php in your child theme’s directory, and that file will be used instead of the parent theme’s header.php.

The table structure is identical and uses the same name. All functionality is ignored if WordPress has already defined term meta functions. There shouldn’t be any migration necessary, since this is basically the same implementation as in core (JJJ, feel free to correct me on this).

On the theme screen you need to click the thumbnail of the theme you want to use. It will show up in the row of buttons at the bottom of the modal window that pops up.

Let me know if you’re still having trouble finding it.