Block the enabling of the PHP module in an admin/modules form validation function

So, the idea would be to add a validation function to the form and then check for php or paranoia there, remove them if present, and do a drupal_set_message (or something like that)?

That makes sense to me. Would that be sufficient for your module?

Here is a patch which updates paranoia to work with module_filter (if it's enabled) and also adds a validation routine to disable modules defined in a new hook paranoia_disable_modules().

I'm trying to review this patch but it does not apply to the latest code in paranoia branch 7.x-1.x. Could you re-roll or ensure that it applies to HEAD?

Looks like the 7.x-1.x was updated since I rolled the patch. Here is a re-roll of the patch based on the current revision.

awesome, tried it out, works great with module_filter. i hope both this and #1983492: Paranoia risky permission removal shouldn't rely on form submission get committed soon!

The formatting is a bit wrong ( }else{ ) and the use of t is bad for translation AND presents a slight xss vulnerability.

I also made it so this patch will work even if something other than module_filter is responsible for mucking with the structure.

@thelee there are at least two things to review: whether it works and then the code. For the latter a good guide is https://drupal.org/patch/review - before marking something RTBC it's valuable to do a complete review of the code. It's not clear from your comment in #7 if you did review the code and missed these issues or if you just tested the functionality.

@greggles turning the else into 2 ifs was a good call, and thanks for fixing the t() call. I won't mark this rbtc since it's originally my patch, but I've verified it. @thelee, can you check this too? I'm anxious to get this patch in there as well.

Thanks!

Rerolled this for the latest dev version.

Docs nitpick.

+++ b/paranoia.moduleundefined
@@ -135,6 +143,15 @@ function paranoia_permissions_submit($form, &$form_state) {
+ * Implements hook_paranoia_disable().
+ */
+function paranoia_paranoia_disable_modules() {
+  return array(
+    'php',
+  );

The docblock says the hook is hook_paranoia_disable(), but the function name and the module_invoke_all in paranoia_module_validate() suggest it is hook_paranoia_disable_modules.

I would reroll the patch, but then I can't RTBC it.

@skwashd - this queue is not as rigorous on the rtbc rules as Core. Please go for it ;)

Docs nitpick fixed and re-rolled :-)

Have verified that the functionality of the patch works.

Looking at the code itself, looks like the issues were taken care of and can't see any new ones.

Thanks: timaholt, thelee, skwash - now committed http://drupalcode.org/project/paranoia.git/commit/128c30a

In some cases, the PHP module is needed on the site, but I still want to be able to use this module. I put a patch for the composer.

The patch in #18 defeats the purpose of this module. A site that uses that patch in composer but "has the module enabled" is bypassing the point of the module.