DrProtocols

In addition, the minimum allowed event schedule in WordPress is ten minutes, so an event that is scheduled to run every five minutes won’t work correctly anyway.

I believe that this is in relation to the scheduling of single (one-off) events – so if a single (one-off) event is scheduled at time T and you try to schedule another single (one-off) event that is _exactly_ the same within (T +/- 600s) then that request to schedule the event will be ignored (although theoretically you could do so by directly manipulating the cron array in the options table). So note that includes trying to schedule an additional event within 600s before or after the existing scheduled event. If the event is given different arguments then the restriction does not apply so the restriction is easily circumvented should you wish to do so.

This does not apply to a repeating schedule event (like the jetpack cron) for which there is no minimum schedule period. In this case the cron queue only ever contains a single instance of the scheduled event as it is the WordPress Core functionality that schedules the “next” instance when the “current” instance is executed. In the jetpack case (or any other repeating event), when the current instance is triggered to run WordPress will “unschedule” the current instance and schedule a new instance (technically it reschedules first and _then_ unschedules the current event) at some time in the future taking into account how overdue to run the task might have been when it was actually triggered. So effectively WordPress will try and schedule the next instance relative to when it should have last run rather then when it actually did run which of course stops “drift”. Note that it will not schedule in the past – so, for example, with a schedule like every 5 minutes if the task was overdue by 7 minutes then the next instance would be scheduled in three minutes time and not two minutes in the past (or at least that is how it should be).

Hi Nastia

Disclosure: I do BackupBuddy Support/Development.

Whilst I am sure that your explanation is well intended and your misrepresentation of BackupBuddy behaviour not maliciously intended, the explanation is technically flawed and your description of how BackupBuddy behaves also demonstrates a misunderstanding of this issue.

FYI we have already been round the block on this one with your colleague Ignacio last year and I would recommend that you refer to him to get an understanding of the technical issues and reasons why both your explanation and description of BackupBuddy behaviour are incorrect. If you prefer I can run through it again with you here just to clarify.

My understanding at that time from the comments made by Ignacio was that the behaviour of Appointments+ was to be modified in the way that we had discussed (which was not the “solution” that you describe here). We have had no further reports of Appointments+ causing any issues so we had assumed that the fix of that nature had been implemented – but your posting here seems to suggest that in fact either that was/is not the case or that Appointments+ (the premium version) has indeed been so modified but that modification was not incorporated into any other “version” of the plugin like this version – so perhaps you could clarify that?

We really do not recommend that you modify BackupBuddy code in the manner of the attached file and we do not assume any responsibility for BackupBuddy on any site where the code may have been modified by a 3rd party such as yourselves or any other individual and in doing so you assume full support responsibility for BackupBuddy in any such instance where an individual may use your modified code.

As regards your suggestion of what is “required” to fix the issue caused by your plugin:

“To fix this, our developers need to rename every single class in the library”

you may indeed choose to resolve the bug in that manner but that is not how we would (or have previously) advise(d) that the issue is addressed. So to imply that you are “forced” to do this because of some BackupBuddy behaviour is a misrepresentation.

Please let me know whether or not you have any additional question or clarification required concerning the above information.

Regards…jeremy

Core dumps are really more fundamental than a simple plugin/theme conflict and the normal troubleshooting approach really doesn’t apply.

This should be referred to the host support who can properly analyse a core dump file as this has to be done in the context of the “program” that caused the core dump which is not specifically WordPress or any PHP scripting addition to that but rather the underlying hosting programs that are actually running those.

You will be messing around for ages trying to identify what may be causing the core dump if you just play around with things are the WordPress level and it will all be guesswork without any proper evidence from analysing a core dump…that’s really what a host support is for, investigating stuff going wrong with the hosting…

This is a definite plugin bug which is simply fixed as per the details from Rich.

I think the plugin author maybe misunderstood the plugin bug and thought it was something to do with cron events not running rather than schedule interval definitions not being available.

The confusing thing with this particular plugin bug is that the effect can vary based on the order of plugin initialisation by WordPress since this determines the order in which filters adding additional schedule intervals are executed.

