SMF Development > Fixed or Bogus Bugs

[4981] [1.x, 2.0] handling MS Smart Quotes

<< < (3/9) > >>

emanuele:

--- Quote from: MrPhil on April 25, 2012, 11:47:36 PM ---It would be nice to give some assistance on mod installs/uninstalls where SMF can handle some of the files itself, but we need to prevent people from walking off with the job half done. It might be enough to refuse to take the forum out of maintenance mode (or otherwise unlock it) until they have answered "yes" or "no" to each "Did you successfully manually edit file ________?" Maybe add, "do you swear upon your mother's grave..."?? There's probably no automated way to check that the work was done (else it could have been done fully automatically). If they answer "no" to any question, refuse to unlock the forum until they agree to uninstall/reinstall the mod, and can answer "yes" to all.
--- End quote ---
And they will simply answer "yes" to all even if they didn't do anything at all...


--- Quote from: MrPhil on April 25, 2012, 11:47:36 PM ---Or, save a backup of each file affected by the mod, and restore all of them to completely roll back the action. If they say "yes" to a question, compare the current file to its backup, to see if something was done. There's all sorts of things that could be done.
--- End quote ---
And so people will come and complain "the mod doesn't install, I installed it, but the function doesn't show up, etc., etc., etc." negatively affecting SMF's image... ;)


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---Wow. Maybe I should try complaining about the other things that irritate me to no end!
--- End quote ---
Usually a fix is more appreciated, but a report is as well. :P


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---
* Fix or remove the SMF database backup
--- End quote ---
http://www.simplemachines.org/community/index.php?topic=474901.0


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---
* Really fix the Settings.php being emptied out problem
--- End quote ---
I don't remember the "final" decision about this for 2.1...


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---
* Get rid of the spurious "your database may require an upgrade" warning
--- End quote ---
AFAIR quite difficult...unfortunately.
Unless we get rid of them entirely.


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---
* Make mod install/uninstall either all or nothing -- refuse if ANY manual edits needed (most people ignore the manual edits) -- and validate that all changes were done properly (no more "undefined index" reports)
--- End quote ---
IMHO: a big no.


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---
* Ensure that version updates do the database update too -- there are far too many systems out there with way back-level databases (even if it's just the smfVersion entry)
--- End quote ---
AFAIR the SMF version is updated only where changes happen. So if during an update the database doesn't change the version is not incremented. But I may be wrong.


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---
* Make conversion between encodings foolproof -- too many systems end up half-way changed, or a mix of encodings in the database or language files
--- End quote ---
I would know what is needed to make it foolproof, maybe someone else has an idea?


--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---
* Fix the calendar so that the min/max limits are deltas to the current year (say, CY - 1 through CY + 5, with hard limits 1970 - 2037), or else automatically update the database, so we don't get reports that "I can't enter a 2012 event -- it's too far in the future!"
--- End quote ---
* emanuele thinks about it, but it could need a bit of changes...

--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---I consider all of these to be bugs, rather than enhancements, and they should be fixed in SMF 1 too!

--- End quote ---
Quite difficult they will be fixed for 1.x, we can fix some of these in 2.1, but even 2.0 wuld probably not be update with the relative "fixes".

MrPhil:

--- Quote from: emanuele on April 26, 2012, 05:30:04 AM ---And they will simply answer "yes" to all even if they didn't do anything at all...

--- End quote ---
True, but then they will be caught and their lies exposed when SMF compares the current file against the old backup. If they didn't bother to do any editing, the install/uninstall can then be rolled back, and the user informed why.


--- Quote ---And so people will come and complain "the mod doesn't install, I installed it, but the function doesn't show up, etc., etc., etc." negatively affecting SMF's image... ;)

--- End quote ---
Well, they were told why the mod didn't install (they didn't make the manual edits). If they want to ****** and moan after that, there's not much we can do. I think it's still better to refuse to install than to allow a half-assed job.


--- Quote ---Usually a fix is more appreciated, but a report is as well. :P

--- End quote ---
I do offer fixes on many of these -- see my sig, especially "Fixes".


* Fix or remove the SMF database backup

--- Quote ---http://www.simplemachines.org/community/index.php?topic=474901.0
--- End quote ---
Just for the record, K@ started that topic after we had a PM gripe session over all the long-festering SMF bugs.
* Really fix the Settings.php being emptied out problem

--- Quote ---I don't remember the "final" decision about this for 2.1...
--- End quote ---
I would hope that this would be addressed for all SMF versions, not just 2.1. Come on, guys, the fix is very simple!
* Get rid of the spurious "your database may require an upgrade" warning

--- Quote ---AFAIR quite difficult...unfortunately.
Unless we get rid of them entirely.
--- End quote ---
I offer a fix in my sig. It's probably more complex than need be, but the object is to remember which database levels (smfVersion) are acceptable for the current code version. We have both the code version and the database version available -- it's trivial  to keep the information somewhere (new function?) as to what database versions work for the given code version.
* Make mod install/uninstall either all or nothing -- refuse if ANY manual edits needed (most people ignore the manual edits) -- and validate that all changes were done properly (no more "undefined index" reports)

