seanr’s picture

I can verify this works well, but I think we'll want some additional people to test it.

codi’s picture

The patch applied cleanly and i'm able to run "drush hd views" for instance and it comes back perfectly. I'm not able to run hacked-list-projects though.

call_user_func_array() expects parameter 1 to be a valid callback, function 'hacked_build_report_batch' not found or invalid function name

Any ideas?

codi’s picture

Issue summary: View changes

link to issue

codi’s picture

Cleaned up the patch and it's working for me now. Would like some other eyes on if possible.

FluxSauce’s picture

5.57 KB

codi, that patch really didn't work for me at all, and it removed out a lot of logic that was used to get it working in the first place.

What version of drush are you using? I'm currently using Drush 5.9. Did you test that by installing hacked into ~/.drush/commands and not into the target site?

I updated my patch to fix a bug where drush would barf if the Drupal core update module wasn't installed.

FluxSauce’s picture

Is there anything that I can do to help this along? I'd really like to get this integrated with Site Audit!

Steven Jones’s picture

I guess this just need some testing by me to see if it still works!

Steven Jones’s picture

Status: Needs review » Needs work

This doesn't quite work as far as I can see.

When running via drush I get the following:

$ drush hlp
Rebuilding Hacked! report
call_user_func_array() expects parameter 1 to be a valid callback, function 'hacked_build_report_batch' not found or invalid function    [warning]
call_user_func_array() expects parameter 1 to be a valid callback, function 'hacked_build_report_batch' not found or invalid function    [warning]
usort() expects parameter 1 to be array, null given                                                                 [warning]
Invalid argument supplied for foreach()                                                                             [warning]
 Title  Name  Version  Status  Changed  Deleted 

If I place the hacked module into the Drupal codebase, then it does work, but if the module is installed as a Drush extension, then it doesn't.

FluxSauce’s picture

Steven - which patch # did you use?

Steven Jones’s picture

codi’s picture

FluxSauce, are you able to give me some more details on "that patch really didn't work for me at all, and it removed out a lot of logic that was used to get it working in the first place place."?

Did the patch not apply, or did the drush hacked command not work. Did it produce any errors?

codi’s picture

Status: Needs work » Needs review
7.25 KB

Ok, maybe I got it. The file argument for the batch operation wasn't working. It was prepending the root of the site you call the command from to the root of the hacked drush commands directory, eg. /var/www/sitename//usr/share/php/drush...). What I've done for now is removed the file argument and made a _drush copy of hacked_build_report_batch and put that directly into the file.Most of the other modifications are from FluxSauce's previous patch, but redone against the latest from hacked's git.

It would be great if someone could test this one out.

Jaesin’s picture

Still applies to 7.x-2.x but need to get rid of: drush_log(print_r($operations), 'warning');

codi’s picture

Sorry about that. Here's a new patch with the line removed as well as an interdiff.

seanr’s picture

Unfortunately, if you've got a site that already has hacked in it's module base, you'll get a fatal with this. Anyone have any idea how to get around that?

codi’s picture

Would it make sense to just remove it from the site?

FluxSauce’s picture

Assigned: Unassigned » FluxSauce
Status: Needs review » Needs work

Hey all, sorry for the delay in response. A lot of stuff's been going on with site_audit and other kinds of stuff.

As of site_audit v1.9, there's now a framework for extending it and adding custom reports.

I'm going to take another swing at this using the new mechanism and try to iron out all the little bugs and nuances, including the use case where hacked is installed within drush and within the site.

FluxSauce’s picture

Title: Do not require hacked to be installed to use drush command, use drush cache » Integrate hacked with site_audit & allow hacked to be installed globally
Status: Needs work » Needs review
20.45 KB
17.66 KB

Major overhaul!

  • Allowed hacked to be used without being enabled
  • Allowed hacked to be installed globally (avoids redeclaration of functions)
  • Integrated hacked with site_audit
  • Applied coding standards to and cleaned up

