Nursing RSS Graffiti

RSS Graffiti 2.0

Wed, 01 Feb 2012 21:28:25 +0100

We have some big news to share: This month we will be rolling out RSS Graffiti 2.0. This will be a major update, containing improvements that will expand the power and usability of the application. With this release you can expect an increase in speed and greater control over how & where your feeds are published. The RSS Graffiti team has been hard at work on this update, and when you see what’s in store, we think you’ll be just as excited as we are.

We will begin rolling out RSS Graffiti 2.0 on a purely opt-in basis, during which time users can continue using 1.9.6 if they so desire. If you have any questions about the coming 2.0 update, please leave a comment on this post. As always, if you are having any trouble using the application, direct your support questions to our GetSatisfaction.com forum.

We are moving! (to a new fan page)

Thu, 19 Jan 2012 01:03:18 +0100

As Facebook’s deadline for phasing-out App Profile Pages approaches, we are about to migrate RSS Graffiti’s own App Profile Page to our new Fan Page.

The URL of our page will remain the same (http://facebook.com/RSS.Graffiti). Likes will also be migrated automatically so you won’t miss any important updates we will be sending out in the future.

This makes it the last post to appear on our old App Profile Page then! See you all, on our new Fan Page! Thanks to everyone for all the discussions and feedback we had on our App Profile’s wall and thanks for all the great reviews you’ve given us!

P.S: To migrate our feeds, we will be using our own new little migration feature, so if you are an App admin and didn’t do your migration yet, then you might want to try it.

Facebook is phasing out App Profile Pages. Here is how we can help you.

Tue, 17 Jan 2012 02:25:16 +0100

Facebook has recently announced that they are going to be removing App Profile Pages by February 1st, 2012. If you administer a Facebook Application, this is important news for you and probably you already know about this for several days or weeks now. If you need more info on this then you can look at Facebook’s own post here.

Now, we know that many of you use RSS Graffiti to publish your feeds on your App Profile Pages. Assuming that you are planning to create a new Fan Page to replace your old App Profile Page (many of you probably already did that), we thought it would be nice if we could lend you a helping hand (especially those last-minute-type-of-admins that need to hurry-up to meet the Feb 1st Facebook deadline). So we’ve put together a nice little utility option in RSS Graffiti to help you make the switch.

Here is how it works:

Let’s say you have a Facebook App called “Super App”. Let’s also say that you just created a new Fan Page named “Super App Fan Page” and assigned it to the Brand/App category. Finally, let’s say that you got 4 feeds added to your “Super App” App Profile Page in RSS Graffiti. Now you want to move those 4 feeds, out of the App Profile Page and into your new “Super App Fan Page”, so that your fans continue to get your news after you make the switch. But you don’t want to re-enter them in RSS Graffiti one by one. You’d love to just click a button, move them all over and be done with it.

To move the feeds without having to re-create every feed manually, you can now go to RSS Graffiti and select either your “Super App” App Profile Page or your “Super App Fan Page”. RSS Graffiti will -sort of magically- detect that you intend to move the feeds from the App Profile to the Fan Page and offer to do it for you.

The message it gives you is pretty self-explanatory for a Facebook App admin so there is not much point in explaining more here. It’s a yellow box that appears before your feeds. Your can’t miss it. If you have questions or doubts don’t hesitate to ask either in the comments of this post or (preferably) in our user support forum on GetSatisfaction.

Some words of caution: As soon as you click on the Migrate Button and confirm the operation on the pop-up dialog that will appear, your feeds will be removed from the App Profile Page immediately and will be added to your new Fan Page. RSS Graffiti will then start publishing them on your new Fan Page. We don’t provide you with a way to move them back to the App Profile Page. So only do it when you are ready for it.

For those who care about detail, here is a bit more on how we match Apps to Fan Pages:

If you navigate to the settings of a Fan Page in RSS Graffiti, then the app will check if the Fan Page is of the proper “Brand/App” category as required by Facebook. If it is, it will then look for any App Profile Pages that you own, which have a similar name with your Fan Page. If it finds at least one App Profile with a similar name, that also has at least one feed added in it, then RSS Graffiti will prompt you to move the feed(s) from one of your relevant App Profiles to the Fan Page.

Similarly if you navigate to an App Profile Page in RSS Graffiti, then the app will check if you also have any Fan Pages of the “Brand/App” category that have a similar name with your Application. If it finds any, it will prompt you to move your feeds there.

We hope this helps! We’ll migrate our own App Profile Page this way in a few days too…

A round-up on today's attack

Fri, 26 Aug 2011 01:59:43 +0200

Many of our users, (especially the ones using Google Chrome) have stumbled upon a puzzling warning message today while trying to access RSS Graffiti. The message was saying that RSS Graffiti is suspicious for distributing malware and that the user should not proceed in using the site.

For the curious -and for the record- here is what happened: Yesterday (August 24th) a new exploit was found for a WordPress theme framework. It so happened that we have purchased a theme based on that framework and we have been using it for our WordPress based site (http://www.rssgraffiti.com).

Unfortunately, shortly after the new exploit was found, someone had the opportunity to use the exploit and infect our WordPress site. This resulted in Google’s crawlers downloading the content, noticing the suspicious JavaScript and black-listing the site immediately. As a result everyone using Google Chrome was getting this red horror warning a few hours later.

Actually blacklisting our WordPress site and giving you that warning was a good thing from Google Chrome. It would be good for us too if they could just block access to the infected site. Unfortunately for us, instead of blocking only the suspicious site, Google blacklisted the entire rssgraffiti.com domain and so any server that was under our domain was causing the same warning to appear. Users were alarmed and everyone here was out of the meeting rooms (at last) and helping each other to find and fix the problem.

Our product site (http://www.rssgraffiti.com) is just another WordPress site. It is totally isolated from our data center. The issue that affected the WordPress site had no impact on the health of our systems. The processing engine and the entire RSS Graffiti service and infrastructure continued to work during this crisis unaffected. What blocked your access to these systems was this browser warning which was issued automatically for any of our servers regardless if they were suspicious or not.

So, after seeing the error reports many of you sent in today, Dimitris, Viral and Aleks got on top of it and pinpointed the cause of the issue. We found the hack and found the patch; then removed the hack and applied the patch. The site was fixed. Then we had to get Google to lift the ban. Ryan called all the right numbers and pulled all the strings he could pull to help this process go fast forward. So that’s done now too. I’m not sure if you can really pull any string at Google. I’ll ask Ryan later. :-)

Any lessons? How can a hack on a WordPress theme affect an entire service like this? Well, in case of Google and Google Chrome it turns out it can. Don’t get me wrong here; Google Chrome is my favorite browser. Nevertheless blacklisting the entire domain seems like an overkill too me. I don’t know. I’m not going to jump into conclusions here. This is over. We’ll try to to think what we can do on our side to minimize the chances anything like this happens again.

Thank you all for being so patient and supportive!

New Support Tab on our Facebook!

Thu, 28 Jul 2011 01:34:00 +0200

New Support Tab on our Facebook!:

Hello All!

First, we would like to thank you all once again for your patience during last week’s issue with saving your feeds. As you know, we are extremely dedicated to our users and want to make sure we can give you the best service possible and answer whatever questions you may have. With this in mind we have decided to upgrade our Get Satisfaction account to allow users quick access to ask questions, address issues, send us ideas, or simply comment on RSS Graffiti directly on Facebook. From this point forward you will be able to come to the RSS Graffiti home page and on the left hand side, click the Support tab to submit your inquiries directly. We hope this will make it easier for all of you as well as create a unified place for all of our users to get in touch with us.

Thanks!

Chris

Alright! We sailed and we failed...

Sat, 23 Jul 2011 01:10:33 +0200

That was an ugly one guys and it’s hard to apologize properly for it.

Here is what happened. Me and Dimitris moved to Luxembourg a couple of weeks ago. So yesterday, looking around through our database servers and debating new features, Dimitris noticed that there was an administrative account that was tied to my IP address in Sweden and said “We moved, didn’t we? I think we should now delete this one!” and I said “Yes please!”. So he deletes it.

Hours later we start seeing 1-star reviews on our Facebook Page. Five of them one after the other. I got worried but everything seemed to work fine so I thought it was just a bad coincidence and went to bed.

It turned out the next day, that not everything was working fine. Users were complaining that they could not add feeds on their pages. We tried but we could not reproduce the problem. All seemed fine. Later we realized that it was only newly added pages that had the issue. We created a new one and tested again. Voila! There was a problem. Big one! No new page had successfully been added to RSS Graffiti since yesterday!

Alright. We figured it out quickly and solved it. It was that user account we deleted. It turned out it was being used by a database trigger. Anyway. Let’s not get too technical here.

The point is we can’t apologize to all these users because we don’t even know who they are. Alright, I know, it’s not such a big deal; it’s only the new pages added for just one day that faced the issue. Ok. Still, it’s a stupid thing to do.

So please accept our apologies everyone. We only want to get better and it seems you can only get better by making mistakes right? As long as you don’t repeat the same mistakes all the time! So, we promise to stay put to Luxembourg for a few years. Alright?

Granting publish permissions to a Page causes "an unknown error occurred"

Wed, 06 Apr 2011 23:42:00 +0200

For those of you who get the “error an unknown error occurred” when trying to Grant permissions to your Fan Page, please perform the following steps.

1.) Go to http://www.facebook.com/pages/manage

2.) Find your Page that you want to add RSS Graffiti on and click Edit Page