What should happen is that as each plugin filter runs it takes the existing schedules array passed as a parameter by WordPress and adds custom schedules to it and then returns the updated array.

What this plugin is currently doing is _not_ taking the existing array (which it should take as the parameter of the filter function call) but effectively defining a new schedules array, adding it’s own schedule definitions and then returning that new array.

The effect is that any filter function for other plugins that are executed _before_ this plugin filter function will have the schedules they have added discarded but any plugin filter functions that run _after_ this plugin filter will have their schedule definitions added to the new schedules array that this plugin created.

Apart from fixing the plugin code as Rich indicates the other workaround is to try and force this plugin to be the first plugin that WordPress initializes (loads) and so its filter will be executed first and hopefully you would then get the additional custom schedules from other plugins as their filters would run after that of this plugin. But this is _not_ a solution but just a workaround because the core WordPress schedules that WordPress populates into the original schedules array will still be lost.

@otto – I really think that you and www.ads-software.com in general are _still_ missing the point.

Perhaps an analogy might help you. Suppose you were working on an important document for a client and you were both using the same application and version and you could exchange the document back and forth no problem. Then the application developers brought out a new version that you updated to and carried on writing the document and then sent it to your client and they couldn’t open it because your updated version of the application had (without notice, warning or choice) “upgraded” the document format so it was no longer compatible with the older application version – anyone wants to share that document _requires_ the updated application version. No problem you would say, I’ll just tell my client to update – but hey, you know they don;t want to pay for the update and anyway they have other concerns as they need to maintain compatibility with all their other stuff and they only do updates when _they_ need/want to and not just because _you_ say they should, and by the way, where is that document, you were supposed to be delivering it today… No problem you say, I’ll just contact the application developers and ask them how I can revert to the previous format…oh, what’s that, they say it’s not possible, sorry, you’ll just have to get your client to update won’t you…

You can argue all you like about how things _should_ be and I’m sure everyone would agree with you more or less. Sure, what has been done has been done with the best of intentions _but_ the real issue is _how_ it has been done and how are www.ads-software.com going to help al those users that they have caused a problem for and will continue to cause a problem for – or does www.ads-software.com simply not care about a bit of “collateral damage” because their intentions are well meaning?

This “problem” involving the use of utf8 has been known about for years (by www.ads-software.com), yes? Some related “fixes” were put in earlier versions of WordPress, yes? Additional issues were identified last year, right? A decision was made that changing to use utf8mb4 would aid in “fixing” those issues, right? The fact that this would now allow support for Unicode versions like 5.0 that would help _some_ users was a useful byproduct, yes?

So the issue is _why_ was such a radical change not better handled and better communicated to give users an opportunity to be able to _plan_ what they would need to do, to be able to _plan_ moving to new hosting or trying to persuade their clients to move, to be able to _plan_ changes to their workflows and tools that would be required?

The release announcement: https://www.ads-software.com/news/2015/04/powell/ has absolutely nothing that would indicate any possible issue or problem concerning MySQL version compatibility – so does this mean none of the assembled brains even gave it a thought, or did they think about it and just decide it didn’t matter and it would teach al those “amateur” developers out there a lesson, or what?

Whilst it’s great that you have your tools and workflows and perfect hosting, that doesn’t mean that your way is the one true way or the right way – others have been doing just fine with their tools and workflows for years, for you to simply say they are “wrong” with just an insouciant shrug of the shoulders is just insulting to all those workaday site developers out there just struggling to make a living out of WordPress. They don’t all have the time to be “Tech Guys” like yourself and understand all the ins-and-out of how things “should” be done in your opinion, they are just trying to make a living.

To just suddenly say that such a “non-tech” developer (and surely isn’t it a “selling” point of WordPress that you don’t have to be a “tech” to use it and develop sites with it) should just install the same version of MySQL as on the target system is just a naive suggestion from someone sitting in an ivory tower.

