petskratt

Hi @strandhuette – could you share your solution?

Short-term solution is to replace this line:

list( $language, $territory ) = explode( ‘_’, $locale );

with:

$language = WPSEO_Utils::get_language( $locale );

There is a issue on github and also a pull request on the way…

This is https://github.com/Yoast/wordpress-seo/issues/8473 and has a pull-request with fix.

Short-term solution is to replace this line e-g:

list( $language, $territory ) = explode( ‘_’, $locale );

with:

$language = WPSEO_Utils::get_language( $locale );

Does not reproduce in my case (Postie 1.5.18, WP 3.8) – tried sending from Gmail, Outlook and smartphone, different JPEGs (edited in Photoshop, straight from Canon camera, some old pic from web), always works.

Please note, that your debug log has size empty, while mine looks like:

GetContent: primary= image, secondary = jpeg
DecodeBase64Part: base64 detected
GetContent: file name 'triibuline-pets.jpg'
GetContent: extension 'jpg'
GetContent: secondary lookup found image/jpeg
GetContent: mimetype image/jpeg
image Attachement: triibuline-pets.jpg
pre-sanitize name: triibuline-pets.jpg, size: 28731
post sanitize name: triibuline-pets.jpg
using post date
postie_handle_upload: detected file type for triibuline-pets.jpg is image/jpeg
wp_unique_filename: triibuline-pets.jpg
attachement id: 591
wp_generate_attachment_metadata
wp_update_attachment_metadata complete

You are absolutely correct – except in this case Trac ticket mentions exactly the same bug being fixed using same method… that is even listed in readme.txt, but somehow fixes in diff have not been merged into style.css, if you happen to know how to publish the fix several users would be immensly happy.

https://themes.trac.www.ads-software.com/changeset?old_path=/p2/1.4.1&new_path=/p2/1.4.2

btw make.www.ads-software.com/core uses 1.4.2-wpcom that does have this fix…

(yes I know the topic is “resolved” – but seems people keep finding this thread and might as well get the answer)

This appears to be a bug in P2 CSS (style.css) – other form elements have width (and max-width) 97.45% while #postbox input#posttitle and #postbox input#postcitation (and .inlineediting input[type=”text”] as well) have 97.6% getting resulting in 630.5px and 631.476px. Both should be rounded to 631px… but apparently browsers do it differently.

FIX – search style.css for 97.6% and replace with 97.45%

Yes, I know the rules. Been running forums since ’89.

Rule #1 – search first (did, found), Rule #2 start new topic unless you are 100% sure this is the same issue (I am, for both threads and the mentioned ticket)

The thread you closed (https://www.ads-software.com/support/topic/problems-with-heading-and-links-wordpress-35?replies=9) provided useful information and was updated by users with suggestions that helped me to provide temporary fix for client.

I am now following the one of the last rules and tagging this thread with modlook – please have another moderator solve our dispute off-forum, as otherways this will be last time I am to contribute here.

@esmi – you have already closed one similar topic without giving any real help and accusing people (who have described ways to reproduce the problem) of hijacking the topic, all I did was fulfill all your requests (by making a clean install) and report on being able to reproduce the problem.

But I agree that also I should have done more research before commenting – apparently this is a bug, there is a ticket https://core.trac.www.ads-software.com/ticket/22888 and the bug is fixed in 3.5.1 that is currently in beta (tested – problem is solved).

So while it is NOT good idea to use beta versions on live sites – updating to nightly build (manually or using https://www.ads-software.com/extend/plugins/wordpress-beta-tester/) fixes the problem.

same problem:

did clean WP 3.5 install, used the sample page to enter five paragraphs (each one word), made 2nd and 4th paragraph H3 and then linked them, switched to text view and back – links are gone, replaced with  

Appears the bug is related to usernames (the one that is used for login and can’t be changed in Users panel) containing space, eg “John Doe” fails vs “JohnDoe” works fine – tried with editing usernames via phpMyAdmin and it really seems to be what breaks it…

We shall hope that the author of this fine plugin finds this hint useful and can fix whatever got broken during tons of changes on the way from 2.1.1 to 2.5 ??

@evandavidpaul – perhaps importing changed the usernames? never checked, but new users do get created from post authors and could well have spaces, considering posts were made with real names

there is a bug – most probably a forgotten line from some debugging session – that prevents .htaccess redirection from being configured

edit /modules/htaccess.php, find the line 268 that has die(“SAVING HTACCESS”); and comment it out (or delete), so the result should be like that:

function save ($filename, $name)
{
  // die("SAVING HTACCESS");
  $text = $this->generate ($name);

that used to be bug #871 on old tracker… so thanks to whoever fixed it first ??