Problem/Motivation

A non-Drupal user notes concerning language regarding module updates:

On the Home >> Administer >> Site building page, there's a real need for the present subjunctive.

It now says "It is important that update.php is run every time a module is updated to a newer version." That means "The following fact is important: update.php is run [ambiguous passive-tense statement] every time..."

If you want to say "You had better run it", change the "is" to a "be". Or just rephrase the whole line.

Proposed resolution

Ticket author noted:

Drupal knows when update.php needs to be run, so instead of just announcing the important fact that update.php needs to be run at the right time, it could not display the message at all when update.php does not need to be run and say "You need to run update.php right now because you upgraded modules X, Y, and Z" when it does need to be run.

Remaining tasks

We need to agree on the appropriate language for this notice.

API changes

As the patch has changes in text, any translations will need to be redone.

Screenshots

Update disabled

Before:

After:

Update enabled

Before:

After:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bjaspan’s picture

Component: update system » base system
Issue tags: +Usability

Tagging.

yoroy’s picture

Active and specific wording is always good.

"Update to apply the upgrades of modules X, Y, and Z."

Not great yet, but trying to get the "you put the new module files in place but you're not finished yet" in there.

brianV’s picture

Perhaps the following is better. In addition to more specific language, it also makes the user aware of the consequences of *not* running update.php.

'You must run update.php every time a module is upgraded to complete the upgrade. Failure to do so may result in broken modules.'

What may be best, from a usability perspective, would be to store the installed module version in the system table. When loading the module page, check if the version in the .info file is greater than the version stored in the system table. If this is the case, it indicates that a new version has been uploaded to the site, in which case we would display this using a drupal_set_message() warning.

Hmmm... I'd like some feedback on this idea. If it has a positive reception, I will implement it.

yoroy’s picture

Issue tags: +Needs text review

I'd like to hear which approach would bjaspan's friend help best. I think suggestion in #3 removes the part that explicitily "now" is the time you update etc.

birdmanx35’s picture

I endorse #3.

dbeall’s picture

Proposed in #3:
You must run update.php every time a module is upgraded to complete the upgrade. Failure to do so may result in broken modules

Maybe add a little why do we do it:

It is required to run update.php when a module is upgraded to keep the database up to date and complete the process. Failure to do so may result in broken modules or errors.

EDIT: I removed the first person as is in the handbook guidelines but keep the importance or urgency of the update action.

dbeall’s picture

Category: bug » task

shouldn't this be task?

brianV’s picture

Status: Needs review » Active
FileSize
2.69 KB

Patch attached to modify the wording. New wording is:

Each time a module is updated, you must run update.php to update the database. Failure to do so may result in broken modules or errors. To help manage the update process, the Update status module, if enabled, provides information on new versions of modules (and themes) as they are released. Regular review of the available updates page is essential to maintaining a secure and current site.

The bolding is to help show which portions have changed from the current text. The current text (for comparison's sake) is:

Each time a module is updated, it is important that update.php is run. To help manage the update process, the Update status module, if enabled, provides information on new versions of modules (and themes) as they are released. Regular review of the available updates page is essential to maintaining a secure and current site.

brianV’s picture

Status: Active » Needs review
yoroy’s picture

Status: Active » Needs review
FileSize
2.58 KB

"You must", "Failure to do so"… This is turning into very condescending language. As important as it is to run update.php, Drupal should not have to use this tone of voice to get the point across. Adding more words is not the way to convince people either. People don't read, they scan. Strategy should be to put the most important part first, use simple language and omit needless words.

I propose:

Run update.php each time a module is updated. It updates the database and prevents errors or broken modules. Use the Update status module to recieve information about new versions of modules and themes. Review the available updates regularly to keep your site current and secure.

dbeall’s picture

agree, sounds friendly and has added information.
I am not much on structured grammar..

Just a thought, Maybe condense it:

Run update.php each time a module is updated to update the database, prevent errors and broken modules.

Edit, that's not right, maybe:
Run update.php each time a module is updated to prevent errors, broken modules and update the database.

there just isn't a shorter way of saying it, thinking about the idea of people scanning instead of reading.

dbeall’s picture

unless, maybe taking out the broken part..

Run update.php each time a module is updated to prevent errors and update the database.

dbeall’s picture

Don't why i just keep getting ideas..

Run update.php each time a module is updated to prevent errors, update modules and the database.

it's up to you folks, I appreciate being able to participate. Drupal Rocks!

Status: Needs review » Needs work

The last submitted patch failed testing.

Tor Arne Thune’s picture

Version: 7.x-dev » 8.x-dev
FileSize
17.57 KB

Still a valid issue. Moving to 8.x, as no new UX changes will be committed to 7.x. See attached screenshot or the text below for the text displayed on admin/modules in 7.0.

Download additional contributed modules to extend Drupal's functionality.

Regularly review and install available updates to maintain a secure and current site. Always run the update script each time a module is updated.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Screenack’s picture

Issue summary: View changes

As part of the DrupalCon 2016 Mentored sprint, I am reviewing this ticket.

Screenack’s picture

Issue summary: View changes

The language essentially the same after this 5-year old comment;

Download additional contributed modules to extend your site's functionality.

Regularly review and install available updates to maintain a secure and current site. Always run the update script each time a module is updated.

My simple recommendation: change: "Always run the update script each time a module is updated." to "Always run the update script every time you update any module."

eporama’s picture

There are three places in code where this happens, once in system.module and twice in update.module.

In checking the Content Style Guide and other samples of text, especially in the system_help() the voice change does seem appropriate. I am attaching a patch for reviewing that makes the currently proposed changes so we have something to test and alter.

I am not including an interdiff because the text has changed dramatically from the previous patches due to changes from other issues.

eporama’s picture

As another point, many important actions are modified with "should" and I was wondering if "must" might be a more appropriate term for this. As an example, "must" is used only once in system_help to describe the need to run cron regularly:

In order for the site and its modules to continue to operate well, a set of routine administrative operations must run on a regular basis; these operations are known as cron tasks.

(emphasis added by me for demonstration).

The issue with changing to "must" is that there are, of course, instances when running update.php is not necessary (i.e., no modules made hook_update_n changes). In that case, running update.php does not cause problems, it will simply tell you that there are no updates to process. This makes me wonder what folks think of:

Regularly review available updates to maintain a secure and current site. After installing module updates, you must run the update script.

While it is not absolutely necessary, it is quite important for the script to run if there actually are updates and I could see that the emphasis could be more important than the technical outliers.

Screenack’s picture

Version: 8.1.x-dev » 8.2.x-dev

I made my patches against 8.2.x-dev, as the language is still present in this branch.

Screenack’s picture

I do not wish to step on eporama's fine work, but I do wish to submit my patch, if for academic purposes. I've read eporama's commit, and I prefer the language in that commit.

eporama’s picture

@screenack, thanks for continuing the work! I didn't realize you were looking to complete the patch process, so wanted to make sure your work was testable and committable. Our patches don't differ from what I can see (for anyone else reviewing this), so no disagreement here.

The last submitted patch, 20: improve_update_php-477356-20.patch, failed testing.

John Cook’s picture

Issue summary: View changes
FileSize
62.69 KB
62.47 KB
61.77 KB
62.96 KB

I've checked the patch and ensured that text is changed where appropriate. Screenshots have been added.

This will break translations as existing text is being changed.

John Cook’s picture

Status: Needs review » Reviewed & tested by the community

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 23: update-notice-477356-23.patch, failed testing.

The last submitted patch, 23: update-notice-477356-23.patch, failed testing.

eporama’s picture

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.