benchwarmer

I actually tried all of that to no avail.

It turns out that I have found the problem, but I don’t understand why it’s like this. Perhaps you’d know?

So to reiterate: what I did was take an expired event (one where the initial event date had already passed) and attempted to change it to a future date. Again I’m just testing this on localhost to see if I want to go down this road (presumably with the Pro version) on my live site.

I only had one expired event left–so I’ll have to wait a few days to try and replicate the problem organically–but at least for this one I noticed that the WordPress Publishing queue was not showing “Publish Immediately” as it does for any new events, but instead some seemingly arbitrary scheduled future publish date. I made no changes to that field manually so i don’t know what prompted this, but that seems to be where the problem is. Once I scheduled the publish to be “today’ and “now” it appears as expected on both the main Events page and on the widget.

Does seem like a bit of a bug though. You may wish to look into it. For now, if anyone else has this problem then the thing to check is the scheduled publish date of the Event post. In real life situations I would assume most people would not reschedule an expired event, but rather just push one in the future further into the future (which does not produce this error). However I could see reviving an old event if it were say an annual thing, just for the sake of not having to retype all the information about it. In that case, this error may crop up.

Though now that I think about it, if I maintain that there is a standard Category specific image when there is no Post image, then if someone wanted an alternative to that post image, then and only then could they attach an image with some specific name and it would appear. So it would be an option for specific circumstances, which may work in my use case.

When Postie ingests an HTML email with embedded images, are they treated as attachments? I’m just trying to think this through. I suppose if I tell it to look for a specifically named attachment it won’t matter, but…

Oh wait. You meant the filename itself. I don’t think I could that either because we’re talking bout MS Outlook HTML emails, so the image is actually part of the message and has no given name. I believe WordPress numbers them sequentially after they get uploaded (or perhaps Outlook does it, not sure. It doesn’t let you peek behind the curtain really). If I attached an image to each email with a name that might work, but I have to think about my email audience too and that would be a bit weird for them I think.

Not exactly the same, at least not with the alt attribute. I work at a University so we are having to gear up our accessibility standards in anticipation of upcoming federal regs on the topic. So for example images have to have an accurate description in their alt=”” so that screen readers can describe the image to people with vision difficulites. Unfortunately Outlook doesn’t let you do “pure” html things so I couldn’t put in a pseudo class or anything like that either.

I think the most value would come in conditional handling.

I have control over the messages that get posted to my site (I also manage the listservs that populate it) so I’m on both sides of the I/O stream, others I’d imagine wouldn’t necessarily be able to predict order of image attachment or otherwise know specifics of which image is best as a feature. Seems like a job for machine learning doesn’t it? Humans can do this super easy, simple algorithm, not so much. Though still some criteria, such as image size would be a good indicator and probably would be right most of the time. Simpler solution may be to use the alt img attribute. For accessibility it would still need to be descriptive, but if you started with “Featured image – Image of white cow in snowstorm” the first part of the string could be parsed.

I was just looking at the list of filters. Is there no specific handler for featured image? Seems gallery is the only image-related filter listed.

OK OK my bad. Sorry. Please ignore this. Turns out I had the password wrong! Very embarrassing, I’m going to go hide in a corner somewhere.

$29 to save all that manual effort? That my friend is a bargain!

I’m going to install it on my local copy of our site and get the config right, and then I’ll roll it out live. I’ll let you know if it doesn’t work for me.

Thanks.

OK. It looks like I figured out the problem. Apparently one of the recent updates to either Category Specific RSS Menu or Postie caused a conflict between the two. I don’t know which it was or why on earth these two wouldn’t get along, but as the former was ancillary at best I’ve just disabled it.

So basically I think it was two problems: One was that the external chron setting changed, so email got backed-up in the inbox, and the other was this recent plugin conflict prevented even a manual run of Postie.

Let this be a warning to others: If something breaks, check for plugin compatibility even if the two plugins have been coexisting. Any update may change the relationship.

Hey Wayne, I discovered something else that happened in November. They changed the webmail service.

Postie seems to be able to connect just fine (according to the Postie config test). Is there anything you’ve seen before that would allow the test config to run successfully but not allow Postie to actually pull the emails?

Not sure. Will have to ask as I can’t look behind the curtain right now.

True, though this doesn’t explain why manually running Postie also doesn’t work.

Hmm. I’ll have to look into that, but it can’t be the issue because I verified the last Postie generated post to the blog was 11/14/14. Everything else was a post or syndication. Can’t believe I didn’t catch this till now.

Thanks. Turns out the problem started before Dec 16. There was a direct post (not through postie) that threw me off. Looks like the problem actually went back to November sometime. I’m wondering if the chron change was the problem to start with. When did that happen?

To answer your questions, Yes everything is in the data center. I have to get access to the web server logs. Hopefully that won’t be s hassle. I used to have full access but they moved servers awhile back (long before this problem)….

As for versions, I’m using the latest of both.

I’ll finish clearing the mailbox tonight and report back if that’s helped.

In both cases it’s the university of California, Irvine. The mail client they use is Roundcube Webmail 0.9.5 which is GNU.

The site (and postie) has been running successfully since 2011. Until just last month/year.