Remove "Who's new" block from core

[quicksketch]

Relevant drupal.org issue: https://drupal.org/node/2020395

[quicksketch]

This issue would be great to get handled before layouts land in #86. Currently we have to port the block settings for this block, but if it were a view, there would be no settings at all and it would simply be part of the view config.

[ghost]

I'm trying to tackle this, but it's my first use of: Github (outside the issue queue), Backdrop, and the changes Backdrop ported from D8 (e.g. CMI)...

I've successfully forked the Backdrop repository to my own, and cloned it onto my server to get a working sandbox site. I've then created a view that mimics the core "Who's New" block, but have two problems:

1. Ideally, the view would have a filter for 'Last access: not NULL', however the 'not NULL' operator doesn't seem to exist in views for Backdrop (though it's in D7). Shall I create a feature request for this? Will this issue depend on that one?
   For the moment I've just set the filter to 'Last access: (> 1970-01-02 00:00:00)' :)
2. Now that I have a view, how do I make it part of Backdrop core?

[quicksketch]

Hi @BWPanda! Great to have you working on this issue. :)

The current filter will probably be okay. No one is going to be creating new accounts before the Unix epoch. ;)

Most likely you could skip the "filter" entirely, and just include the "sort", since I believe it'd be preferable to show even "old" users as "new" rather than an empty block if there were no new users (maybe not though, I suppose it's a matter of opinion). I'm fine with it either way.

So, to answer your question.

Now that I have a view, how do I make it part of Backdrop core?

There are two things you need to do. One is easy and the other quite difficult. First thing, just copy the configured JSON file file from your files/config_*/active/ directory, probably called "views.view.whos_new.json" (or similar) to the /core/module/user/config directory. Congrats! Now your new view will be installed automatically on new installs of Backdrop.

Unfortunately, then comes the hard part, which is providing an upgrade path for this block. If the block was enabled in D7, it should be enabled upon upgrading to Backdrop 1.0 via update.php. This means that you'll need to make a user_update_10*() function in user.install, which *recreates the view as an array then writes it to a config file. Then it will need to update the blocks table to modify the delta/module for all themes that had the whos online block enabled.

Let's start with just the first part and file a PR from there. I'll followup up feedback on what you have so far, then we can work on the upgrade path, which has a number of caveats.

[ghost]

Great, thanks for the assistance! Just posted a question in the meta issue which I'd like your thoughts on before proceeding: #151 (comment)

[ghost]

Ok, so the view is ready to commit, but git status says settings.php has been modified (I obviously had to add my database settings to get the site working)... Do I have to setup a .gitignore file, or is there another way to not include the settings.php changes in my commit?

[quicksketch]

So if you have accidentally committed your settings.php file, the easiest thing to do is replace it with a fresh copy, then commit the change (with settings.php back to the default) with git commit --amend. That will undo the change to settings.php in your commit. Then push to your remote with git commit push origin your-branch-name -f, with the -f to force the push.

Generally speaking, you can prevent this problem by avoiding the -a flag and instead specifically using git add core before your commits, avoiding committing anything accidentally in your files, modules, or the settings.php file.

.gitignore can't ignore a file that's under version control (apparently), so you just have to avoid using -a instead of ignoring the file.

[ghost]

Nope, all good. Was just checking before I made any commits. I learnt git using Drupal, so only ever really committed everything in the directory (e.g. module, theme...) Didn't think to just not add what I didn't want :)

[ghost]

For the record, regarding my comment above for the 'Last access' filter, Backdrop does have the 'Is empty (NULL)' filter, but it only applies to fields that can be NULL (as set in the DB). Users.access cannot be NULL, hence you can't use the 'Is empty (NULL)' filter.
It seems the best solution is what I did above by setting the last access date to be greater than something.

[ghost]

@quicksketch In looking at other default views to see how/why "module": "user" should be added, I realised that all the other default views are provided by the Views module... Should this one be provided by Views too (as opposed to User), or should the others be moved to their respective modules?

[quicksketch]

Views module is only providing the current ones because that's how they came over from the D7 port.

Should this one be provided by Views too (as opposed to User), or should the others be moved to their respective modules?

The views should be moved to their respective modules. :)

[docwilmot]

Hi, as you may have noticed, I started the conversion of the new content block. I noticed your comments in last weeks Hangout re the upgrade path missing. I've been finishing my dissertation; its gone off to be crucified now, so I'm free and would like to get back on this.
I am a bit unexperienced as well, so would appreciate some direction about the upgrade paths. Dont quite get the concept you describe just now though about recreating it as an array?

[jenlampton]

@docwilmot I added some docs to the meta issue about how to approach upgrade paths. #151 I hope that helps :)

[ghost]

Forgot to remove the hard-coded block...

[ghost]

Considering this discussion about dropping blocks such as "Who's Online", I'm wondering if this "Who's New" block is useful or should it be dropped too? (I've personally never used it...)
Again, the (few?) users who do use this block can create it themselves in Views.

[jenlampton]

As per #148, I think we should remove this block from core. (This is not a feature that benefits the 80%.)

At this point, we're running out of time to port things to views, and even though it's pretty "easy" to build the view, the upgrade path complicates things a little. Our time would be better spent on things that have a bigger impact on our users than these two blocks :)

[quicksketch]

I posted a response over in #148 (comment) as well.

The PR to remove this block at backdrop/backdrop#591 looks good to go to me.