Forum Replies Created

Viewing 5 replies - 31 through 35 (of 35 total)
  • Thread Starter inceweb

    (@inceweb)

    Thank you for the prompt reply. I can confirm that rolling back to version 2.0.13 does indeed solve the problem.

    pixeljunky,
    It sounds like you have invalid syntax in your funtions.php – you could try posting it here so we can look.
    If I had to guess, I would say that you have pasted the code after the final “?>” in the file – it must be in front of it, otherwise the PHP will not be interpreted.

    For example:

    <?php
    /**
    * Enqueues child theme stylesheet, loading first the parent theme stylesheet.
    */
    function hemingway_child_load_style() {
    if ( ! is_admin() ) {
    wp_register_style( ‘hemingway_style’, get_template_directory_uri() . ‘/style.css’ );
    wp_enqueue_style( ‘hemingway_child_style’, get_stylesheet_uri(), array( ‘hemingway_style’ ) );
    }
    }
    add_action( ‘wp_print_styles’, ‘hemingway_child_load_style’ );
    ?>

    Many thanks, Anders – I’ve updated our child theme’s functions.php as recommended, removed the edit I had made to the Hemingway functions.php and it is all working perfectly.

    I guess I have a blindspot for anything called readme.txt 🙂

    Thanks again.

    For the benefit of others reading this, amending the child’s functions.php in this way ensures that the Hemingway style.css is loaded immediately followed by the child’s style.css, so we can fully customise the theme without worrying about Hemingway updates overwriting our changes.

    This is different to the code provided in the WordPress Codex for child themes.

    Me too. Issue is incorrectly marked as resolved, OP actually extended their CSS to workaround.
    The issue first appears in version 1.57 which is why foomep’s site (and ours) works ok with v1.56
    There are a lot of changes between these versions, and unfortunatley the changelog.txt disappears at v1.57
    However, I have diff-ed a number of files and I think that the problem arises in functions.php at line 89. If I revert:
    wp_enqueue_style( ‘hemingway_style’, get_template_directory_uri() . ‘/style.css’ );
    back to:
    wp_enqueue_style( ‘hemingway_style’, get_stylesheet_uri() );
    the child theme CSS is correctly loaded.
    I’m not saying that this is necessarily the solution, but the problem definitely relates to the child style.css not being correctly enqueued.

    bookchiq is correct – this is still a bug in 2.2.2
    The problem arises when the user clicks “Add custom field” before a page has been saved using the “Save and continue editing” or “Save” buttons or the autosave.
    As described by HopkinsProg above, a post is created instead of a page, and the page content including custom fields is lost.
    I suspect that the fix would be to force the save action when the “Add custom field” button is clicked, somewhere in admin-functions.php
    The workaround, as described above, is to save the page before trying to add custom fields.

Viewing 5 replies - 31 through 35 (of 35 total)