--- Quote ---IMHO: a big no.
--- End quote ---
A Big Yes. Something has to be done to keep people from partially installing mods (or uninstalling them) by ignoring warnings that they need to do manual edits.
* Ensure that version updates do the database update too -- there are far too many systems out there with way back-level databases (even if it's just the smfVersion entry)

--- Quote ---AFAIR the SMF version is updated only where changes happen. So if during an update the database doesn't change the version is not incremented. But I may be wrong.
--- End quote ---
If you're right, that's a stupid way to do it. If we're going to compare smfVersion to the code level and scare users with ominous warnings about mismatched version, we need to update smfVersion to match the code version. Otherwise, add code (see above) to allow still-working earlier smfVersion.
* Make conversion between encodings foolproof -- too many systems end up half-way changed, or a mix of encodings in the database or language files

--- Quote ---I would know what is needed to make it foolproof, maybe someone else has an idea?
--- End quote ---
I'm not sure about this one, but we need some ideas. I see far too many systems where they've got a random mixture of database encoding, language support encoding(s), and display page encodings. For later SMF versions (2.1 or 3.0), perhaps the best solution would be to simply mandate UTF-8 for everything.
* Fix the calendar so that the min/max limits are deltas to the current year (say, CY - 1 through CY + 5, with hard limits 1970 - 2037), or else automatically update the database, so we don't get reports that "I can't enter a 2012 event -- it's too far in the future!"

--- Quote ---thinks about it, but it could need a bit of changes...
--- End quote ---
The biggest problem would be to ensure that unchanged min/max entries (years) are interpreted as fixed years and not deltas (value >500, treat as year). Perhaps if the max year <= current year + 1, the admin could be prompted to change the values to deltas? It could even be done automatically, with an email to the admin telling what was done.

--- Quote from: MrPhil on April 25, 2012, 05:54:38 PM ---I consider all of these to be bugs, rather than enhancements, and they should be fixed in SMF 1 too!

--- Quote ---Quite difficult they will be fixed for 1.x, we can fix some of these in 2.1, but even 2.0 wuld probably not be update with the relative "fixes".

--- End quote ---

--- End quote ---
They're all serious bugs that greatly detract from SMF's base functionality and sully its reputation, and need to be fixed in all release branches. In most cases, acceptable fixes are quite trivial to implement. They may not be the most elegant code, but they do the job to keep SMF from failing.

MrPhil:
To add two more to the list before they slip my mind again...

* Consolidate hard coded permissions in one function, and during configuration find out if 755, 775, or 777 is the necessary permission for SMF to write to a directory (likewise for files 644, 664, or 666). If 777 is absolutely required, see about automatically changing it back to 755 after the upload operation is done.

SMF still has hard coded 777 directory permissions, which won't even work on some systems (e.g., running suPHP), and are often a security hazard. Let's get permissions straightened out to use the least expansive permissions for any case.
* With SMF 2 we seem to be getting lots of reports of problems with the SMF cache. It clearly has problems. Let's disable it by default until it can be fixed.
Hmm. how about a third:

* Adjust the CSS to put some vertical space between list items.

emanuele:

--- Quote from: MrPhil on April 27, 2012, 10:23:42 AM ---
* Consolidate hard coded permissions in one function, and during configuration find out if 755, 775, or 777 is the necessary permission for SMF to write to a directory (likewise for files 644, 664, or 666). If 777 is absolutely required, see about automatically changing it back to 755 after the upload operation is done.

SMF still has hard coded 777 directory permissions, which won't even work on some systems (e.g., running suPHP), and are often a security hazard. Let's get permissions straightened out to use the least expansive permissions for any case.
--- End quote ---
There are already 2 or 3 topics around in this board and is tracked in mantis.
There are a couple of ideas (don't remember if here or in some less public board), nothing definitive.


--- Quote from: MrPhil on April 27, 2012, 10:23:42 AM ---
* With SMF 2 we seem to be getting lots of reports of problems with the SMF cache. It clearly has problems. Let's disable it by default until it can be fixed.
--- End quote ---
I'm aware of 2 problems:
1) the "/" in the keys (reported and tracked, waiting for a fix);
2) the "random" (but not exactly random) broken cached files that *should* be fixed in 2.1, but we cannot be sure until we have it tested in a (multitude of) "real-world" case(s)...

Is there any other problem with the cache?

MrPhil:

--- Quote from: emanuele on April 27, 2012, 11:19:16 AM ---There are already 2 or 3 topics around in this board and is tracked in mantis.
There are a couple of ideas (don't remember if here or in some less public board), nothing definitive.
--- End quote ---
Fine, so long as progress is made and soon SMF is only using proper permissions (not just hard coded 777). SMF could do some testing at the top of installation, and build a permissions.php file to hold the defines. Something like

--- Code: ---<?php
// consolidate permissions in one place

define ('WRITABLE_FILE', 0664);
define ('WRITABLE_DIR',  0775);

define ('GENERAL_FILE', 0644);
define ('GENERAL_DIR',  0755);

define ('RO_FILE', 0444);
define ('RO_DIR',  0555);
?>

--- End code ---
and pull this in from Settings.php or something.


--- Quote ---Is there any other problem with the cache?

--- End quote ---
I don't know of specific problems, except that I see a lot of "file not found" reports in the support board. Emptying out the cache seems to do the trick, but SMF still needs fixing. If it isn't easily fixed, and doesn't speed up the system all that much, I'd just get rid of it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version