3.) Go to the top Left Link (“Your Settings”)

4.) Check the first box: Posting Preferences: Always comment and post on your page as YOUR PAGE NAME even when using Facebook as YOUR OWN NAME.

5.) Click Save

6.) Go again to http://apps.facebook.com/rssgraffiti , click on your Page and try to provide the required permissions.

This should this time work Let us know if that helps
Dimitris for RSSGraffiti

Difficulties editing Fan Page / Group / Event / Application settings

Sun, 03 Apr 2011 16:17:00 +0200

PROBLEM

On my RSS Graffiti management page I click on the page that I want to update but when it refreshes the page I am back to the landing for the management page where I can add a feed for my personal profile. How can I edit my Fan Page /Group / Application settings?

FIX(temp)

This is a Facebook bug we are looing into. Till either Facebook Fixes that, or we implement a seemless workaround, use the following simpe trick:

1.) Click on the link to edit your Fan Page settings in RSSGraffiti.

2.) When the page reloads (not showing your Page/Group settings as expected but your Profile settings instead) simply press your Browser’s refresh button, or the F5 button in your keyboard. That should bring you to the correct destination.

Let us know if that helps

Fan Pages using new layout and Compact Style stories problem fixed.

Tue, 15 Mar 2011 01:44:34 +0100

