Settings.php, database update, caching, hostname lookup, editing controls

[Kindred]

I agree... Which is why I am now badgering the main complainers to do something and contribute.

[MrPhil]

OK, challenge accepted. I will submit a fix for one of the ones I listed. Is there a post somewhere listing how to sign up on Github, how to use it, how to submit changes, etc.? Then we'll see how bad the politicking is and whether it gets accepted quickly. Is everything in Github going into 2.1, or are 1.1.18 and 2.0.4 also in there?

Before I go through the labor of all this, is there any place to discuss specific proposed fixes/features and find out ahead of time if they'll be rejected for whatever reason? Pardon me for sounding cynical, but I've heard so many horror stories about perfectly good fixes and features being rejected for trivial (read: political, personal) reasons that I want to know what I'm getting into before I invest the time in it.

For earlier versions of SMF, I'm willing to do the same fixes as a mod. Again, are there concise guidelines somewhere (how to build and submit a mod)?

If I have good results on the first fix, I'll consider doing other ones.

[MrPhil]

10. Questions and Answers feature, allow multiple correct answers (e.g., Q: "What does a Sanitation Department truck pick up?" A: "garbage", "trash", "refuse", "rubbish", "discards", ...).

11. Questions and Answers feature, randomly pick the input method from text entry ("fill in the blank"), selection (drop-down) list, radio buttons, check boxes, to confuse robots looking to fill in a specific response field type. This of course requires that the Admin supply a number of plausible but incorrect answers for each question, of which a few will be selected, and they will be supplied in random order.

[Arantor]

Is everything in Github going into 2.1, or are 1.1.18 and 2.0.4 also in there?

As I understand it, 1.1.x and 2.0 are still managed by SVN while 2.1 is in Github. 1.1.x and 2.0 are also only getting *major* fixes because it's not viable to push out releases with many bug fixes in.

For earlier versions of SMF, I'm willing to do the same fixes as a mod. Again, are there concise guidelines somewhere (how to build and submit a mod)?

I'd be prepared to help with that. Essentially it's just creating a pair of XML files that describe the package and that describe the find/replace operations to be carried out.

[Kindred]

This is the details that I have on it...

With this post we would also like to start involve the community into the main development process in two ways: first officially presenting our public repository. As some of you may already have noticed, the main repository where SMF 2.1 is being developed is now publicly available at github: https://github.com/SimpleMachines/SMF2.1 That means anyone can see the code, fork it and send pull requests with new features or bug fixes.

I have asked the dev folks if there is any more detailed set of instructions...


and it looks like github has an issues list where things are discussed along with linking to the submitted fix
https://github.com/SimpleMachines/SMF2.1/issues

edit
The readme on the front page of the repo contains a short and sweet summary of how to contribute.
https://github.com/SimpleMachines/SMF2.1#readme
Of course there are many things to know about git and github, but for that there is google.

The three things that are usually forgotten are:
1) send pull requests to the correct branch (release-2.1 bug fixes, development new features, etc),
2) sign-off
3) line ending in unix style

[MrPhil]

Is everything in Github going into 2.1, or are 1.1.18 and 2.0.4 also in there?

As I understand it, 1.1.x and 2.0 are still managed by SVN while 2.1 is in Github. 1.1.x and 2.0 are also only getting *major* fixes because it's not viable to push out releases with many bug fixes in.

That's extremely disturbing news, if it means that 2.0 and 1.1 are essentially closed off to fixes for major bugs. Some of the bugs I want to fix once and for all are, frankly, catastrophic: Settings.php emptied out crashes a system hard, and may require much effort to bring up a new Settings.php, difficult to do for neophytes. Malformed backups cause massive data loss, and while my fixes will reduce the problem, I can't guarantee perfect backups (especially if PHP is timing out, leaving an incomplete backup). The best course of action would be to disable SMF Admin backups -- are there really sites out there with no phpMyAdmin or other backup utilities (dependent solely on SMF's backup)? There are other, somewhat less serious, problems such as the scary "your database may require an upgrade" that ought to be dealt with, even on the older branches. If caching is not to be repaired in 2.0, it should be disabled, or at the very least, default to turned off on new installations. The rest of the stuff I've listed are new features that can wait for 2.1, or possibly be mods.

For earlier versions of SMF, I'm willing to do the same fixes as a mod. Again, are there concise guidelines somewhere (how to build and submit a mod)?

I'd be prepared to help with that. Essentially it's just creating a pair of XML files that describe the package and that describe the find/replace operations to be carried out.

Hmm. If I make a mod to fix bugs in 1.1 and 2.0, could that be used to introduce the fix into the SVN code repository?

[Arantor]

Yes, if you make a mod to fix bugs, it's not a huge task to add that to SVN from there (install SMF from SVN, install mods, commit changed files)

Some of the bugs with caching are in the realms of impossible to prevent though - mitigation is possible but proper prevention isn't. I don't understand why a file_exists should return true for a file, only for the *very next line* being the require then failing. I can only imagine that it's passing the test from the statcache but it's somehow removed in the very small window that is the life of the statcache.

[Antechinus]

That's extremely disturbing news, if it means that 2.0 and 1.1 are essentially closed off to fixes for major bugs.

The policy has always been that stable branches only get fixes for security exploits. IOW, you're probably plum out of luck.

[Arantor]

Well, the PayPal fix in 2.0.3 isn't security related, so it's not outside the realm of possibility. But it IS somewhat unlikely.

[vbgamer45]

That's extremely disturbing news, if it means that 2.0 and 1.1 are essentially closed off to fixes for major bugs.

The policy has always been that stable branches only get fixes for security exploits. IOW, you're probably plum out of luck.

That is sad I think that is a bad policy simple bug fixes should be allowed. I tired to do that when I was on the team but they were all rejected for 1.1.x line.

[emanuele]

TBH: the definition of "simple" is subjective.

Yep, the paypal fix was not for a security issue. But it was a fix for a completely, totally, undoubtedly broken functionality (in few months).

Don't tell anyone: I slipped in also a couple of other minor not security related things...

Though there are at least two things to consider:
1) many people don't even install security fixes, what would be the percentage of people installing a patch that "just" fix a few bugs? Probably not many (I'm not sure if I would install it...meh I would install it just to not have issues with any future security patch), may be just those experiencing the issue,
2) more importantly, the more the changes, the more the likelihood the patch doesn't apply on modded forums. Of course it would apply on a clean one, but then we'd get complains from admins that would have to uninstall all their mods "just" for bug (not security related) fixes.

