sffandom

Not running SSL.

Whenever I run the test script it fails to connect to the server. The authorization token is indeed embedded in the settings (you will not see it here). Here is an example report:

*** Test 1/2: SitesManager.getSitesWithAtLeastViewAccess ***
Call: [DOMAIN REMOVED]/?module=API&method=SitesManager.getSitesWithAtLeastViewAccess&format=XML&token_auth= + TOKEN
Result:

Time: 0.26s

*** Test 2/2: SitesManager.getSitesIdFromSiteUrl ***
Call: [DOMAIN REMOVED]?module=API&method=SitesManager.getSitesIdFromSiteUrl&url=http%3A%2F%2F[DOMAIN REMOVED]&format=XML&token_auth= + TOKEN
Result:
<?xml version="1.0" encoding="utf-8" ?>
<result />
Time: 0.39s

For the record, that should have said: “the WP-Piwik is up-to-date (version 0.95)”

Okay, the issue seems to be resolved by following the directions posted here by user “lewatson”.

1) Switch theme to Twenty Eleven
2) Edit a post (displays as white pane with red underlines)
3) Clear cache (press F5)

Visual editor, tabs and buttons returned at this point in edit post mode.

4) Switch back to original theme.
5) Edit post.

For what it’s worth, the logged in editors cannot see the new dashboard header/toolbar. I have even tried upgrading an editor to Admin status and it’s not helping. The user cannot log out, change Screen Options, Edit Profile, etc.

The left-side navigation works fine. You can click on anything and the screen changes. But the WP 3.3 dashboard is not there.

My admin accounts are able to use all functions in WordPress 3.3. The other accounts apparently cannot get anything to work in the dashboard. Anyone can read the articles but Editor-level users cannot post, set preferences, change attributes for articles, etc.

Have tested this with different browsers, logging out and logging back in, etc.

The ads are still running fine. This issue is resolved.

To follow up, though I’m not quite yet ready to say it’s fixed, PeggyK in the Google AdSense support forum noticed that I was not explicitly permitting the AdSense bot to fetch my pages in robots.txt.

I am pretty sure I rewrote the robots.txt file when I rebuilt the site in June. She suggested that my catchall Disallow at the end of the file was probably blocking the AdSensebot. I commented out those two lines last night and now we’re seeing ads again.

I have seen intermittent ad displays before in the past couple of weeks but I think this may have been my problem all along. The old robots.txt file had been around for years and I probably just overlooked giving explicit permission to the AdSense bot.

I’ll check in here either later today or tomorrow and if the ads are still displaying that should be good enough to say this issue is resolved.

And interestingly, I just noticed that the WordPress blog feed doesn’t appear in the dashboard.

So my installation of WordPress can fetch Twitter feeds — it just cannot fetch RSS feeds.

This will be my last comment in this thread since someone has filed a bug report.

“This solved the problem – adding this line to .htaccess:”

Does me no good. I got around the problem by using the Twitter widget. So my RSS feed goes to Twitter through Twitterfeed, and therefore my Tweets come back to WordPress.

They really need to solve this problem and stop denying that it exists.

Never mind. I created a test php file that fetched a remotely hosted file just fine.

So it’s not my server and it’s not my hosting ISP that is causing the problem.

In my book, that points the finger right back at WordPress 3.0.1.

However, not being a PHP guru, I’ll be glad to accept there may be some configuration thingee that prevents WordPress 3.0.1 from remotely fetching files even though a script I write on the fly works just fine.

Can anyone point me to a human-readable, non-cryptic reference that doesn’t assume the reader already understands whatever it is the author is incapable of explaining in plain, simple English that provides a checklist of things to look for in PHP configuration (which I have not ever attempted to edit)?

“More than likely, your hosting provider has disabled PHP’s ability to fetch remote URLs (including feeds),”

I have a leased, dedicated server. Since my Perl scripts are able to fetch remote URLs (including feeds) I think it unlikely the hosting provider is interfering with the server’s fetch capabilities.

At this point, I cannot even get a wordpress.com feed to run in the widget. I tried the American Chairs feed above, too. No go.

Can you point me to an example of some PHP code I can drop into the footer.php file to test my server’s ability?

Okay, so I posted that without explaining the fix. This is the line that allows my subdomain to use images from within WordPress:

RewriteCond %{HTTP_REFERER} !^https://([^.]+\.)+example.com(/)?.*$ [NC]

I probably no longer need the line above it.

After recently installing WordPress 3.0.1 myself, I ran into this problem with my first subdomain-based blog. I found this discussion and saw I was in the exact same boat.

Fortunately (for me, and hopefully for others) I discovered a resolution that may help many people.

My .htaccess file includes code that prevents people from hotlinking to images on my site. That code provides for a few exceptions (domains I control myself). Until now, I hadn’t really needed to worry about sub-domains.

Here is an example of the .htaccess code I am now using. My images are loading fine on the subdomain. The first block of code prevents the hotlinking (while allowing major search engines and my sites to show my images).

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www\.)?example.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://([^.]+\.)+example.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://(www\.)?google.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://(www\.)?bing.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://(www\.)?yahoo.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://(www\.)?bing.com(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^https://(www\.)?ask.com(/)?.*$ [NC]
RewriteRule .*\.(gif|jpg|jpeg|bmp)$ https://www.example.com/hotlink.jpg [R,NC]

# Enable WordPress 3.0.1 (multi-site) control over root URL
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]

# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule . index.php [L]

# End WordPress 3.0.1 specific code

The section embedded in the “WordPress 3.0.1 specific code” section is the same code apyano posted a week ago. So far, this is all I seem to need in my .htaccess file to allow everything to work.

Admitting there really is a problem and then fixing it would be more acceptable.

I have just installed WordPress 3.0.1 in the past few days and the RSS widget is STILL broken. The very same feeds that I can install on a WordPress.com blog without any problem do not work with WordPress 3.0.1’s widget.

I don’t care who on the development team can get their test site to work properly. I’m not using your test sites.

Please don’t sit there and say, “Well, our light bulb is working so there is no problem that we can see” That is the old joke that people used to tell about Microsoft tech support.

Clearly, there is something wrong with the WordPress 3.0.1 code. Is there an IPR issue that prevents the WordPress 3.0.1 code set from using the same code that WordPress.com uses? Why should a feed that WordPress.com finds acceptable not be acceptable in WordPress 3.0.1? Why can’t both the hosted and the self-installed WordPress widgets work the same way?