rawalex

Jan, I suggest you re-read Esmi’s post above yours. Your moderator is out of touch with the reality on the ground.

As for the TRAC, all I have found is tickets that suggest it’s something that might get looked at long in the future, that it’s not considered an issue. Moreover, I doubt that any fix to the core on this issue will be rolled back to 3.8.3.

I hear you and Esmi plain and clear now, sorry I tried to help wordpress with issues.

My last post. Thanks for your “support”.

esmi, sadly your answer is the best way to discourage people from participating. A single minded “this is the only way to troubleshoot, no matter how much it hurts you” won’t cut it with commercial customers. You can’t tell someone to stop doing business for an undetermined amount of time while you play around. It’s not practical, it’s not sellable, and it’s certainly not something people will tolerate.

I think you probably went well past your moderator mandate, can you just pass this thread on to a developer instead and let them consider it? Clearly there is an issue if there is a plug in to band aid the issue, don’t you think?

Sadly, what you think of a temporary steps are enough to cripple a blog in Google for weeks. Since this isn’t a 1 minute “works or it don’t” thing, it would essentially require a series of steps with upcoming posts, removing and then slowly adding back themes and plug ins until “boom” you hit the right one – over a period of days. Worse, because the problem is NOT consistent, the process could yield nothing, a false positive, or a false negative, because it’s not a yes/no 100% of the time issue.

Thus, your idea for troubleshooting doesn’t really cut it. It might work for someone with a blog that get a few dozen visits a day an no search engine attention, but for sites getting thousands of visitors and plenty of search engine love it’s just not a logical step.

Sorry I raised the point. There is a bug in wordpress, but I am not going to pay for it with my business to find it.

esmi, if it was something that I could trigger “just like that” I would just set up a test blog and make it happen. It’s not consistent, it doesn’t happen every time, it might not happen for days. In order to test it, I would have to basically operate a blog like normal, put future posts on it, and then wait until finally something did or did not post.

“Not a hunch. Just basic troubleshooting.”

The issue here is that the known state isn’t really “known”. The problem appears to be either a coding error in the core or unprotected code in the core, either of which is best fixed by… fixing the core. Your hunch is that it is a plug in, yet there is no indication of this, my installs tend to use minimal plug ins, nothing bleeding edge, and nothing that has any similar reports. Clearly with a number of other people experiencing the same issue, there would be some sort of report in any offending plug in by now. There is not.

” Could be the theme, a plugin or the configuration of your server.”

Yes, and but it’s more likely to be a core issue, as it’s something that changed with changing version of wordpress itself. Assuming it’s always someone else’s fault is never a good starting point.

Here, some more thoughts on WordPress 4 and beyond.

I think wordpress needs to deem certain features and functions as “core” and not to be played with. Currently there are issues with scheduled posting that some are suggesting might be caused by plug ins or themes. This is something that should be a core function and not able to be touched by others.

It seems a little too easy for a plug in developer to create true havok by doing X or Y or Z in order to make their nifty new widget thing work, while not considering the impact on others. If they can mess with the very core of wordpress, the risks for end users is very high (and provides perhaps a quiet and sneaky way to install malware in the long run).

Some features and functions should be core to wordpress and not able to be usurped by plug ins.

Jan, in a world where Google revisits sites often and punishes the slightest transgression with weeks of pain, it is very unwise to take a site and make significant changes to it in order to “test” something. This would require leaving blogs without SEO, without design, and without the structure created by the combination of themes, widgets, and plug ins, just to test your hunch. I tell you the same thing I tell my ISP when they suggest that I remove all of my networking equipment and install their connection software directly on a PC, which is: I can do that, but I would have to charge you for my time to do so, and any losses I incur as a result.

Put another way: If you think that a theme or a plug in has the power to disrupt, block, or harm a core feature, then perhaps it’s time to consider protecting core features from the plugins.

“The scheduled posts issue is impacting a number of users such as your self. A quick search of the forums easily verifies that.

As an alternative you can also consider trying this plugin or one’s like it.

https://www.ads-software.com/plugins/wp-missed-schedule/”

I looked at that plug in, and the end result on a server with 100 blogs would be a ton of extra resources used to constantly be scanning for missed posts. I appreciate at least that you didn’t suggest to fix it with CSS this time, a marked improvement! Seriously though, that isn’t a fix, it’s a crude band aid to try to cover up a core failing. Post scheduling is something that shouldn’t be affected by plug ins or themes, it’s a basic core function (and a relatively simple one at that, from everything I can see).

