Skip to main content ↑ ↓
ElkArte 1.1 Final - Release announcement Started by emanuele · · Read 59399 times 0 Members and 2 Guests are viewing this topic. previous topic - next topic

Re: ElkArte 1.1 Final - Release announcement

Reply #15 –

Quote from: emanuele –
Quote from: b4pjoe – On #2 above....I created the clone of my site and replaced all files. Then when I go to my forum URL it runs install.php instead of upgrade.php. It appears it will do a full new install if I go that route. Should I manually point it to upgrade.php? Doing so does take me to the upgrade page instead of the install page. Should I continue on this way?
Sorry, probably I didn't explain it crystal clear: with "clone" I mean create a perfectly functioning duplicate with a different database and paths in order to properly test the upgrade before doing it "live". :)
It's always good practice to test before doing the real one, just because if something goes wrong for any reason, you don't even have to care about restoring a backup, you just wipe the clone and investigate the issue. ;)

ETA: sorry, I misread "#2" and thought it was #1... ::)
hmm... that's strange, it should bring you to upgrade.php, if it does not, just replace install.php with upgrade.php in the address bar.

OK I did that. A complete clone with a different DB. Made sure all paths were updated with repair_settings.php. Uninstalled all addons and reverted back to the default elkarte theme. Then manually pointed to upgrade.php and the upgrade proceeded and completed. Going straight to the forum produced a lot of giant icons all over the front page but clearing the browser cache and reloading the page cleared that up. All looks good now other than as you mentioned....old custom theme also produced giant icons everywhere. Looks like I will have to redo my custom theme.

Re: ElkArte 1.1 Final - Release announcement

Reply #16 –

The bigger the easier to see! xD
Bugs creator.
Features destroyer.
Template killer.

Re: ElkArte 1.1 Final - Release announcement

Reply #17 –

Quote from: emanuele –
Quote from: scripple – Now with object obfuscated code via the database.  Whee!
What you mean?
I mean the fact that the modules to call are now stored in the database and between the modules and their abstractions it was many files and in fact all the way back to Load and the install and upgrade scripts to figure out what was failing.  So the new structure has wonderfully obscured what the code does.

Quote from: emanuele – This should be according to what you have enabled at the time of the upgrade.
Well this needs a lot of work.  A quick grep for enableModules and disableModules shows only calendar and drafts can be turned on and off post install/upgrade.  So mentions, attachments and anything else is stuck.

Re: ElkArte 1.1 Final - Release announcement

Reply #19 –