In any case this “helpful” suggestion does not help all of those who have already been force upgraded to _require_ MySQL 5.5+ for the site they have been developing for a client and now find it is incompatible with the client hosting. And what about all those who still have no idea about this issue and will be similarly updating or starting client development sites on their dev systems only to eventually find then incompatible with their client hosting. Oh, by the way, try convincing a client who has paid up their hosting for a year that they should just write off that and move to a new host just because you say so.

And as for this being an important security issue and so everyone must just accept it – if it is so important why is it that WordPress still only requires MySQL5.0 and 5.5.3 is only recommended – surely such an important security issue should mean that 5.5.3 was required?

We’ve been living with utf8 for years and the world hasn’t collapsed has it? I think the world would have survived a little longer without having nanny tell it what is best for it and force the cod-liver oil down its throat.

As for MySQL 5.5+ providing support for Unicode 5.0+ as opposed to 5.1 being only Unicode 3.0 – well that’s all great but how many users actually _need_ that so desperately that it has to be forced upon users unknowingly. I’m sure such users will be happy but at the same time would they mind if everyone was given a choice, at least initially? Whatever happened to deprecation followed later by removal? I don’t ever remember seeing pre-MySQL 5.5 being deprecated and notice given that support for older MySQL versions would be going away at some point under certain stated conditions?

I thought WordPress always made a big thing about being a “community” – in fact on the www.ads-software.com home page it states “we’d love you to join the family.” – well guess what, it just kicked some of its family members in the teeth and can’t even be bothered to say sorry let alone help them to the dentist to get them fixed.

So please, www.ads-software.com, think of _all_ your “family”, don’t hide behind ill-though out excuses, just admit you didn’t give things proper consideration, you didn’t respect your users and their needs, but that you’ll change things so that there will be a choice whether the upgrade will be made for some period of time that will be communicated so as to give users a chance to plan to accommodate it _and_ that you will also provide a means for sites that have already been force upgraded against the requirements of the users to “downgrade” back to utf8 until such a time as the users are _ready_ to upgrade.

No one minds you got the approach wrong, everyone makes mistakes, the strength of commitment comes in how you acknowledge and repair the damage caused and I’m sure www.ads-software.com is big enough to come through for its disenfranchised family members in this respect.

And before anyone “dismisses’ this as a “rant” – as one unfortunate WordPress forum mod did with similar comments elsewhere I can assure you I am perfectly calm and rational as is all the text above ??

Ok, now I’m waiting for the next set of excuses and put-downs and clever rejoinders to be rolled out in order to try and humiliate and intimidate me. Or maybe you’ll just ignore this altogether showing an equal level of contempt. Honestly I don’t really care as it would all be bluster over substance. Why not prove me wrong instead and do the right thing.

Regards

@mcdonna – hmm, seems like I posted before but maybe _someone_ is removing my posts. This in itself is not a solution in the general case but might happen to be something that coincidentally works (as far as you may know initially) in your particular case. Earlier in this topic it is stated by a “www.ads-software.com Tech Guy” that the upgrade is a one-way process and you cannot safely/reliably revert database tables once upgraded. So the WP Migrate DB support may certainly tell you that and perhaps they even believe it but what they state is rather too general to have any real meaning. But at least it appears to work for you ??

Regards

@mcdonna – I appreciate that you may have found a workaround that happens to work in your particular case and I am happy for you. But this cannot be offered as a general, safe, guaranteed “solution” in all possible cases. The support response you got, whilst I am sure well-meaning (and basically they would say that) is wwaayy too vague to have any meaning at all.

It’s sad when you see something like WordPress go the way of “products” from from traditional monolithic corporations. Eventually everything has to end up conforming to their view of how the world should operate and they forget their real world users who made them popular in the first place. The thing is you shouldn’t have to have had to do what you did – there is absolutely no good reason for you having been put in that situation.

@james – you are still missing the point which is that WordPress users have had a change forced upon them that is (apparently, as neither you or anyone else seem to have indicated otherwise) not safely reversible.

