topsoftbe

OK, this is a typical case of developers who think they are so good that any criticism is like a blasphemy. I understand perfectly well what mariusfv is worried about. But just because the developers feel like been criticized, they become deaf and blind to what he is trying to say.
So let me try to clarify the situation:
– What he says about plugins is true: lots of amateurs are creating all kinds of plugins. They sometimes work great, they sometimes are just what you need. And then the person who wrote the plugin gets married, get kids, abandons the plugin and there you are…
– The argument of the developers about plugins, that they are necessary to avoid WP becoming bloated is absolutely correct. It’s thanks to plugins that very specific demands and problems can be met and solved.

So, back to the problem of privacy: maybe this is too important to leave it to some guy somewhere who will write a splendid plugin that makes WP compliant to the European legislation about privacy or something like that and then, after a few years, abandons the plugin and leaves the users with a website that does not comply anymore.

Maybe there should be a special category of plugins, not developed by some nerd in his spare time, but by the same people who develop the core, so that users can be certain that whatever changes are made to the core, these fundamental plugins will always remain up-to-date, supported and available. Maybe incorporated into JetPack, or something like that. Or maybe create a “BasePack” with plugins that are really important, not to everybody, but to an important majority. Plugins that deal with privacy, encryption, security, that kind of stuff. Things that are so important that you need to be sure, when using them, that they will always be supported and updated.

Because you will have to admit, volunteers are great, they have done wonderful things, but being around for year after year is not their strongest point. That is not a criticism, it’s just simply the truth. not all great plugins are written by established companies. And you can not expect that a simple mortal individual who once developed a great piece of code, will be condemned to support it to his dying day.

After reading the comments on the original posts, I guess I will only receive negative reactions. So be it.

I found the culprit, it has nothing to do with EWWW, it was a workaround from a plug-in “add meta tags”. They had a compatibility problem with JetPack and added the following code:

function amt_workaround_og_tags( $metatags ) {
    // Remove og:image:width & og:image:height OG metatags
    $metatags = array_filter($metatags, "amt_filter_og_tags");
    return $metatags;
}
add_filter( 'amt_opengraph_metadata_head', 'amt_workaround_og_tags', 10, 1 );

function amt_generate_extended_image_tags( $default ) {
    return false;
}
add_filter( 'amt_extended_image_tags', 'amt_generate_extended_image_tags', 10, 1 );

I deleted the code and EWWW works again flawlessly.

Thanks,
Everything is working OK.

I have just created a new blog, called test, with only akismet and wp2flickr as plugins and using the twenty fourteen theme.
I added one post with just one picture.
The pic got uploaded to flickr and was in the correct group.

I then created a second post, with 2 pictures and a featured picture, only one picture got uploaded, but maybe that’s the way you programmed it.

So the plugin is working correctly in this configuration.
I will now add all my normal plugins one by one until it stops working.
Also, I will change the theme to my standard theme.
I will keep you informed about the results.

I checked the database and the logfile.
This is what I found:

Logfile:
2014-12-16 16:46:14 – insert into art_wp2flickr ( post_id ) select ID from art_posts where post_status=’publish’ and id not in ( select post_id from art_wp2flickr )

2014-12-16 16:53:03 –
2014-12-16 16:53:03 – Error uploading [path and filename of picture]
2014-12-16 16:53:03 – error code:
2014-12-16 16:53:03 – error message:
2014-12-16 16:53:26 –
2014-12-16 16:53:26 – Error uploading [path and filename of picture]
2014-12-16 16:53:26 – error code:
2014-12-16 16:53:26 – error message:

Database: I found nearly 500 records:

Post_id: with incremental numbers starting at 5, ending at 4251
yapb_id: always 0
flickr_photo_id: always 0

The post I posted had one picture in the body and one (the same) featured image.

But…

The image in the art_posts table has not a status of “publish” but a status of “inherited”.

I have deleted all the bogus entries in the art_wp2flickr table and will try again.

I tried again, but still no luck.

There’s one (720×500) image (95 KB) in the post and as featured image.

Nothing gets uploaded, but test picture loads without a problem.

Can you tell a bit more about your WP config? What theme do you use and what plugins do you have? Maybe the plugin looks at the wrong place for the image or maybe there’s a conflict with another plugin.

I use JetPack and the uploads to Google, Tumblr, Twitter and LinkedIn all work without a problem, not only the picture but also the title and excerpt get uploaded. It’s just the Flickr plugin that doesn’t do anything at all.

