Forum Replies Created

Viewing 8 replies - 1 through 8 (of 8 total)
  • I found the problem.

    If the content type is already set to “text/html”, then lines 288-290 of includes/wp-mail-api.php will set both the text and HTML message bodies to the same value.

    Line 260 has a comment “…and *attempt* to strip tags and provide a text/plain version.” but there never is any HTML-to-text conversion.

    Further, the clever trick (lines 259-275) of trying to save the content body to a temp file and sniff the content type that way (in the absence of an explicit content type) isn’t very useful.

    For me, the easy fix was to incorporate the html2text PHP library, then change lines 285-291 to:

    
        if( $content_type == 'text/html' )
        {
            $body['text'] = convert_html_to_text( $message );
            $body['html'] = $message;
        }
    

    I have just discovered the same problem, and it’s not specific to WooCommerce; it’s all email sent from the WordPress instance through the Mailgun plugin.

    While viewing the raw message, there are certainly two MIME types, Content-Type: text/plain; charset="ascii" and Content-Type: text/html; charset="ascii", both with the same HTML content.

    I am currently focusing on the includes/wp-mail-api.php file to see if I can determine the problem…

    Forum: Plugins
    In reply to: [WooCommerce] CSV Export

    Ugh, I hate when threads dead-end like this… @renamer, did you resolve this?

    I have the same problem, yet permissions on the server are absolutely correct. I can su to the web server user and touch and rm the file (using the exact path that’s displayed in the error message) without problems, so it doesn’t make sense why this plugin thinks it can’t. There are no messages in the PHP log, either.

    I experienced this, too. All posts containing a SoundCloud link stopped working.

    Upon further inspection, it seemed the wp_oembed_get() was somehow using the posts own URL rather than the SoundCloud URL.

    I hadn’t noticed that this may have happened after a WordPress upgrade (my hosting platform performs core upgrades automatically). So, when I found this thread, I decided to compare 4.5.3 embed.php with 4.5 embed.php (4.5, 4.5.1, and 4.5.2 were identical). The difference is the addition of wp_filter_pre_oembed_result(). So, this must be tripping on SoundCloud oEmbed responses somehow.

    To test, I regressed that addition by making wp_filter_pre_oembed_result() return immediately. This fixed the problem and SoundCloud embeds re-appeared.

    I’m still investigating, but thought I should post this much in case someone figured it faster than me.

    Solved my problem. I had a nimble_portfolio_lightbox_link_atts filter added to my theme’s functions.php so I could disable the lightbox.

    The documentation for removing the lightbox said to use this:

    add_filter('nimble_portfolio_lightbox_link_atts', 'handle_nimble_portfolio_lightbox_link_atts', 10, 2);
    function handle_nimble_portfolio_lightbox_link_atts($link_atts, $item) {
        $link_atts['href'] = get_permalink($item->ID);
        unset($link_atts['rel']);
        return $link_atts;
    }

    I changed it to this:

    add_filter('nimble_portfolio_lightbox_link_atts', 'handle_nimble_portfolio_lightbox_link_atts', 10, 2);
    function handle_nimble_portfolio_lightbox_link_atts($link_atts, $item) {
        $link_atts['href'] = '/our-clients/' . $item->post_name;
        unset($link_atts['rel']);
        return $link_atts;
    }

    Now, my index page had the correct permalink using the desired slug.

    Disabling the plugin, then re-enabling it caused the filter to take effect.

    Now, my portfolio posts have the permalink I want, but the index page still sets the href of each portfolio item to “/portfolio/[slug]” instead of “/what-i-want/[slug]”

    I’ve found where the links are rendered in skins/default/items.php. Now I’m backtracking the function calls to figure out where the “/portfolio” is being coded…

    I’m with Jason — I applied this hack to my functions.php as instructed, but nothing changed.

    Here’s a SQL script someone wrote, but it’s targetted for Drupal 6. However, it may not take much hacking to get the SQL script to use the right tables for Drupal 7.

    https://blog.room34.com/archives/4530

    I’ve been tinkering with it, but haven’t yet had success. We’ll see how far I get…

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