That change means that the workflow used by people making their living by developing WordPress sites for clients is broken when the development site (with no warning whatsoever) has the database changed (because WordPress considers the conditions to be right on _that_ server) and then the site developer tries to migrate the site to their clients hosting that _does not_ support the database changes in charset/collation and they cannot deliver the site to the client.

Now you can argue until you are blue in the face that all hosts should be on up to date versions of X and Y and Z but, you know what, as I previously stated above, the real world simply doesn’t match such a cosy idealisation as hosts don’t; all have up to date X and Y and Z and not all clients could give a fig, they just want their site delivered.

Your arguments are simply meaningless because they simply based on how you think the world should be but the world just isn’t like that, however much we might all wish it were.

So I say to you again, why don’t you get in contact with all the thousands of hosts out there and tell them they really ought to update their “stuff” because you say they should.

And, as I keep saying, WordPress didn’t force you to use a higher version of MySQL.

You just don’t get it do you – if the server you are on has the right conditions WordPress forces an update to the table charset/collation when the update to 4.2 is made doesn’t it, you cannot possibly deny that that update is forced, the user has _no_ choice, it happens automatically.

From that point on you are _forced_ to use the higher version of MySQL if you want to migrate that site to another server/hosting using the site migration processes that thousands of WordPress users would use and have used for ages. How is that not WordPress forcing you into using a higher version of MySQL? Any information I have seen from WordPress so far says the database “upgrade” is a one-way operation, it cannot be safely undone which means you cannot go to a server/hosting that has an earlier version of MySQL – but according to WordPress requirements all you need is MySQL version 5.0.

So again, all your “ideal world” arguments simply don’t hold water in the real world but it’s good to know that you are not really interested in the problem, in fact you refuse to even acknowledge there is a problem which is very sad.

Oh, and you strangely never responded to the point about this database upgrade being made optional through an “opt-in” check-box or similar. The information from WordPress make sit clear that it can be done at any time, it doesn’t have to be done as an automatic thing on a version update so a simple checkbox to select and save and have the upgrade done if you wanted it would have done the job with no fuss, no mess.

Perhaps you would care to answer how many users actually _need_ this database upgrade and how many might _want_ it and how many would really rather not because of the implications?

Remember, just because you have a problem, or even a handful other people do, doesn’t mean that everyone else does.

Hmm, did I say that “everyone” has a problem, no I didn’t. I have specifically outlined the scenario that will result in some unknown number of people having a problem – but given the huge user base of WordPress do you really think it will be just a “handful”, but at least I seem to care about their problem – you apparently do not because it may only be a “handful” of people. But of course you have no way of knowing that either do you?

If your hosts insists on using a version of MySQL over 5 years old, I fail to see how that’s a WordPress problem.

And again, if it is a version of MySQL that WordPress states is supported and yet a WordPress site cannot be migrated to that host because WordPress made the site incompatible with that host then it _is_ a WordPress problem.

Look at the WordPress requirements page – there is no warning that using a server with MySQL 5.5 or greater will then render your site unmigrateable to a host that supports only an earlier version of MySQL that is all that WordPress claims to require.

I appreciate you are just a volunteer and doing this in your free time but that doesn’t give you the right to be judge and jury over what is or isn’t a problem:

I’m not one of the developers, and I personally don’t see this as that big of an issue

As I say before, it isn’t about what you “personally” think and as you have stated you are not one of the developers so are you really qualified to judge what is and isn’t a problem for all those workaday site developers out there trying to make a living using WordPress? No, your role is to help people where you can and if there is something that you are not sure about or qualified to judge then you refer it on to someone who is – that is support. I’m used to this “blocking” from host supports on bad hosts whose sole job is to simply deny everything and blame someone else – I had hoped for something better here.

I honestly see no point in continuing this conversation as you have obviously decided that as you don’t think there is a problem then there isn’t one – I wonder what it is like to be so omniscient?

Good luck with your future endeavours.

@mcdonna – this isn’t really the issue, please refer to the information from earlier posts:

