Su

Click the title text of the redirect, next to the checkbox.

Same here, across three separate WP installations.
The cron job is running, and curl is functioning(fine with a different URL).

Requesting the FeedWordPress update URL manually with curl at the command line results in a completely blank response(0 data transferred, etc.) and no new content pulled down.

Oh, nice. Just tried it out and it works perfectly. Thanks.

My comment might’ve been unclear.
You’re not hacking the source; I was just including where it seemed the problem was.

There’s a setting within the UI for the cache time. Set that to “0”.

Also seeing edit links for non-authd users. Using the shortcode in my case.

EDIT
The problem has something to do with Spots’ caching feature, at line 1258 of icit-spots.php. If you set the Spots cache time to 0(disabled), the edit links are no longer erroneously presented. Since many/most users are probably using a dedicated caching plugin, this is probably a reasonable workaround until the Spots dev addresses.

[I assume you’ve given up on this by now, but in case anyone else ends up here.]

There’s a PHP shorttag opening(<?) at line 171.
Change it to <?php and the plugin should activate without issue.

Can’t be done.
There’s already been a request for it that currently has the feature bumped to “probably in a future pro version.”

If you require this immediately, CSV Importer can do it, although you should do a careful comparison before switching. It can’t, for example, match the featured image function of this plugin. There may be other differences; that’s just the main one that had me switch to this from that one. (I didn’t need taxonomies; did need images.)

I was just about to upload a modified version of the file, but 1.1.2 is already available. I’ve installed it on both sites I mentioned before, and it seems like they’re behaving, front and back end.
Thanks for looking at this so quickly.

Looks like you got most of the way there.
Something I should’ve mentioned before(sorry) is that the errors were rendering both within WordPress and on the site itself.

With 1.1.1, WP is now clear, but the front-facing site still shows the SuperCache line 90 message. I didn’t disable it to see if it still made its way to other plugins, etc. yet

Maybe that gives you enough information to continue investigating. I’m going to try and get this going on a non-public install so I can remove stuff more aggressively and narrow it down more.

You could use the Adminimize plugin to hide menu items by user level in the meantime.

I’ve poked around in the repository a bit and as far as that’s concerned the code that would be responsible for this has never existed, from what I can see. The inline search/replace function is also mysteriously missing.

The documentation page references a version of the plugin(1.4.11) that’s not actually tagged in the repository, so maybe the dev decided to yank the features or something and didn’t entirely clean up.

The only thing I can see working at the moment is to add a large value to the drop-down. I mentioned where to do it in my original post. It’s pretty simple.

I can’t say it’s whatever is happening in your particular case(especially since I have no comments data myself), but you might want to have a look at my recent thread, where I’m finding some strange behavior with the “Limit to” option. It’s messed up enough I’m paranoid it’s a “just me” thing, so if it looks familiar it’d be great if you could confirm over there.

This turns out to be more involved, related to particular field combinations. The content model of the project I’m using this on at the moment is very minimal so I can’t try everything, but to start:

In all cases the search term is “the”
Assuming anyone replicates this, your specific numbers may change, obviously, since this is dependent upon how many actual matches you have in your data. Just for reference, I’ve got about 2000 items at the moment.

• Searching post titles with no limit always returns nothing.
• Searching post titles with limit 10 returns 5 results.
• Searching post titles with limit 25 returns 11 results.
• Searching post titles with limit 50 returns 23 results.
• Searching post titles with limit 100 returns 32 results.

Note that each time we increase the limit(beyond 10), we get a number of results that should’ve been possible with the lower limit.

• Searching post URLs with “no limit” also always returns nothing.
• Post URL searches exhibit similar behavior to the numbered limits for titles.

• Searching post content with any of the limit options(including none) returns 959 items
• This is especially weird, so I tried a another term “will”, and the behavior is the same. (With different number of matches.)

I don’t have much data in the post excerpts, but there’s a term I do know appears several times, so using it:

• Searching post excerpts with no limit returns nothing
• Using numerical limits, I still get nothing until set to 50(1 result) and 100(2 results), which obviously makes no sense.
• Additionally, I know the term appears a lot more often than that, so there’s still instances that are being outright ignored.

I have no comment or meta field data at the moment, so can’t try those.

The behavior at least partially duplicates on a separate installation(though too small to draw much conclusions from), so hopefully I’m not completely wasting my time here documenting a case-specific glitch. Trying to find a larger install to try things out on for confirmation.

Same here. Doesn’t actually break anything that I can tell, but still ugly.