That is what I thought, so it was strange that my server died while editing my post (simply uploading a picture) with the plugin activated.
The picture was 379 KB.
Anyway, I will try again tomorrow and keep you informed.

I tested it today. Installation went OK, I had to enter the code manually but the test picture uploaded successfully.
I created a new post, but each time I tried to upload a picture into the post, the connection to the server was broken and I had to restart apache and mysql.
I then deactivated the plugin and I could upload the same picture into the same post without any problem.
I have now uninstalled and deleted the plugin.

Update: Facebook and Google+ are working OK now. Tumblr and Twitter don’t work anymore however. Because I’m not sure if this has anything to do with meta tags, I will contact the JetPack people first.
I’ll let you know if something new comes up. Thks for your help.

mmm, it’s not easy to understand where the problem lies.
First of all, I added your two functions to functions.php.

Then I disabled Photon in Jetpack. That’s the Jetpack function that makes my pictures being served from the WordPress CDN. Just to be on the safe side, as you said, this would not cause problems.

Then I also disabled WP Super Cache, to make sure that no old, stale information is sent to FB. I had to delete the instructions in .htaccess in order to completely disable the cache.

Finally, I uploaded 3 posts, they all were posted on Facebook.

Then I activated Photon again (the CDN activating module) and posted 3 more articles.

They all posted on facebook instantaniously.

The most important test was of course WP Super Cache. I reinstalled the plugin from scratch, then activated and configured it.

I again posted 3 articles.
The first one was posted to facebook. I then activated the “preload” function in WP Super Cache, which means that all my posts will be static cached and served from there.
The subsequent posts were all on Facebook.

So I guess you found and fixed the problem.
I will use it like this for a few days and will come back to you on Monday. If it is still working, then you will have well deserved your cup of coffee.
I will keep you informed and thank you for the great help.

Thanks for your quick reply.
The images are inserted in the posts the normal way: I write the article, click on “Add Media”, drag and drop he picture in the Library, add the Alt tag and the Description, Then the picture is uploaded, inserted in the post and I add the caption. This is what the code looks like:

<div class="imgCaption"><a href="https://www.rubben.be/articles/wp-content/uploads/2009/11/Altered-Oceans-Part-Four-Plastic-Sea-02.jpg"><img src="https://www.rubben.be/articles/wp-content/uploads/2009/11/Altered-Oceans-Part-Four-Plastic-Sea-02.jpg" alt="Spinner dolphin" width="700" height="482" class="aligncenter size-full wp-image-6040" />Spinner dolphin</a></div><p>&nbsp;</p>

As you can see, height and with are not empty. But when I look at the page source in Firefox I see this for the pictures:

wp-content/uploads/2009/11/Altered-Oceans-Part-Four-Plastic-Sea-16.jpg?resize=700%2C482

Maybe that’s the reason? I use Hueman, which is a responsive theme.

What you said about the URL being different in the debug tool, I suppose you don’t remember what it was? Could it be because of me using WP Super Cache? Anyway, that can’t be the reason why FB does not accept the post, because I tried to post with all my plugins ctivated, except for add_meta_tags, and then I have no problems.

Are there some things I can test to help you find a solution?

(I started another thread this morning, please disregard that one).

sorry, forgot to click on resolved.

It seems that this is not the best place to get an answer to a technical question.
Anyway, for who’s interested, I solved my problem.
I have uninstalled Jetpack once again, but now I have also looked into the options table and there were a lot of Jetpack related records remaining.
I deleted them all, reinstalled Jetpack, reconnected to facebook and the other services (google, pinterest etc) and this time the reconnection worked.
I still have no idea why the problem occured but maybe all the other people who suffered from the same problem (Jetpack not posting to facebook) should try to clean up the mess that Jetpack leaves behind after uninstalling before trying to reinstall.

I now have an extra error:
Jetpack: [auth_failed] Authorization header was malformed
Still not working and still unable to reconnect to facebook.

here’s a list of my active plug-ins.
admin-post-navigation
akismet
ewww-image-optimizer
fancier-author-box
firestats
pro (part of firestats)
link-manager
opml-importer
post-editor-buttons-fork
sitemap-generator
widget-settings-importexport
wordpress-importer
wp-optimize
wp-pagenavi
wp-super-cache
wp-user-avatar
youtube-embed-plus
jetpack