Thanks to all for their feedback, code (especially codi) and review, really appreciated.

FluxSauce’s picture

If this is included, the commit comment should also mention for his original version of the site_audit integration in #2065513: Add Hacked! check :-)

Jaesin’s picture

I'm getting:

"Unable to determine whether core or contrib modules have been modified!"

hacked-list-projects doesn't have the --include-unchanged=0 argument.

If I add --strict=0 to line #79 of I get a list of hacked projects in my report without the unchanged modules listed.

$result = drush_invoke_process('@self', 'hacked-list-projects', array(), array('--include-unchanged=0', '--strict=0'), FALSE);
FluxSauce’s picture

20.46 KB

Thanks for the feedback, Jaesin, I've adjusted as recommended. I've also added a security report since the initial patch was written, so I've added Hacked! to the Security report instead of codebase.

greggmarshall’s picture

I just used the patch from #20 against a git clone, aka the dev branch, and installed the resulting patched files into my home/.drush directory, cleared caches, and used that to
a) try the hacked (hd) command and it found the changes I expected (we have a patched version of core to support our proxy for https traffic)
b) use the site audit (aa) command, although while it executed hacked (I presume) I got the result "Unable to determine whether core or contrib modules have been modified!" Not sure why that happened, it appears that #20 incorporates the --strict=0 from #19, although I found that at line 79 of and not, which I assume was a typo in the comment above.

