and fixed wiki versioning test
Rails 5.1 last steps
crabgrass_media from rubygems
remove controller test for task sorting - not possible to test xhr request without route in new parameter syntax
remove new framework defaults initializer file
Final step of upgrade to rails 5.1
we only test on stretch, because we need ruby >= 2.2.2
update dependencies by running bundle update
and fix gallery_image_controller_test
Also write db/schema.rb with rails 5
to make database indexes fit after conversion to full utf8, the db forces
us to shrink the size of the varchar fields which are part of those indexes.
before doing so, we had to make sure that the content in this fields does not
exceed 191 characters. we used a rake task to shrink long legacy tags.
remove tables hourlies, dalies, trackings
remove column views_count from pages and page_terms
remove views_count from fixtures and a test
remove views_count from sphinx index
- remove unused name fields and birthday
- remove legacy permissions which have been replaced
by castle_gates_keys long ago
- remove migration test for users and groups
We were rewriting the alias_method_chain for setting in user...
but we are not using settings at all.
Inspecting them in production showed that the only fields that
differ from defaults are not used anymore:
```
User::Setting.last.attributes.keys.select do |key|
User::Setting.group(key).count.size > 1
end
["id", "user_id", "show_welcome", "created_at", "updated_at", "preferred_editor"]
```
(this finds all attributes that differ accross instances.)
Neither show_welcome nor preferred_editor are used anymore.
We used to allow a LOT of configuration via sites and Conf.
This developed out of the need to create working instances for
different interests. Now this is no more the case and we can
finally drop the associated complexity.
The need to persist site settings in the database is also gone
since the is no UI for changing them anymore. Instead they can
now be applied via configuration files only.
While i ripped out a lot of complexity and brittle code i kept
a basic destinction. Some config settings are accessed via
Conf
others in the controllers and views via
current_site
This will still allow us to customize ui and to some extend
behaviour based on the domain of a request. It will NOT serve
however to run two completely different sites on the same install
though.
We used to have app/models/activity in the autoload path and had classes
like FriendActivity < Activity
This conflicts with how rails4 handles class lookup. Plus it clutters the
autoload path and makes it harder to find classes.
Using proper namespaces instead now and I'm about to apply this to all the
different namespace avoiding things like ...Extension. We can use classes
as namespaces as long as we:
* make sure to define things inside the namespace in one line or in a
class instead of a module block:
```ruby
class Activity::Friend < Activity
# or
class Activity
class Friend < ::Activity
```
* have names inside the namespaces that do not conflict with global names
The second one is important because if PrivatePost is already loaded and
Activity::PrivatePost is referenced somewhere it will be found as an
constant inside the Object namespace of Activity (since Activity is a class).
So instead of loading Activity::PrivatePost we'll see a warning that global
constant PrivatePost was referenced by Activity::PrivatePost.
So how do we prevent this?
* do not clutter the global namespace
* use more specific names in other namespaces
-> in this case i am renaming PrivatePostActivity to Activity::MessageSent
and not Activity::PrivatePost
TaskLists used to be an empty table that linked pages and
their tasks together:
* page.data -> TaskList
* task.task_list -> TaskList
This commit removes the TaskLists entirely. Instead tasks
now belong to the page itself. TaskListPages have no more data
set.
This cleanup removes an intermediate class we never really used anyway.
In general i plan to move away from relying on the polymorphic page
belongs_to data. Instead data belongs_to page and only the page types
it's relevant to have the corresponding has_many associations defined.
This allows for much more flexibility in attaching data to the page.
InnoDB allows us to perform non blocking backups with transactions.
So we convert all the tables that remained as MyISAM tables to
InnoDB except page_terms which need the full text search capacities
that InnoDB only gained with mysql 5.6. (we're still on 5.5).
trackings were actively using "INSERT DELAYED" which also is
MyISAM specific - but will be removed in this commit as well.
The mysql docs say:
> Note that INSERT DELAYED is slower than a normal INSERT if the table
> is not otherwise in use.
So it very much looks like premature optimization.
The other tables just happen to still be MyISAM in production
has_secure_password uses bcrypt which is far better at hashing passwords
than sha1.
In order to profit from the security gains of bcrypt without waiting for
all users to login again so we can encrypt their plaintext password we use
bcrypt(sha1(password, salt)) as an intermediate step. This allows us to
simply bcrypt all existing hashes. We obviously need to keep the old salt.
When a user logs in we calculate the old hash like before and then use the
password comparison of has_secure_password.
If the password worked we also rehash it with plain bcrypt and remove the old
salt from the database. This way we can tell how a password was hashed by
looking at the salt of the record.
Once all users have logged in or their accounts have expired we can remove
these hacks.
ATTENTION:
* migration required
* rake task cg:upgrade:secure_password required
dgt