Over the last weeks, after Facebook rolled out the new Page layout to all Fan Pages, we received your feedback, that the “Compact Style” posts did not get published correctly. The preview showed the format as previously, but the actual published post was only containing a single message, without any additional properties or the Share action link, just like Status Updates.

We managed to determine what is causing this behavior - actually what seems to be a Facebook bug - as well as a way to go around the issue and fix it.

What happens is that Facebook, when we are publishing to a New Page, treats posts slightly different than before. If there is no attachment description, (see here for the anatomy of a Facebook post) it discards all other information and simply posts a status update using the provided “message”.

What we implemented as a fix, is to send the publication date as the description instead of as just another Key-Value pair property of the attachment.

What this means for you and your feeds? The only noticeable difference will be that Published: {Date_Here} will appear first instead of last in your extended story info.

Before:

Read: Full story

Source: Source Name!

Published: 2011-03-14 22:33:53 GMT

After:

Published: 2011-03-14 22:33:53 GMT

Read: Full story

Source: Source Name!

When you preview your feed you will be able to see the exact way that the stories will appear on your wall as always.

So now you can use the Compact Style again in your new layout decorated Fan Pages. Thank you all for your valuable feedback!

Update on Short URLs issue

Wed, 26 Jan 2011 22:11:00 +0100

The issue that has been reported earlier today, causing posts to fail if they contained attachments with shortened or redirected URLs, is indeed a Facebook bug that affects every application that uses this feature.

In response to this issue we just deployed a workaround on our servers that will allow your posts to go through until Facebook fixes the issue. Now RSS Graffiti instead of shortening URLs it actually tries to expand (un-shorten) them. This effectively bypasses the Facebook issue.

At the moment of writing this, Facebook is also rolling-out a fix. We will keep our workaround in place until the fix by Facebook is confirmed.

For details on the bug see Bug 14832 on Facebook’s bug tracker.

