Problem/Motivation

This is a follow up issue to #3619190-8: Undefined variable $message_to_confirm in BlockClassConfirmBulkOperationForm::getQuestion()

However, I think you've pointed out another more annoying issue:

Why does the following URL not return a 404? 😅
/admin/config/content/block-class/confirm-bulk-operation/bogus_op/x/x/x/x/x/x

The bogus_op operation does not exist, so this page actually does not make any sense and there is currently no way to navigate to this page though the interface....

It probably slipped through the code cracks and since submitting the form on this page does nothing, I assume ... it just does no harm (?!). 😅

 

The page /admin/config/content/block-class/confirm-bulk-operation/bogus_op/x/x/x/x/x/x should probably not exist... There should be some kind of validation in the parameters to check whether the operation is supported.

Steps to reproduce

Open locally the page: /admin/config/content/block-class/confirm-bulk-operation/bogus_op/x/x/x/x/x/x

Proposed resolution

Look into refactoring: src/Form/BlockClassConfirmBulkOperationForm.php

and related endpoints: block_class.routing.yml
path: '/admin/config/content/block-class/confirm-bulk-operation/{operation}/{classes_to_be_added}/{current_class}/{new_class}/{attributes_to_be_added}/{current_attribute}/{new_attribute}'

There should be some kind of validation on the parameters to return a 403 or 404 for error cases, such as an undefined operation.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

dydave created an issue.

dydave’s picture

dydave commented

I've qualified this as a Task, since it is not really a "bug" in the sense it does no harm and does not prevent the proper use of the module.
It's more of a clean up task.