Quote from: scripple – I mean the fact that the modules to call are now stored in the database and between the modules and their abstractions it was many files and in fact all the way back to Load and the install and upgrade scripts to figure out what was failing.  So the new structure has wonderfully obscured what the code does.
Oh in that sense.
Yes, let's call it an experiment.
It's a kind of obfuscation, I agree, but it is a way to avoid having zillions of conditionals everywhere that obfuscate everything else.
At least each "feature" is in "one place" (yes, not yet, not entirely, but it's just a first step) and not spread across multiple controllers/subs/etc.

Quote from: scripple –
Quote from: emanuele – This should be according to what you have enabled at the time of the upgrade.
Well this needs a lot of work.  A quick grep for enableModules and disableModules shows only calendar and drafts can be turned on and off post install/upgrade.  So mentions, attachments and anything else is stuck.
This just needed me not to forget things. Again sh**t happens. I did a mistake. A huge one indeed[1], but the testing done up until now did not show it. You can argue you just tried an upgrade, well nobody tried that upgrade in that conditions.
The bug will be fixed, the 1.1.1 branch was already there, I created a 1.1.2 milestone and moved all the less-than-vital issues to it.
I think a release next weekend is possible to fix at least these important issues.
1 It's not the first, and it will not be the last.↵
Bugs creator.
Features destroyer.
Template killer.

Re: ElkArte 1.1 Final - Release announcement

Reply #20 –

Quote from: emanuele –
Quote from: scripple – I mean the fact that the modules to call are now stored in the database and between the modules and their abstractions it was many files and in fact all the way back to Load and the install and upgrade scripts to figure out what was failing.  So the new structure has wonderfully obscured what the code does.
Oh in that sense.
Yes, let's call it an experiment.
It's a kind of obfuscation, I agree, but it is a way to avoid having zillions of conditionals everywhere that obfuscate everything else.
At least each "feature" is in "one place" (yes, not yet, not entirely, but it's just a first step) and not spread across multiple controllers/subs/etc.
The same thing could have been accomplished without a "shadow state" in the database.  By shadow state I mean you now have multiple places in the database that store the (hopefully) same information.  And it's critical that they really do all store the same information to prevent breakage (like what's happening here).  That's a big hassle.

You could have the same code split but instead of storing a module string for each controller that uses the module you could have a simple check at the start of each controller.

if modSettings['attachments'] => run/load/envoke attachmentModule
if modSettings['drafts'] => run/load/envoke draftsModule

This model cuts down on these mistakes now and in the future. 

The current model is asking for trouble.  Modify a controller to use a module it didn't previously then forget to modify EVERY place where that setting is possibly enabled or disabled and things are broken.  Add a new place that changes the setting and don't update every controller string and things are broken.

With my model you don't have to remember to update the database for every controller that uses a given module when the setting is enabled or disabled.  You don't even have to know which controllers use which modules.  The database also can never be out of sync as the setting is stored only once.  This really is a good thing for stability.

Re: ElkArte 1.1 Final - Release announcement

Reply #21 –

Not sure I need to back up everything, since I keep the full site root in a Git repository, but I'll diff against 1.0.10 stock, then install 1.1, then apply the diff as a patch to see what I can salvage of our extensive random changes.

Re: ElkArte 1.1 Final - Release announcement

Reply #22 –

Quote from: scripple – You could have the same code split but instead of storing a module string for each controller that uses the module you could have a simple check at the start of each controller.

if modSettings['attachments'] => run/load/envoke attachmentModule
if modSettings['drafts'] => run/load/envoke draftsModule

This model cuts down on these mistakes now and in the future. 
Not really.
You just change the place you have to remember to do things (in addition multiplying it by having to repeat the check for each and every "extension" in each involved controller. And if an addon wants to expand a controller it has to add code to that spot (or you have to add a way for addons to add their code there.
And so on.

Also, since you are criticising the modules approach, I guess it's the same with hooks approach, because they "hide" their activation code into the database the same way.

Quote from: scripple – The current model is asking for trouble.  Modify a controller to use a module it didn't previously then forget to modify EVERY place where that setting is possibly enabled or disabled and things are broken.  Add a new place that changes the setting and don't update every controller string and things are broken.
I'm not sure what you mean here.
If a controller needs a module, the only thing to do is list the controller name in the list of controllers involved for that module. Done.
It's not even necessary to switch it on/off, you can leave it always on and forget about it (that's what I did for some of them.

Modules are basically hooks under steroids. Nothing more.
The point is to make anything that is not strictly "the action" to be run from an addon point of view (so "posting" is the "core", then anything additional (attachments, pools, post approval, notifications, etc.) and for that, hard-code it is not an option.
Bugs creator.
Features destroyer.
Template killer.
 

Re: ElkArte 1.1 Final - Release announcement

Reply #23 –

Yes I have issues with hooks.  They aren't all they're cracked up to be because utility functions move all the time and the way data is stored/serialized and where it is stored changes with every update.  So even though the hook may exist it doesn't actually work anymore.  Of course you can't find that out until eventually the hook trips the error.  If you really want hooks to be useful you have to commit to a stable ABI/API to go with them.  And carefully document when that changes.

This is all pointless though.  It's your project and clearly you've made up your mind the path of the moment.

Re: ElkArte 1.1 Final - Release announcement

Reply #24 –

Quote from: kode54 – Not sure I need to back up everything, since I keep the full site root in a Git repository, but I'll diff against 1.0.10 stock, then install 1.1, then apply the diff as a patch to see what I can salvage of our extensive random changes.
If you think some of those changes should be in the core, please let us know :D

Re: ElkArte 1.1 Final - Release announcement

Reply #25 –

Congrats on the release! Will check it and work on updating my sites to this new release!

Re: ElkArte 1.1 Final - Release announcement

Reply #26 –

You forgot the optional "two factor authentication" in the list of new features  :D
Anyways, great work and a big thank you to all the guys (and girls) involved..
Thorsten "TE" Eurich
------------------------

Re: ElkArte 1.1 Final - Release announcement

Reply #27 –

Ouch!
Good point TE!
Bugs creator.
Features destroyer.
Template killer.

Re: ElkArte 1.1 Final - Release announcement

Reply #28 –

Quote from: TE – You forgot the optional "two factor authentication" in the list of new features  :D
Anyways, great work and a big thank you to all the guys (and girls) involved..
I can't believe emanuele forgot to add that  O:-)  Its now been added here and on the release page.

Re: ElkArte 1.1 Final - Release announcement

Reply #29 –

I cannot tell you how cool it is that you guys keep plugging away at this. SMF should be doing a git pull from Elkarte if you ask me. :D

This is awesome. Two-factor is pretty cool. I'll have to check that out!

--Edit--

Ok I checked out two-factor.  Just a couple of things. The scan image would not work for my google authenticator. I had to manually enter the one time pass.  The other thing is the text box that the one time pass is in. Make it longer so the whole pass fits in the box without having to scroll. :)
Last Edit: October 24, 2017, 12:31:20 pm by IchBin
Success is not the result of spontaneous combustion, you must set yourself on fire!