Empty page callbacks should be able to be configured such that extra path arguments added to the end of the request will result in a 404, rather than returning the empty page itself.
Example:
I create an empty page with the path "foo". I use context to add a bunch of blocks to the body of the page on that specific path. If a site visitor happens to hit www.example.com/foo/bar, they will see an empty page, when really they should get a 404.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | empy_page-disallow-extra-args-reroll.patch | 4.75 KB | unleet |
| #1 | empty_page_disallow_arguments.patch | 4.99 KB | unleet |
Comments
Comment #1
unleet commentedHere is a patch against the current 7.x-1.0 release that does what I'm asking for. It adds a field to the database to store the new setting, and adds some checking to the empty_page_empty() function. The patch also adds an extra API function to retrieve an empty page callback's settings by path.
By default, when this patch is applied and the update function run, all existing empty page callbacks will be set to allow additional arguments, which is the current behavior.
Comment #2
Nick Robillard commentedI like the idea but it seems there is a problem with the saving of this setting. Are you able to toggle between enabled and disabled? The setting doesn't seem to be saving in the database for me.
Comment #3
unleet commentedNick: Make sure you run update.php after applying this patch. Since it's technically in testing, definitely backup your database first ;-)
Comment #4
Nick Robillard commentedI ran the updates and confirmed that the empty_page table has your new column "allow_arguments". However, it always has NULL value, and never changes after submitting the form, no matter if the checkbox is checked or not.
Comment #5
unleet commentedThat's... weird. It worked when I applied it against the current release version.
I'll pull the latest code from git and try applying this to it and see why this is misbehaving.
Comment #6
unleet commentedI can't reproduce the failure you're seeing, but I have an educated guess on why it's happening. Attaching a re-roll that applies cleanly against the current 7.x-1.x branch and has small change that might fix the failure you're seeing.
What I *think* happened is that the combination of PHP/MySQL we're running here writes a 1 into an integer column when told to write a boolean TRUE. That made my patch work perfectly when we tested it here. What I changed in this re-roll is that I no longer assume this works everywhere, and explicitly change the boolean TRUE into an integer 1 before writing it.
Nick: Please let me know if this change makes the functionality work for you now.
Comment #6.0
unleet commentedremoved unnecessary reference to "home page" in the example.