Temporarily disabling URL shortening with Bit.ly

Wed, 26 Jan 2011 13:30:00 +0100

[UPDATE] This is a confirmed Facebook bug. We deployed a new work around. Read details here.

Many posts with attachments have been failing for the past several hours with the message:

Facebook responded with error 100: ‘attachment-href URL is not properly formatted’.

It turns out that Facebook is rejecting URLs shortened with bit.ly. This has happened also in the past, but Facebook had fixed the issue promptly. Our guess is that they will fix it again soon.

Nevertheless, as a temporary workaround, to unblock your posts from going through, we decided to bypass URL shortening with bit.ly.

We will keep monitoring the situation and keep you updated. We will re-enable bit.ly support after Facebook resolves this issue.

Temporarily disabling UI for Event Walls

Wed, 26 Jan 2011 03:10:40 +0100

Recently some users complained of getting a blank page while trying to access RSS Graffiti. With the help of one of our users we have been finally able to reproduce the problem and track down the cause.

I’ll get more technical about it later. Let me give you the bottom line first:

To solve this we have to disable the listing of your events on the left-hand column of RSS Graffiti.

What does this mean?

This means that you will not be able to see a list of your Facebook Events in the user interface and thus will not be able to click on any of them to add or edit your feeds for them.

Workaround

We will work on a workaround for this tomorrow and push it as soon as we can. In the mean time if you have added feeds on an Event and need to modify them please contact us at support@rssgraffiti.com, or leave a message on our Facebook Wall (http://facebook.com/rss.graffiti), or in our user support community (http://getsatisfaction.com/rssgraffiti) and we will help you make the modifications you need to do.

Is publishing on Event Wall affected?

No, publishing will continue normally for the feeds that you have already setup for your Facebook Events. This issue affects only the user interface.

How long will this go on?

Disabling the listing of Events in the UI is a temporary measure to allow the users that were blocked by this issue to use RSS Graffiti normally. Luckily the number of Event Walls that use RSS Graffiti is relatively small and hopefully those users will not be affected but this measure before we come up with an alternative solution. We hope to be able to find an alternative solution to the problem tomorrow.

So what was the problem?

The problem is that a Facebook FQL query which should list the Events created by a user, suddenly times out for some users. Although our implementation should work normally, there is some unknown problem in Facebook that causes it to time-out so badly that you don’t even see the Facebook logo appearing when this happens. We will file a bug to Facebook for this and look for alternative ways to implement the specific functionality ASAP.

Special thanks to the users that worked with us to track this down. We’ll keep you updated on how we tackle this issue.

About the recent downtime

Sat, 15 Jan 2011 16:13:00 +0100

After bringing everything back up and looking at our log files to see what happened, we conclude that this embarrassing downtime could have gone by unnoticed had we realized it sooner.

RSS Graffiti runs on multiple servers. The website and the front end of the application run independently from the processing engine. The problem started on one of our back-end servers while we were still up and working, but we failed to get the alert before calling it a day and going to bed. Then gradually everything started to go wrong to the point the front-end web server became unresponsive. Later, the processing queue stopped functioning too and the rest of the servers that were still up couldn’t do anything about it without human intervention.

During the past days we have been phasing out an old domain name we were using when we started developing RSS Graffiti. Changes in the DNS and MX along with an apparent bug at Google Apps GMail , caused a mail actually originating from rssgraffiti.com to appear to have been sent via our old domain name which in turn led us to ignore the warning.

Disasters usually come about by a number of small coincidences and this one was no exception. Although the problem with the mail will most likely not happen again, we definitely need to find a way to wake up when an alert comes in. RSS Graffiti can sustain failures and recover from them without affecting the end user, but obviously this is not true if the problem remains unnoticed and unsolved for many hours.

We would like to ask you to please accept our apologies for this incident and assure you for our determination to prevent similar issues from happening in the future.

Facebook down - Pausing Publishers

Thu, 16 Dec 2010 22:38:10 +0100

We were just stunned by the short look we had on the brand new design of Fan Pages and their new features! Unfortunately Facebook has become unstable during the roll-out so we can’t kick the tires just yet!

As a precaution while Facebook is facing difficulties we are pausing our publishing engine to avoid unexpected behavior or lost posts. We will resume publishing after Facebook seems alive again.

New Facebook change breaks publishing. Here is a fix for every curious developer

Wed, 10 Nov 2010 20:41:00 +0100

Early this morning (morning in Stockholm at least :-) ) around 06:00 GMT, Facebook pushed an update on its platform, affecting RSS Graffiti publishing feature on all Fan Pages. We ‘ve been informed by our users about it, and soon came up with the solution to the mystery, developing and pushing a hot-fix for this issue.