I’m not sure you’re getting it here. You cannot undo this. Older versions of MySQL don’t support utf8mb4 properly. You cannot do hand-wavy things to add that support. They simply cannot support those character sets. Trying to “fix” an export file will simply result in the data becoming corrupted if you use any of those unsupported characters.

and

If you want to try to search and replace “utf8mb4_unicode_ci” with “utf8_unicode_ci” in your export file, then that might work. Probably won’t though. And it will definitely result in data loss most of the time.

and

Which is why we were asking if anyone knows how to export or alter the database to go from utf8mb4 back to utf8.

Right. You can’t actually do that. If you have 4 byte characters in the database, then going backwards to a character set that doesn’t support them properly will cause your text to be truncated at the unsupported characters. And if you’ve been developing with 4.2, then you probably do have 4 byte characters somewhere.

You could go through and manually remove those characters, if you like. But it would probably take less time to copy and paste your text into the live site instead. Or do a normal WordPress export/import operation. Something like that.

Like I said earlier, if you want to edit your export files and change the collation with a search/replace, you can try it. No idea if it will work on your data though.

which basically mans it’s a one way operation according to the www.ads-software.com Tech Guy.

Thanks for your reply, but:

WordPress doesn’t require utf8mb4, nor does switching to utf8mb4 cause any problems, so I’m not sure what you’re so upset about.

I didn’t say that WordPress “requires” utf8mb4 and it is simply your opinion that WordPress forcing an update to utf8mb4 doesn’t cause any problems, which seems to fly in the face of real-world experience by real-world users.

The issue is that once your WordPress site has been forcefully “upgraded” to utf8mbr on a server where MySQL happens to support that you can then no longer migrate that site to another server where the MySQL version does not support that using standard procedures that people have been using for years. You don’t call that a problem, what do you call it then?

And by the way, a “www.ads-software.com Tech Guy” states that you can’t go back from utf8mb4 to utf8 (or do you know otherwise in which case care to share how to do it safely, reliably and 100% guaranteed not to cause any problem under any conditions) and you certainly can’t do it just by changing the table definitions, you already stated that yourself.

If you’re moving to a hosting provider who is offering a version of MySQL lower than 5.5.3 (which was released in March of 2010 by the way), perhaps you should consider not moving to that host.

With all due respect did you actually read what I said? For your average workaday WordPress developer trying to scrape a living they often do not get a choice about their clients hosting. I don’t disagree with you that hosts _should_ have up to date MySQL versions but you know what, they don’t and trolling out the trite “solution” of moving to another host just isn’t a “solution”, it’s just an excuse to try and avoid a issue that has been caused.

So, as I said, do you want to go head and contact all the hosts out there and tell then to get a move on and update their MySQL versions. Or maybe you want to explain this to all those clients of workaday WordPress developers who have what you consider to be “outdated” hosting that that they need to change their hosting because WordPress has forced it upon them for no god reason they will understand.

Oh, and if you are so sure about this why not have www.ads-software.com “force” users into using PHP5.4+ rather than still passively (or even actively) encouraging them to not bother with having to use an up to date and supported PHP version by having WordPress still support PHP5.2? Consistency don’t you think?

So I’m not “upset” about anything (haven’y you ever encountered anyone just putting across an argument/point in a forthright manner) but I don’t know why you are so lackadaisical about something that is clearly a problem that you seem to fail to grasp based on your “misunderstanding” of my post.

Sure enough WordPress is a popular application and that is due in no small part to the dedication of many and it’s popularity gives those in “control” much power _but_ with power comes responsibility and in this case the responsibility is to consider the users and their day to day requirements for the use of WordPress in the real-world – unfortunately they have taken their eye off the ball here and they will be doing a great many people a great service by doing the right thing and fixing the problem as caused and making this “upgrade” optional and providing a “reversion” path for anyone adversely affected thus far.

Thanks.

That is not a “solution” but just a hack to try and workaround a bad design decision to force the use of utf8mbr on users who neither need nor want it.

That’s not exactly a WordPress problems, and it would be easier to upgrade MySQL on the server, to be honest.