The standard answer of “remove all plug ins and use a default theme” may be function from your stand point to get a potential answer (or find someone else to blame for the issue) but really, it’s not real world practical. As wordpress becomes more and more of a commercial CMS as well as a personal blogging software, you will find it harder and harder to convince people to shut down their sites or make significant changes just to try to troubleshoot what has been broken in an update.

You have enough people complaining about this situation, perhaps having a look at the code (and looking at differences to past versions) might help you spot the problem. If something can determine that the schedule was missed, you would think it could also actually post it.

“. Can you replicate the problem using the default Twenty Fourteen theme with all plugins deactivated?”

Umm, no, because I am not going to take a functional blog and disable all that makes it acceptable to Google in order to track down a core coding issue. I don’t run a ton of plugins, all of them well aged and respected.

Switching a blog to 2014 and no plugins long enough to detect this problem would pretty much be death in Google to that blog, making it pointless to find the solution.

(as for the us and them, the difference is that the core developers actually do have influence in the product, where board moderators are regular people who have taken up the position of well informed person. If’s the difference between someone who can tell you how to drive a car and someone who actually drives one)

I am using 3.8.3 right now.

What happens is you write a post for a future release (say tomorrow morning), and everything is fine. It’s marked as scheduled. The next day, the post doesn’t get added, instead it gets marked as “schedule missed”.

The solution that I have seen here so far is some sort of cron job that runs every 5 minutes that checks the posts and resets them somehow. That appears to be closing the door after the horse got out. It’s something that pre-3.8 seemed to work fine. Now in 3.8.3 it seems to be a regular occurrence that posts “miss schedule”, even on sites with more than enough traffic to trigger the event in a reasonable amount of time. In fact, the volume of visits to the blog seems to have no effect either way.

(oh, and to answer you mod thing… I asked for wordpress support. That you volunteer to do it for them but have no real control over the product isn’t my fault either!).

I too tend to agree here, for a bunch of reasons.

However, I think that the wordpress staff and the users aren’t listening very well to each other on this one.

For users, you need to understand that the source of your frustration is that you have often used this tool to make up for poorer source material, or as a way of making a theme do something that it otherwise does not do. I have used it to “float” images in a post (by adding Float:left in the advance options after setting a border). It’s not the “right” way to do it, but it is often the expedient way to do things.

IAmediaworks, you example is perfect. Varying size images are perhaps better addressed by correcting the images themselves. Yes, that does require some effort outside of wordpress, but the old saw of “garbage in, garbage out” applies. Yet, I understand what you are doing and wordpress should still support it, because it is expedient and a very direct way to solve an issue.

They are also tools for people who are not in the position to edit the themes or who are not comfortable with creating child themes.

For the developers and wordpress team, you guys and gals need to step back and moment and have a good think here. Up until fairly recent wordpress history, child themes were not really supported, and correcting display problems by editing the theme meant that you could no longer update the theme without losing your fixes. WordPress itself taught us to use the advanced editing tools for these very reasons. The current and very sudden “fix it in css” mentality goes against everything wordpress has done for nearly 10 years. It’s a big shift, and pulling the rug out from under people by removing a tool (without any obvious reason why you did so) leaves them feeling unsupported and out of touch.

Moreover, you start to create a gap between the “can do CSS / can program” and those who cannot. Fixing it in code or in css isn’t easy for people who don’t grok the concepts, it creates a high barrier to entry for those who would want to use wordpress, they are now stuck using the themes as presented – or they get to pay someone to fix it for them. That certainly goes against the wordpress way for the last 10 years.

I also think that wordpress risks running itself into the problems that face frameworks that rely too much on plug ins and external pieces to really work. That risk is that no two installs can ever be the same, and debugging them and making them truly work becomes a nightmare. As anyone who has tried to debug a drupal site someone else created, there is always one or more annoying plugin getting in the way, it seems… and no two installs ever seem to be the same.

When you remove functionality, for some it creates netsplit. Some people will refuse to upgrade (so they don’t lose their tools), and over time that may increase security risks and support issues. WordPress is very a much a “current version support” product, most of the plugins are “current version” if they are maintained. It’s not a pretty scenario in the end for anyone.

Is that the future for wordpress? If so, let us know now, so that we can consider the alternatives.

Since 4.0 is really just the next step from 3.9, it’s not really a .0 version, just a numerical counter. From what I can tell, it’s not a windows 7 to windows 8 thing, just some changes.

Then again, as we have seen with 3.9, what wordpress developers consider minor may in face be a big deal for many. I personally almost always avoid x.x.0 upgrades, they almost always have issues, and it helps keep yourself from getting cut by the bleeding edge.

