Forum Replies Created

Viewing 15 replies - 1 through 15 (of 18 total)
  • I agree with that. People are used to copy a shortcode and simply paste it everywhere. Usually that works as the shortcode does not contain markup. That old behavior was a good feature.

    We seemed to have exactly the same problem. But after trying some things (and before rolling back to the previous version) we found out: The editor/user had mixed up html and text. We had the <p> in the visual editor but a &lt;p&gt; in the text-editor.
    This is weird as that contents havent been changed for months and the problem occured right after updating the plugin.
    My idea: The old version of the plugin automatically corrected that wrong escaping of the HTML and the new version doesnt do that anymore.
    You might wanna check your editor too.

    Thread Starter bodokade

    (@bodokade)

    Hello Anthony,

    thx for your reply. I like the constructive way you deal with feedbacks.

    You’re right: we dont use a cache-plugin yet. Its a rather slim website with just few plugins and no other optimizations yet. That makes the relative impact of your plugin that high.

    Which js/css cache do you use?

    Kind regards
    bodo

    bodokade

    (@bodokade)

    Hallo George,

    i’ve registered at transifex and requested a german translation. Is it you to approve/allow me to do the translation? I do not see anything to translate yet.

    Greetings

    bodokade

    (@bodokade)

    Hello George!

    If you can tell me how it is done I’ll do a german translation of your plugin. Maybe vor version 2.4?

    Greetings
    Bodo

    You have plenty calls to get_queried_object() and to get_post_type(). Not just one. Is it enough to chance one?

    I’d rather suggest a my_get_queried_object() which returns either get_queried_object() oder – if not set – global $post.

    Yes, I’ll give the new version a try. Inform me as you’r done.

    Good night ??

    Adding is_home() seems to solve the one problem but i’m sure I’d encounter new ones later.

    I also thought about setting the query-object manually by calling

    $wp_query->queried_object = $post;

    but this could have side-effects at many places – bad idea.

    Instead I replaced all your calls to get_post_type() by my own theme_my_get_post_type() and implemented this as:

    function theme_my_get_post_type( $xPost ) {
    
        global $post;
    
        if ( empty( $post ) ) {
             $xPost    =   $post;
        }
    
        return get_post_type( $post );
    
    }

    This works fine and solve exactly the reason without changing the logics of your plugin.

    Best wishes!

    Hello George!

    My problems rely on my old wordpress-version 3.4.2. We are still using this version because we have dozens of websites running on it and cannot chance the version without adapting all the themes, own plugins etc.

    In the old version get_post_type() return false. The new version uses global $post if an empty post is passed and therefore has a valid post to get the type for.

    I’m sorry I did not mention this earlier. As the problem could by solved by a simple addition of is_home() I did not expect this to be a version conflict.

    Thanks for your help and sorry for the miss-information.

    Grettings

    Bodo

    It works in my clean version only. The project where the problem occurs originally still does not work. But I understand that you cannot do research for a problem you cannot reproduce.

    Did I understand you right: If your $post is null then get_post_type() returns ‘post’? Mine returns false.

    Does it work with the twentyeleven without touching the code? Don’t bother with get_queried_object().

    Grrrrr (-:

    3.7.1., Twenty Thirteen, installing plugin…, activating plugin, setting starting page to last posts, checking plugins settings: both markers for Automatically generate… are set, setting frontpage description to “TEST DESCRIPTION” saving settings… reloading website, opening source – damn it’s there!!!

    <!– BEGIN Metadata added by Add-Meta-Tags WordPress plugin –>
    <meta name=”description” content=”TEST DESCRIPTION” />
    <meta name=”keywords” content=”testwas” />
    <!– END Metadata added by Add-Meta-Tags WordPress plugin –>

    And

    var_dump( get_queried_object() );

    still return null.

    Ah! Plugin Version is 2.3.7. The version i loaded this morning is 2.3.6. What did you change?

    I’ve used a clean wordpress now: Latest version 3.7.1 and latest version of Twenty Thirteen. If I add

    var_dump( get_queried_object() );

    to the beginning of header.php and turn the starting-page to “last posts”, the output ist null. This is the problem as your plugin does not have post-objekt.

    If I set the starting-Page to a certain fix page, the data of the post is printed.

    I’ve changed to twenty-eleven and added

    var_dump( get_queried_object() );

    at the beginning of my header.php. The output ist

    null

    so your $post would be null and the thing cannot work.

    I’ll try another wordpress on another server now! ??

    Which settings to i need to enable? I’m running with the default settings of the plugin.

    You are right. The template tags do not work at all. They were completely untested.

    Yes, I used the tags. But the problem looks the same if the plugin does the insertion with the wp_head-action.
    =============================================
    function amt_add_metadata_head() {
    print “1 “;
    echo PHP_EOL . implode(PHP_EOL, amt_get_metadata_head()) . PHP_EOL . PHP_EOL;
    print “2 “;
    }
    add_action(‘wp_head’, ‘amt_add_metadata_head’, 0);
    ============================================

    results on my frontpage in:
    ============================================
    1

    2
    ============================================

    If I change your code by adding an is_home() (as said above) it works:

    ============================================
    1
    <!– BEGIN Metadata added by Add-Meta-Tags WordPress plugin –>
    <meta name=”description” content=”FRONMT APGE DESCIRTPTION” />
    <meta name=”keywords” content=”fronten dpage keyworfdss” />
    <!– END Metadata added by Add-Meta-Tags WordPress plugin –>

    2
    ============================================

    So what is the recommended way to use it?

    Hello!

    I can see it in german only. The selected radio button’s html ist:

    <input name=”show_on_front” type=”radio” value=”posts” class=”tog” checked=”checked”/>

    I think thats ‘latest posts page”

    There are no warnings or notices (I switched them ON) but just an empty-line-output. ALL functions of amt-template-tags.php have an empty-line-output.

    In my header.php there is:

    =============================
    <meta name=”viewport” content=”initial-scale=1.0,width=device-width,maximum-scale=1.0″>
    <?php
    amt_content_description();
    amt_content_keywords();
    amt_metadata_head();
    amt_metadata_footer();
    ##amt_metadata_review(); // error: Call to undefined function amt_get_metadata_inspect()
    ?>
    <title>123</title>
    =============================

    the generated html-code is:

    =============================
    <meta name=”viewport” content=”initial-scale=1.0,width=device-width,maximum-scale=1.0″>

    <title>123</title>
    =============================

    According to $post: The plugin does not use $post. It only uses get_queried_object(). There is no “global $post” and get_queried_object() also does not return the global $post.

Viewing 15 replies - 1 through 15 (of 18 total)