So I tried just "drush hacked-list-projects" and got the error message
PHP Fatal error: Cannot redeclare hacked_reports_hacked() (previously declared in /sites/all/modules/_development_d7/hacked/ in .drush/hacked/ on line 21 which is documented in #14. I removed the hacked module from the site's module directory and the hacked-list-projects and site-audit commands worked fine. Is there no way to test if a module is installed in drush?

FluxSauce’s picture

Re: #21 - I can't replicate the aa failure.

jpeck@:~/Projects/broken$ drush hd panels
Details for project: Panels
Total files: 186, files changed: 1, deleted files: 0

Detailed results:
 Status   File
 Changed  panels.module

jpeck@:~/Projects/broken$ drush asec
Security: 54%
    The following extension(s) have been modified:                          [warning]
      devel v7.x-1.3: 1 line(s)
      drupal v7.25: 132 line(s)
      panels v7.x-3.4: 1 line(s)

Regarding the concern of redeclaring - the patch fixes it, but the site includes a version of hacked that doesn't check for the existing function, then that will happen and I don't think there's any way around it. What may make sense is to specify a new release if this patch is included, which will encourage people to upgrade and hopefully avoid that problem.

info999’s picture

I failed to apply patch to latest dev release:

; Information added by packaging script on 2015-02-19
version = "7.x-2.0-beta5+13-dev"
core = "7.x"
project = "hacked"
datestamp = "1424333282"

Applying patch:

$ patch -p1 integrate_hacked_with-2066371-20.patch 
patching file
Hunk #3 FAILED at 86.
1 out of 16 hunks FAILED -- saving rejects to file
patching file hacked.module
patching file
patching file
can't find file to patch at input line 617
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|diff --git a/includes/ b/includes/
|index 11c44fe..4cc3b7a 100644
|--- a/includes/
|+++ b/includes/
File to patch: 

Is patch incompatible with latest dev release?

FluxSauce’s picture

Status: Needs review » Needs work

Is patch incompatible with latest dev release?

Probably. I'll work on it.

rcross’s picture

This applies cleanly to commit 1fa55b3

The removal of includes/ in commit 794c51e (and other code rearranging) is what is causing the conflict.

Assuming we can reroll the patch to work, can the maintainer comment about what is holding back this patch from being committed?

FluxSauce’s picture

Status: Needs work » Needs review
19.97 KB

I've got some time again!

Security: 75%
  Menu Router: Check for potentially malicious entries in the menu router.
    No known potentially malicious entries were detected in the menu_router table.
  Hacked: Determine whether core or contrib modules have been modified.
    The following extension(s) have been modified:
      coder v7.x-2.5: 1 line(s)

Rerolled and aligned with the latest changes. Let me know if there's anything else I can do to help!

jcnventura’s picture

Status: Needs review » Reviewed & tested by the community

Patch #26 works for me.. Please add this functionality.

rcross’s picture

looks good to me.

colan’s picture

Status: Reviewed & tested by the community » Needs work

Looks like this is now breaking when run from the UI, over at admin/reports/hacked:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?id=13366&op=do StatusText: OK ResponseText: ( ! ) Fatal error: Call to undefined function hacked_load_dependencies() in /path/to/drupal/sites/all/modules/contrib/hacked/ on line 41 Call Stack #TimeMemoryFunctionLocation 10.0001243520{main}( )../index.php:0 20.07149387544menu_execute_active_handler( )../index.php:21 30.07169389072call_user_func_array:{/path/to/drupal/includes/} ( )../ 40.07169389304system_batch_page( )../ 50.07169389408_batch_page( )../ 60.07169390264_batch_do( )../ 70.07169390480_batch_process( )../ 80.07229423720call_user_func_array:{/path/to/drupal/includes/} ( )../ 90.07229423832hacked_build_report_batch( )../

I'm assuming only gets loaded when run through drush? That's where that function is defined.

colan’s picture

Version: 7.x-2.x-dev » 8.x-2.x-dev
4.12 KB

I thought it would make more sense to get this working in D8 first. The problem, however, is that I'm running into this:

exception 'Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException' with message 'You have requested a non-existent service "cache.hacked".' in /path/to/drupal/core/lib/Drupal/Component/DependencyInjection/Container.php:161 [error]

Stack trace:

  • #0 /path/to/drupal/template/core/lib/Drupal.php(299): Drupal\Component\DependencyInjection\Container->get('cache.hacked')
  • #1 /path/to/hacked/ Drupal::cache('hacked')

I think the problem is that the Hacked! cache service cache.hacked defined in was never set up because the module wasn't installed. Anyone know if there's a way to get to Drush to do so, without installing the module?

    class: Drupal\Core\Cache\CacheBackendInterface
      - { name: cache.bin }
    factory: cache_factory:get
    arguments: [hacked]

Maybe the service can be registered via ServiceProviderBase::register as described in Overriding services in Drupal 8 - advanced cases, but I'm not sure.

colan’s picture

Here's a D7 version that should be good to go; it works both uninstalled with Drush and installed from the Web UI now. Changes from #26:

Added the following stanza to

// Add missing dependencies if the module isn't installed.
if (function_exists('drush_verify_cli') && drush_verify_cli()) {

...and renamed hacked_load_dependencies() to hacked_load_drush_dependencies().

Leaving status as Needs Work for D8, even though this D7 patch should really be Needs Review.

colan’s picture

Assigned: FluxSauce » colan

Don't worry about #30. I just realized I was trying to use the Drupal cache instead of Drush's cache. Fixing...

dawehner’s picture

Well yeah to be clear about the problem described earlier. Services aren't loaded into the container, unless the module is installed. Maybe drush could provide its own dependency injection container, but I guess this could be tricky.

colan’s picture

Assigned: colan » Unassigned
Status: Needs work » Needs review
20.12 KB

I didn't get a chance to test this with Site Audit (even though the code is there), but I tested the following:

  • Running via Drush without module installed.
  • Running via Drush with module installed.
  • Running from the Web UI (module is installed obviously).
Alan D.’s picture

Latest 7.x-2.x-dev (3 Jul 2017) tarball was crashing using drush with the message

$ drush hlp
..... (cut)
Finished processing: Zen

Invalid argument supplied for foreach()

 Title  Name  Version  Status  Changed  Deleted

The patch from #26 resolved the drush issues, but the Drupal Admin UI functionality was fairly broken.