Well intentioned I’m sure but it’s rather a “slippy-shoulder” response that doesn’t address the realities of life for the average workaday WordPress developer who often get no choice concerning their clients hosting – perhaps you would like to personally contact all hosts and tell them to update their servers?

There was absolutely _no_ need to _force_ this upon users, it _should_ have been an “opt-in” by ticking a box that could be done anytime along with a big warning of the implications for site transportability.

WordPress devs will be doing their users a great service by changing this to an “opt-in” and providing a non-hacky “reversion” for those already affected – not everyone wants to delve into the guts of their database to fix what shouldn’t have been broken in the first place.

Thanks.

Seems like a well intentioned feature but badly conceived implementation – a case of just because you can doesn’t mean you should.

How many users actually _need_ this and if anyone does need it then I’m sure they’d be happy to just have to tick a box to make it happen and also have that throw up big Warning about the implications as regards the future transportability of your site. Surely preferable to _forcing_ this onto the general WordPress user population whether they want it or not.

We know from the chatter above that this “conversion” can be done at _any_ time so there is absolutely no need to make it a “stealth” one-way upgrade is there?

I haven’t seen any good justification for why this has been forced upon the general WordPress user population and in fact I’ve seen some pretty wacky comments from a “Tech nerd what works on WordPress.oeg” (sic) about what users should and shouldn’t be doing as regards how they manage their site developments and workflows that would kinda suggest a certain lack of connectedness with real-world usage and may well be indicative of how this got slipped in without there being any true consideration of the potential impact.

So please WordPress devs, you are great guys and gals and WordPress is a great application but please consider your users and their real-world needs and seriously consider turning this into an _optional_ action selected through a tick-box for those that _need_ it (or want it just for the sake of it) and also provide a “back out” for those whose sites have already been affected through no fault of their own. It’s not too late to make this right.

Thanks.

Where the Apache documentation says:

Directives in the configuration files are case-insensitive, but arguments to directives are often case sensitive.

https://httpd.apache.org/docs/2.2/configuring.html

In this case order, allow and deny are directives and so as per the Apache documentation it shouldn’t matter what case is used. For the order directive the ordering argument also appears to be case insensitive as the documentation contain examples such as “deny,allow” and “Deny,Allow” – I suppose the documentation could have mistakes but such mistakes have been present for many years if that is the case.

So if there is a server where case matters then I would suggest that the issue lies with the server and not the .htaccess file content.

This is just based on a reading of the Apache documentation you understand and of course you are quite free to disagree and offer evidence of an alternative interpretation or perhaps newer documentation that changes this.

Regards

Seen a similar issue to this where the wp-settings.php had been changed so that the

// WordPress calculates offsets from UTC.
date_default_timezone_set( ‘UTC’ );

had a different default timezone set. This should never be changed from UTC.

It might also be that the setting made in the wp-settings.php file is being overridden, maybe by a another plugin.

Please note this is _independent_ of whatever may be set elsewhere in your Settings and that there are different mechanisms that can be used to determine the “current” time – all are perfectly acceptable _provided_ the underlying data is consistent.

Regards

What a hacker can do with a file is more determined by what access they have to the parent directory. If they have access to and the necessary permissions for the parent directory they can still manipulate a file within that directory even if the file itself has read-only access. For example, you can read the content of the file, delete the file (even though the file itself has read-only permissions) and then create a new file with new contents (based on the original contents that were read) and set the permissions to read-only again. But you couldn’t append (wtite) to the _existing_ file because it doesn’t have write permissions. Slightly confusing you may say but that’s how it is.

You might want to look at the timestamps on the file to see when it is being changed and that may help you correlate it with other activity on the site. You may well have to involve your host support in this.

Probably what you need to do is determine how the hacker is gaining access to the site, e,g, it could be through another compromised site on the same server in which case they are not breaking into your site “through” the site interface but rather through the server itself and that is not really something that any security plugin can protect against.

May not directly resolve your problem but I hope that gives you an idea of how things are not always as straightforward as they may seem as regards file ownership/permissions.

Regards