mickeykay / better-font-awesome-library Goto Github PK

I have a post type where I would like to use the same Font Awesome icon picker for some custom meta fields. Everything is working nicely, except that I end up conflicting with Better Font Awesome.

I found the bfa_init_args filter, but it's loaded so early that functions such as get_current_screen() return null, so I'm unable to remove the media button only from a certain post type editor screen.

On the one hand, I would like to be able to use the filter, but my real issue is that I want to use both the media button and the custom fields. At this point, any time any instance of the iconpicker library select is clicked, the value and shortcode is inserted into the editor, even if the iconpicker isn't from the plugin media button. I've tested locally and found that if your icon insertion is modified to work only from the media button, we can coexist happily. This modification is working for me:

		// Set up icon insertion functionality.
		$( document ).on( 'iconpickerSelect', function ( e ) {
			if ( ! e.target.attributes.class.value.includes( 'bfa-iconpicker' ) ) {
				return;
			}
			wp.media.editor.insert( icon_shortcode( e.iconpickerItem.context.title.replace( '.', '' ) ) );
		} );

I'd be happy to submit a PR for this script change, as I would love to be able to use both instances of the icon picker. Thank you for an awesome plugin!

If you look at https://github.com/FortAwesome/Font-Awesome/blob/master/UPGRADING.md#550-to-560 you'll see that the CDN assets have moved since this library was last updated. Instead of the icons.yml file being located in advanced-options/metadata/icons.yml it's now located at metadata/icons.yml, which is causing this library not to be able to locate the icon data.

As far as I can tell, the only change that needs to be made is to modify https://github.com/MickeyKay/better-font-awesome-library/blob/master/better-font-awesome-library.php#L70 from:

	const JSDELIVR_ICON_METADATA_FILE_PATH = '/advanced-options/metadata/icons.yml';

to:

	const JSDELIVR_ICON_METADATA_FILE_PATH = '/metadata/icons.yml';

Thanks.

When using the bfa_fallback_directory_path filter in private function setup_fallback_data(), it is possible to specify an own fallback Font Awesome directory. Works fine, extracts the version from a supplied package.json, adds it to URL, etc.

But the URL to stylesheet still links to default fallback, no filter available for this.

Suggested fix, replace this:

        $this->fallback_data['url'] = $this->root_url . $this->fallback_data['directory'] . 'css/font-awesome' . $this->get_min_suffix() . '.css';

With this:

        $directory_uri = $this->root_url . $this->fallback_data['directory'];
        $directory_uri = trailingslashit( apply_filters( 'bfa_fallback_directory_uri', $directory_uri ) );
        $this->fallback_data['url'] = $directory_uri . 'css/font-awesome' . $this->get_min_suffix() . '.css';

This adds new filter bfa_fallback_directory_uri which then can be used in addition to above filter to supply the correct URL to stylesheet.

Hi,

Thanks for a great plugin.

How do you include the better font awesome library in a custom wordpress theme as I've followed the instructions in the readme but nothing is happening, i.e No tinymce button, etc.

Currently inside the Better_Font_Awesome_Library class there is a function setup_root_url() that determines the URL to use for enqueueing the admin JS and CSS files. This function calls the WordPress functions get_stylesheet_directory() and get_stylesheet_directory_uri(), which return different values when used in a parent theme vs. a child theme.

This issue is tricky because technically a theme only becomes a parent theme when it is child themed, and until it is child themed the get_stylesheet_* functions work great, but when a child theme is used the get_stylesheet_* functions refer to the child theme while the get_template_* functions refer to the parent theme.

I've updated the logic for the setup_root_url() function in a recent project to:

/**
 * Set up root URL for library, which differs for plugins vs. themes.
 *
 * @since  1.0.4
 */
function setup_root_url() {

    // Get BFA directory and theme root directory paths.
    $bfa_directory = dirname(__FILE__);
    $theme_directory = get_template_directory();
    $child_theme_directory = get_stylesheet_directory();
    $plugin_dir = plugin_dir_url( __FILE__ );

    /**
     * Check if we're inside a theme or plugin.
     *
     * If we're in a theme, than plugin_dir_url() will return a
     * funky URL that includes the actual file path (e.g.
     * /srv/www/site_name/wp-content/...)
     */
    $is_theme = false;
    if ( strpos( $plugin_dir, $bfa_directory ) !== false ) {
        $is_theme = true;
    }

    // First check if we're inside a theme.
    if ( $is_theme ) {

        // Use appropriate file paths for parent themes and child themes.
        if ( strpos( $bfa_directory, $theme_directory ) !== false ) {

            // Get relative BFA directory by removing theme root directory path.
            $bfa_rel_path = str_replace( $theme_directory, '', $bfa_directory );
            $this->root_url = trailingslashit( get_template_directory_uri() . $bfa_rel_path );

        } else {

            $bfa_rel_path = str_replace( $child_theme_directory, '', $bfa_directory );
            $this->root_url = trailingslashit( get_stylesheet_directory_uri() . $bfa_rel_path );

        }

    } else { // Otherwise we're inside a plugin.

        $this->root_url = trailingslashit( plugin_dir_url( __FILE__ ) );

    }

}

This code is working for me in the following situations: BFAL being in a theme by itself, BFA being in a parent theme, and BFAL being in a child theme where the parent doesn't include BFAL.

Any chance you can consider making this change or a similar change in BFAL? I'm happy to submit a PR also. I've only tested the new code in the cases I mentioned but I'm thinking it should work across the board.

No map-marker-alt

any plans on adding font awesome 5?

Switch to a Grunt/Composer flow for including dependencies including:

• Font Awesome fallback