Some of the issues you are discussing here (or have discussed in other topics)  are already fixed (or have some kind of workaround applied) in the development branch, so a "slightly" faster release cycle would make much more people happy than patches for "old" versions.

Anyway, anybody can release a mod to fix issues, nobody prevents that. I think there are few on the mod site already

.

Yes, if you make a mod to fix bugs, it's not a huge task to add that to SVN from there (install SMF from SVN, install mods, commit changed files)

Have things in SVN doesn't mean the packages on the download site have these changes applied.

[Arantor]

Would these be the same 'simple fixes' that you admitted caused problems for you, vbgamer? Sounds like they might not be simple fixes.


Tell you what though, setting new installs to disable hostname lookups would solve some issues; you wouldn't have to patch it in the core because people can just change it themselves.

I'm even tempted to suggest that new installs should be UTF-8 by default, which again doesn't impact existing installs and doesn't require any patches.

[Antechinus]

Those are both good ideas IMO.

[MrPhil]

12. Calendar is not a fixed range of years, but ThisYear-M through ThisYear+N years. A floating window, in other words. This would prevent those error reports this forum is flooded with around every New Year of "help, my calendar won't accept this/next year's date!" M=-1 and N=+5 might be good defaults. 1970 and 2037 would be hard stops, due to how timestamps are  currently saved. When systems eventually go to 64 bit timestamps, those limitations can be removed. Reuse the existing calendar min and max year fields/editing (with changed labels), since they're useless; or assume any min/max value under 1970 is actually the new format (no one needs a floating window more than 1970 years into the future!). If made compatible with current min/max year data, it could be offered as a mod for versions earlier than 2.1.

• minCalendarYear < 1970, assume it's delta to current year (typically <= 0), otherwise is actual year
• maxCalendarYear < 1970, assume it's delta to current year (typically > 0), otherwise is actual year
• minCalendarYear (calculated or set) minimum 1970
• maxCalendarYear (calculated or set) maximum 2037
• minCalendarYear > maxCalendarYear: set maxCalendarYear to minCalendarYear

   

[Arantor]

The main reason for hard-capping years is to prevent search engines consuming too much bandwidth, by enforcing what years are available in the calendar, at least when originally set up. Having rolling years would not impact that, though.

Mind you, I'd also note that your observations are not entirely correct. There are users who use it for a roleplay context, with dates set far into the future. I've also even seen one person who used it for tracking their family tree, so it is not correct to say that 'no one needs x', when I have seen examples of it being used in a manner dissimilar to its original purpose. You could argue that these are sufficiently close to edge cases so that it doesn't matter that they would have to code it, but I'd argue that's not the way to go.

You're also relying on the assumption that any of it uses timestamps... it doesn't. The calendar uses date format, so almost any date from 0000-01-01 to 9999-12-31 can be represented. This is important because holidays are handled in this fashion using year 0004 with the month/day to indicate annual events that don't move.

Here's the other thing... if you enforce minCalendarYear as currentYear - 1, you can't then go back in time to review previous events in the calendar more than a year old, something that some communities do do.

Just because it offends your sensibilities, doesn't mean you should inflict them on others who happen to have different views to you.

[Arantor]

1. Done in 2.1.

2. Done in 2.1.

3. Done in 2.1.

4. It's always been optional but the number of incidents of it being a problem has actually reduced.

5. Edit controls have been available for a long time. Delete actually should use the same time control.

6. Done in 2.1.

7. Not done because this is actually very rare, and 2.1 has UTF-8 by default (but not exclusively so)

8. A find/replace could be good, but that requires some of the other functionality currently under development.

9. Not going to happen.

10. Done in 2.1.

11. Not going to happen.

12. Not going to happen.


I think we're done here.