Ipstenu, I will agree with Davidmcc3 here. The whole point of wordpress, from the 1 button install to the direct interface was original to make it so that non-programmers, non-designers, non-techies could setup and maintain a web blog site… without needing to hire a tech to do it for them.

More and more, wordpress slides away from that. When the answer is “learn PHP” or “learn css” then wordpress is losing it’s advantage. It’s nice to be able to use those things to extend wordpress and customize it, but don’t you think the basic core of wordpress should just work fine for most people, without needing a programmer to “fix” it for you?

At this point, wordpress is starting to make Drupal look good (and it’s way to technical and picky for most).

My thoughts for 4.0: Stop.

Seriously, I would suggest that the developers of wordpress, rather than just relentlessly pushing forward actually take some time out and actually consider the product as a whole, rather than working on bits and pieces. The recent debacle with the series of releases from 3.8.1 to 3.9.0 release (with bugs, unpopular removal of features, etc) should be a moment to reflect.

Moreover, rather than worrying about wing ding flashy stuff, sit back and look at the core of the product and make sure it is absolutely it’s best. Look for slow queries, things that don’t scale, and more than anything security of the login, comment, and pingback systems. Make sure the foundation of the house of wordpress is as good as the shiny layers of paint you keep slapping on willy nilly.

Seriously, it’s time to reflect, maybe take 6 months to develop wordpress 5.0, perhaps with a new and refined core.

Jan, one of the problems of moving this from core to a plug in is that the core will continue to evolve with no consideration for the plug in, it will no longer be a player in future directions or decisions. As of today, that functionality is no longer part of wordpress, but if you want to FORCE it with a plug in, you can make it happen for now. However, at some point in the future the core will change again, the person who made the plug in will no longer maintain it, and the functionality will be lost forever.

Pushing those who use that functionality off to a plug in is basically a sedative to make us stop thinking about the problem. By the time it crops up again, the answer will be “we removed that from core 3 versions ago, we can no longer re-integrate it”.

I see where it’s going, and it means plenty of disrupted work flow for those who were using that functionality.

“In cases where past habits did get settled into, a plugin like https://www.ads-software.com/plugins/advanced-image-styles/ is a good route in the short term.”

Sheri, that is sort of intentionally missing the point, don’t you think? There isn’t any good solid reason to remove the functionality from the core to start with (except it made it easier for someone to code an upgrade with new winky blinky features, I suspect). It seems really insane to remove a feature and kill off one of the ways that (apparently) a significant amount of power users were using to write blogs without any real notice. I mean, it’s the sort of “upgrade” that makes me NEVER take a .0 upgrade from wordpress, because there is always some magic catch that wasn’t clearly discussed.

“These topics are important but they typically get marked resolved when a ticket is raised”

Wouldn’t it be better to mark it as “Ticket raised” or “SEE TRAC ####”. Marking it as resolved sounds like you have a solution, not just that you have accepted it as an issue.

Actually, I have a family member who is entirely blind, so I have plenty of experience with how they deal with (and don’t deal with) the internet. Recaptcha is not perfect, nobody is claiming it. However, it is functional. Most spammers are not going to spend the time and money to get past captcha, a few will but most will not.

The point is more this: It isn’t any less effective in dealing with spam as compared to Akismet, so it’s disappointing that something is grandfathered in while not being the optimum solution.

As for using it for free, if you have a popular site (at least popular with the spammers) you will blow past the volume levels very quickly that will make it say that you need a commercial license. The first level of license is insufficient for the most part, meaning that you have to pay on a volume level. This isn’t for a service you need, but to protect against a weakness and deficiency of how wordpress handles spam.

It’s funny. I came to realize a while back that wordpress’s problem of spam is exactly the same problem as why spam is such a problem in email: Overly permissive and easily manipulated systems, with default settings of wide open which invite, permit, and encourage spammers at all levels. The solutions generally put forward are like sandbags in a flood, a poor line of last defense for something you can’t stop.

So the real solution is changing the core function and core functionality to better serve real users and to make it less appealing to spammers. WordPress installs are too easy of a target with default settings that encourage them. As an example, allowing people to post a comment based not on the name of the post (or it’s permalink) but rather allowing them to use the postID, even if you are specifically not using postID in your blog. Ever wonder why your spam often attacks older posts? it’s because they just aim at a random low post number and fire away. Often once they have one comment accepted, they will automatically add that post number and domain onto a list and come back to spam it again and again. Even if you decline the comment or mark it as spam, as long as it gets accepted on submission, they keep coming back. They exploit a weakness in the way wordpress approaches spam to make it easy for them to spam.