Forum Replies Created

Viewing 12 replies - 1 through 12 (of 12 total)
  • Thread Starter herrstrietzel

    (@15broetchenmann)

    @Michael Beckwith: Thanks! You’re right! gosh … reading helps.

    In my case I had a slug conflict due to a custom post-type landing – which should be eliminated.

    I could also solve it by

    • temporarily changing the page slug of the page “team”
    • registering the post type “team” via cpt-UI
    • reverting the previously changed page slug
    Thread Starter herrstrietzel

    (@15broetchenmann)

    @tw2113 Thanks for your response!

    Unfortunately, this didn’t work.

    I’ve also tried to

    • log out
    • clear caches / permalinks etc
    • switch to a standard theme like twentyXX

    CPTUI was still throwing an error message like (translated as I’m using a german WP version)

    Please choose a different content type name. “team” matches an existing page title form, which can cause problems.

    So apparently CPTUI is very strict/cautious when it comes to existing post types – which is actually great!

    What actually solved the problem, was temporarily out commenting some lines in the “post-types.php”

        if ( true === $slug_exists ) {
    
            add_filter( 'cptui_custom_error_message', 'cptui_slug_matches_post_type' );
    
            return 'error';
    
        }
    
        if ( 'new' === $data['cpt_type_status'] ) {
    
            $slug_as_page = cptui_check_page_slugs( $data['cpt_custom_post_type']['name'] );
    
            if ( true === $slug_as_page ) {
    
                add_filter( 'cptui_custom_error_message', 'cptui_slug_matches_page' );
    
                return 'error';
    
            }
    
        }

    Disclaimer for other users:
    don’t hack plugin files!!!
    Don’t try this unless you’re working on a local server copy
    Always backup your DB before applying changes like this.

    So I highly appreciate CPTUI’s safety measures and my use case is barely relevant for the majority of users.

    However, it might be a great option to actually allow adding already existing post-types via an additional checkbox/confirmation.

    Thread Starter herrstrietzel

    (@15broetchenmann)

    Aaah!

    adding the global definitions in my template file solved the problem

    	global $pdf_margin_left;
    	global $pdf_margin_right;
    	global $pdf_margin_top;
    	global $pdf_margin_bottom;
    	global $pdf_margin_header;
    	global $pdf_margin_footer;
    

    But I’d also like to use the css @page method if possible.
    Regards,
    Patrick

    Hi Selimoyan,

    your example has a lot of table structure and a lot of inline styles from woocommerce.
    Do you really experience a significant difference between ssl and http?
    My first bet would be disabling the “Adds wp_head() in PDF head” as it might include a big overhead of stylesheet data.

    It’s a known issue that mpdf library is not the fastest in particular when it comes to rendering tables. That’s mainly due to the fact that it tries to interpret css more precisely than other libraries, thus very complex stylesheets can slow down the rendering process significantly.

    herrstrietzel

    (@15broetchenmann)

    Hi Penderworth,
    this is an annoying bug caused by the new (wp 4.4) responsive images feature (which is of course a great improvement).

    For some reason it has issues with image classes:
    1. Option: Try to disable the responsive image feature by adding this snippet to your function.php

    function disable_srcset( $sources ) {
    return false;
    }
    add_filter( 'wp_calculate_image_srcset', 'disable_srcset' );

    2. Option: Remove classes from thumbnail sized image elements:

    /*remove class from the_post_thumbnail*/
    
    function the_post_thumbnail_remove_class($output) {
    	$output = preg_replace('/class=".*?"/', '', $output);
    	return $output;
    }
    add_filter('post_thumbnail_html', 'the_post_thumbnail_remove_class');

    3. Option: Manually search for inserted images with classes assigned.
    In my case it were particularly the “wp-image-123x” classes.

    Try to delete any image class i.e. in your post:
    https://thesheetnews.com/2016/01/29/death-valley-blooms-early/

    Is the error message still showing up?

    Thanks for this advice.

    But you should not edit the plugin’s file “class-fee.php” as your changes will get overwritten when updating the plugin.

    Just add these lines to your function.php.

    /* front end editing in custom post-types */
    add_post_type_support( 'mycustomposttype', 'front-end-editor' );
    Thread Starter herrstrietzel

    (@15broetchenmann)

    Hi Curtiss,

    Thank you so much! Your code did it!

    Hi John,

    also works in this constellation:
    – qtranslate 3.2.9.9.4
    – Advanced Custom Fields 4.4.1
    – WPBakery Visual Composer & qTranslate-X

    My problem was I could not save the content in my custom field (advanced custom field).
    I’d recommend to publish the alpha soon as it offers some nice features.

    thanks!

    Hi sebastianpierre,

    it’s not a question of whether you need tinymce as it is the default wysiwyg/rich-text editor.

    So the conflict described above usually occurs when your wordpress posts use custom fields with wysiwyg/rich-text editor in conjunction with mqtranslate.

    That’s mainly because both tinymce and mqtranslate heavily manipulate the wordpress content textarea by javascript and can interfere with each other.

    … tinymce and qtranslate … the never ending story …

    as I switched to WordPress 4.0 and mqtranslate Version: 2.7.1.1
    and I got it fixed by replacing
    (about line 305):

    if ( ed.getParam( 'wpautop', true ) )
    e.content = switchEditors.pre_wpautop(e.content);
    qtrans_save(e.content);

    with

    if (ed.id.match(/^qtrans_/)) {
    qtrans_save(switchEditors.pre_wpautop(e.content));
    }

    This Hack worked for me without using “ACF qTranslate”(intended to translate advanced custom fields) and both with tiny mce advanced and wp-edit (the successor of “ultimate tiny mce”).

    If you are new to qtranslate/mqtranslate, my advice is to check the “achilles heel” of qtranslate:
    It has always been the conjunction of qtranslate tabs with additional wysiwyg instances (in fact tinymce instances) such as custom fields.

    So if you encounter any problems the most likely place to search for is the “m/qtranslate_javascrip.php” in your plugin directory.

    herrstrietzel

    (@15broetchenmann)

    Hi Saikes,

    I have the same problem but I can’t figure out how to make it work.

    It only prevents bookings if the mail address already exists for a registered user. For non registered Users in No-user Mode it still can’t find previous booking with the same address for a particular event.

    Any Ideas?
    Kind regards

    Thread Starter herrstrietzel

    (@15broetchenmann)

    I finally found a solution. You could also use this for other kinds of custom fields.

    $pdf_output .= 'get_post_meta($post->ID, 'CustomFieldname', true);

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