Apparently RSS Graffiti was not the only application affected. Any application using the REST api to publish on facebook Fan Pages’ Walls has the same problem. Since then quite a few developers have asked us one way or another to help them circumvnet this issue, by explaining what was the change and how we fixed it. So here it goes:

After this modification by Facebook, in essense all of our users trying to publish on their Fan Pages, were getting an error indicating:

“Session user 0 does not have permission to post to page XXX as the page” error 200.

“0” (zero) in this error message, was there to indicate that there is no actual session user associated with the API call. Which up to … yesterday was absolutely acceptable, as session keys were not required to publish on a Fan Page.

What changed, is that Facebook now - we cannot know if this a temporary condition or a permanent change - requires a user’s session key to publish on Fan Page. The “0” in the error above was the hint to help us guess that.

So in order to successfully call the “stream_publish” method of the rest API, you need to provide a user’s session key by setting the Facebook->api_client->session_key property.

And in order for that to work while the user is not logged in, the Facebook user has to have granted the “Offline Access” and “manage pages” permission on the application, so that the session key of the user is not expiring and usable even when he is offline and allowing access to his administered Fan Pages.

There you have it. You can then go on and call $Facebook->api_client->stream_publish to publish on the stream of your fan Pages.

If on the other hand you are using the graph api to perform the stream publishing, you will need:

Request to be granted the manage Pages and offline access permission
Request access_tokens for the pages by visiting: https://graph.facebook.com/me/accounts with the user’s access_token. This should return a list of Pages that they admin, along with valid access_tokens for each of these Pages.
You should then use these access_tokens to publish on behalf of each Page.

We hope this can save all of those that asked us, or are anyway affected by this issue, a few hours of their lives.

There is now an associated bug in the Facebook bug tracker:

http://bugs.developers.facebook.net/show_bug.cgi?id=13453

Unplanned maintenance

Thu, 23 Sep 2010 22:16:00 +0200

Since Facebook is down anyway and as a result, RSS Graffiti is not currently accessible, we are seizing the opportunity to take RSS Graffiiti offline too to do a couple of chores we had planned for tomorrow. We will be right back.

[UPDATE] 2010-09-23 21:17 GMT

We are done with our maintenance window and the application is now back online.

Facebook Latency issues

Thu, 23 Sep 2010 21:29:00 +0200

Facebook has announced in their Platform Status blog that they are experiencing API latency issues right now. Apart from the API we see that the whole of facebook.com is not responsive so this seems even more serious than announced.

The graph below is a snapshot taken a moment ago from Facebook Platform Live Status (which is also unresponsive from time to time). The peak in the graph is kind of monumental…

Of course RSS Graffiti cannot be expected to function under these circumstances. We are sure that Facebook engineers are actively pursuing a solution to these issues and we hope they manage to resolve them quickly.

Removing the application

Wed, 18 Aug 2010 02:16:07 +0200

As strange as it might seem, some Fan Page administrators have been complaining lately about problems removing RSS Graffiti. It is strange because removing an application is a standard Facebook procedure, it is completely independent of any application and it should be bullet proof and just work.

If you are facing such problem please read on for some insight on what is going on and how you can resolve your issue.

First make sure the application is removed from the Fan Page (not just your Facebook Profile)

Sometimes people are tricked into thinking that removing an application from a Facebook Profile, also automatically removes the application from the Fan Pages the user administers. Of course this is not the case. Profiles are independent of Fan Pages and that is as designed by Facebook. So first of all make sure the application is removed from the Fan Page.

To do that:

Go to the Fan Page
Click “Edit Page”
Find the RSS Graffiti application listed along with the other applications you added on the Fan Page and
Click on the “Remove Application” link

If you think that the application has been removed from (or never been added to) the Fan Page but it still posts, please just check once more. Sometimes Fan Pages have more than one administrators. You might have removed the application from the Fan Page but another administrator might have added it there.

