Forum Replies Created

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter The Merovingian

    (@the-merovingian)

    Using ‘he_IL’ (Hebrew).

    I should add that currently I’m using a permanent fix to this problem –

    I simply replaced the original “TC_init->tc_active_skin()” function in “parts/class-fire-init.php”, like such:

    1) I’ve created a “tc_active_skin_FIXED()” function in my child-theme’s functions.php file. this function is based on the original “tc_active_skin()” with a few changes fixing the bug in this discussion.

    2) I’ve then created a “editor_style_child()” function to re-register editor styles using the corrected active skin function mentioned above.

    3) I’ve created a “wp_enqueue_scripts_child()” to re-register & re-enqueue the ‘customizr-skin’ using the same corrected active skin function.

    4) I’ve used “add_action()” to hook “wp_enqueue_scripts_child()” to “wp_enqueue_scripts” (priority=100), and to hook “editor_style_child()” to “after_setup_theme” (MUST use priority=20).

    Here is a draft of the 2 new functions mentions in section 2,3 :

    /**
     * re-register editor-styles and add the fixed tc_active_skin_FIXED()
     */
    function editor_style_child() {
    	$success = remove_editor_styles();
    	if ($success) {
    		add_editor_style( array( TC_BASE_URL.'inc/admin/css/editor-style.css',
    						$this -> tc_active_skin_FIXED() ,
    						get_stylesheet_uri() ,
    						TC_BASE_URL_CHILD.'editor-style-child.css'
    		) );
    	}
    }
    
    function wp_enqueue_scripts_child() {
    	// ------------------------------------------------------------------------------------------------------------------
    	// replace tc_active_skin() invoked in "parts/class-fire-resources.php: TC_resources->tc_enqueue_customizr_styles()"
    	// ------------------------------------------------------------------------------------------------------------------
    
    	// remove css + un-register so we can re-register under same handle name 'customizr-skin'.
    
    	if ( wp_style_is( 'customizr-skin' , $list = 'enqueued' ) )
    		wp_dequeue_style( 'customizr-skin' );
    
    	if ( wp_style_is( 'customizr-skin' , $list = 'registered' ) )
    			wp_deregister_style( 'customizr-skin' );
    
    	// re-register & re-queue new function
    
    	wp_register_style( 'customizr-skin' , $this -> tc_active_skin_FIXED(), array(), CUSTOMIZR_VER, $media = 'all' );
    	wp_enqueue_style( 'customizr-skin' );
    }

    I won’t share the full code since it might seem a bit too convoluted and confusing. But if someone insists, i’ll post it.

    Thread Starter The Merovingian

    (@the-merovingian)

    Update:

    I’ve been using an import code (example below) in the css files of my child theme’s “inc/css/rtl” folder, which eliminates the problem I mentioned, and automatically imports the new css files after an update in the main theme.

    I still need a better way to do this, I was unsuccessful in using the functions.php of my child theme to override the buggy “tc_active_skin” function.

    here is what I currently for the “customizr-child/inc/css/rtl/blue.css” file:
    @import url("../../../../customizr/inc/css/rtl/blue.css");

    I have not encountered this bug on my WP site. However using ‘admin_init’ correctly hides the Jetpack menu items, but ‘admin_menu’ does NOT.

    My 2 cents:

    I have the same problem.
    In my case, my avatar is reset to the “empty” gravatar every time I delete an attachment (any image, not the avatar ofcourse) through the Media control panel.

    I’ve noticed that when you add an avatar, 7 files are created on the server – the original image, and 6 square scaled images:
    150, 150-2x, 96, 64, 32, 26
    the 150 & 150-2x are standard (150px size & 150px with x2 pixel density if i’m not mistaking). the other 4 are not.

    On deletion of an image, other than the avatar itself, the avatar’s 4 NON-standard sizes are deleted too, leaving only the 3 standard ones.

    This probably means that the plugin’s code is not registering those 4 non-standard images as part of the attachment’s scaled images, so when you delete an arbitrary image from your library, the wp_delete_attachment() function probably considers those 4 images to be some sort of temporary files, and deletes them too.

    I have years of experience with PHP language, but I’m not well versed in the plugin’s PHP code, nor WP code. So for now I cannot offer a solution or a bugfix.

    Hope this helps.

Viewing 4 replies - 1 through 4 (of 4 total)