If you are certain that the application has been removed from the Fan Page but it still posts then please follow the instructions in “How to disable posting on a Fan Page” to make sure you disable posting. Some insight on how can an application post on Fan Page even if it seems to be removed can also be found in that post.

How to disable posting on a Fan Page

Thu, 29 Jul 2010 16:31:00 +0200

Some users have complained that RSS Graffiti is still able to post on their Fan Pages even after they have removed the application.

It seems that ~~two~~ [one] things ~~are~~ [is] going suddenly wrong and result in this behavior:

~~RSS Graffiti fails to realize that the application has been removed (our bug)~~. [UPADTE: this is now fixed and all removal notifications from Facebook suceed.]
Facebook still accepts posts from RSS Graffiti even though the user has removed the application (strange Facebook behavior).

Of course Facebook should not accept posts from a removed application. We used to count on that. It seems we can’t count on that any longer.

One of the new Facebook permissions that is specific to Fan Pages is not revoked automatically by Facebook when the application is removed. The permission that seems to be causing this issue is “Manage my Pages”. Since Facebook does not remove the permission automatically, to avoid the issue you have to manually revoke the permission before removing the application.

Apart from this issue on Facebook’s side, ~~there is one more problem on our part:~~ When you remove the application, Facebook pings our server to notify of the removal. Apparently there is a bug in our code that results in not marking the application as removed, so RSS Graffiti will still try to post as long as there are feeds on the page. This was not a problem so far because Facebook denied to accept the posts. Apparently it now accepts them ~~so RSS Graffiti never gets a chance to realize that something is wrong and that the application has been removed~~. [UPDATE: FIXED. All removal notifications now succeed.]

~~We identified the problem on our part and we are going to push a maintenance release later today to fix it for future users~~. [UPDATE: DONE]

If you are experiencing this issue now, please follow these instructions to make sure RSS Graffiti does not publish on a Fan Page even after you have removed the application:

If you have already removed RSS Graffiti then just add it back temporarily.
Go to RSS Graffiti and select the Fan Page that you want to disable.
Click on the ON/OFF button on the top right corner to switch the Fan Page OFF.
You can now remove RSS Graffiti from the Fan Page again.

If the ON/OFF switch was in the ON position then the Fan Page was active and as long as it had feeds added to it and the “Manage my Pages” permission was not revoked, RSS Graffiti would still be trying to publish on the Page and Facebook would still accept and actually publish the posts even if the application was removed.

So make sure this time you leave the ON/OFF switch in the OFF position. This way RSS Graffiti won’t try to publish and regardless of whether Facebook would still accept the posts or not, you would not see any more posts coming from RSS Graffiti on the Fan Page.

Look at the following screen shot to get a better orientation on where you should click to disable RSS Graffiti for a Fan Page.

Look at the following screenshot to see the same Fan Page in Disabled Status.

If you later on decide to add RSS Graffiti again to the Fan Page you can always come bak and switch it back ON again so that updates can resume.

This is the easy way to disable posting.

Although this is not ~~entirely~~ our fault we would like to apologize to the inconvenienced users. ~~A maintenance release will be pushed to our servers later today to address the application removal issue~~. [UPDATE: FIX RELEASED]

[Important UPDATE: We have also noticed that some users file similar complains (i.e: ‘I removed the app but it still posts’ or ‘I never added the app how do I get rid of it’) but actually have the application -still- added. This is usually observed on Fan Pages with multiple administrators and it is actually caused by lack of proper coordination between them (i.e. admin A removes the app, then admin B adds it without telling admin A, then admin A complains about the app still posting). If you run a Fan Page with multiple admins please also make sure that the application is indeed removed and coordinate with other admins on the issue.]

1.9.0 Beta - first impressions

Fri, 23 Jul 2010 04:08:21 +0200

For the past few hours we have been monitoring our new release and trying to identify and resolve any issues. The processing engine seems to run very smoothly and processes all feeds of all targets in less than a minute as expected.

Nevertheless we identified some issues relating to session keys and publishing on Application Profile walls. These do not affect everyone but there are some cases where they can prevent posts from completing successfully. We are going to be working on ways to overcome these issues in the coming days.

All feedback will be valuable.