The Varnish control terminal is not responding at theme_hook_original on port

I'm getting the same error

Notice: Undefined offset: 1 in theme_varnish_status() (line 264 of /var/www/mysite/sites/all/modules/varnish/varnish.module).

I have recently updated the core to 7.33 don't know if that was the issue was fine before

I can confirm this is occuring as well. It appears to be related to the $status array containing the varnish server details as well as a reference the theme_hook_original.

Contents of the $status array as passed to theme_varnish_status():

Array
(
    [127.0.0.1:6082] => 1
    [theme_hook_original] => varnish_status
)

Same issue to me as updated to 7.33

I'm having same problem. Just wanted to confirm that I'm also using Drupal 7.33.

Following, I have the same issue as updated to 7.33.

I believe I have the same issue "The Varnish control terminal is not responding at theme_hook_original on port ." after I updated to Drupal 7.33

This seems to be due to the following change in Drupal 7.33

Added a "theme_hook_original" variable to templates and theme functions and an optional sitewide theme debug mode, to provide contextual information in the page's HTML to theme developers. The theme debug mode is based on the one used with Twig in Drupal 8 and can be accessed by setting the "theme_debug" variable to TRUE (API addition).

https://www.drupal.org/drupal-7.33-release-notes

I fixed it by adding this to the beginning of the function theme_varnish_status on line 261

if(isset($status['theme_hook_original'])) {
  unset($status['theme_hook_original']);
}

so it looks like this:

function theme_varnish_status($status) {
  if(isset($status['theme_hook_original'])) {
    unset($status['theme_hook_original']);
  }
  $items = array();
  foreach ($status as $terminal => $state) {

While unset will work for this, a more elegant solution would probably be to negate the item in the loop like so:

function theme_varnish_status($status) {
  $items = array();
  foreach ($status as $terminal => $state) {
  if ($terminal == 'theme_hook_original') continue;

Fixed, LobsterJonn's solution worked for me. Thank you.

Here's a patch file for #9.

I realize that this problem occurs with Drupal 7.33 only but when Drupal is eventually upgraded to 7.34 will this problem go away or will this continue to be a problem for all future versions of the Drupal core from 7.33 and higher for the current Varnish module?

This problem also occurs in 7.34. Patch in #11 fixed it for me.

Patch #11 worked for me as well in Drupal 7.34.

Had this issue on 7.33 and 7.34 and the patch from #11 solved it for me. RTBC?

Patch #11 works indeed; setting this to RTBC.

I can also confirm the patch worked me as well. Both 7.33 and 7.34.

Adding tag for core incompatibility, think that should be done?

I would most definitely say that this does not have a core incompatibility. The error is only appearing because of the core change mentioned in #8. However the error only appears due to iteration over the array. Everything still functions correctly without the patch. Fixing the error is a purely cosmetic fix.

Would it make more sense to have some validation for the server and port rather than specifically exclude a value?

If there were more than just the one additional key/value pair being passed to the function I might agree that it would merit additional code. However, given that we know the key/value pair will be passed with that specific key and it is the only key/value pair that is not a varnish server it wouldn't make much sense to perform validation on the passed data outside of what the function already does.

Two thumbs up for #11

While the patch in #11 does fix this particular issue, the underlying problem comes from an incorrect use of Drupal's theme system and the same issue could reoccur in future.

This patch mitigates the issue by correcting the way the theme system is used, and avoids having a 'magic string' check for theme_hook_original.

Having the same issue on Drupal 7.34

Patch #24 is working for me and I think it's the correct way to go. It will prevent any additional variables from causing issues in the future.

I haven't had a chance to apply the patch in #24, but it does appear to negate passing the additional theme variable this way and would be a better solution.

I can confirm the patch from #24 works well.

+1 for patch in #24, also in favor for that solution.

I was experiencing this on Drupal 7.34, running the Varnish module version 7.x-1.0-beta3, hooked up to varnishd version 3.0.2 revision cbf1284.

I've updated the issue summary with the information from the comments and the patch.

I've reviewed the code in #24 and I believe it to be the correct solution to the problem. It appears to conform to coding standards and the resulting code is clear. I have tested it on my site, it applies cleanly, and it works as-described.

I do not believe this change needs tests: it corrects problems with the way that this module uses the Drupal theming API, which is already well-tested in core.

I second @frankkessler's RTBC.

+1 for patch #24. More clean, and works just fine on 7.34.

Patch in #24 applies cleanly and fixes the OP's error. Drupal 7.34, varnish-7.x-1.0-beta3

+1 for RTBC. Patch #24 applied cleanly and corrected the issue. Drupal 7.34, varnish-7.x-1.0-beta3

another +1 - Patch #24 fixed the error message for d7.34, varnish 7.x-1.0-beta3 against varnish 3.x.

Patch #24 worked for me. Thanks for the patch.

I can also confirm that the patch #24 is ok, thanks markpavlitski.

- Varnish-7.x-1.0-beta3
- Drupal 7.34

I have contacted the module maintainer to check if help is needed to get this and other issues that is RTBC committed.

This is committed to latest dev, I will try to get a new release out in some days from now, need to take care of a couple other RTBC issues as well.

Thanks patch #24 worked for me :)

Hey! Great help for me. Patch attached to comment #24 helped me. Thanks a lot!!!

Will this ever be committed to the official version as we have to patch every time we download Varnish module?

@yngens2 - it's been committed. See comment #38.

#24 worked and helped me out. Hope to see this committed in next varnish update. Cheers

JamesOakley, however when Varnish module is installed with drush, the status page still shows "The Varnish control terminal is not responding at theme_hook_original on port ." error. Is drush pulling incorrect version?

It was committed on 17th March 2015, but there have been no numbered releases of the module since then.

So you'd need "drush dl varnish 7.x-1.x-dev", yes.

We could do with another point release of the module; I think there have been a few commits that could do with wider circulation.

Ca we have this pushed to a release please?

Setting this back to Closed

@esolitos - I, like you, would love the module maintainers to tag a new release of the module so that we can have this fix without having to use the -dev release. However, the way Drupal issues work, is that this issue is marked as "Fixed" once a patch has been committed to the repository, and then moves to "Closed" if no further problems occur after 2 weeks. We reached that point, so this issue is closed.

Re-opening this issue is not the way to ask for a tagged release. If you want to, you could create a new issue in the issue queue, make it a "Task" not a "Bug Report", link it to this issue, and request a new tagged release that incorporates this and other changes.

Just a little note to others, it is actually drush dl varnish-7.x-1.x-dev (with a dash between name and version), but apart from that it does take care of the problem.

drush dl varnish --select will let you choose a version interactively.

Hi!
Sorry to open but installing 7.x-1.0-beta3+6-dev doesn't solve the problem.
Notice: Undefined offset: 1 in theme_varnish_status() (line 264 of sites/all/modules/varnish/varnish.module). still appears.

oops.. seems like everything works without errors :)

Pardon me bumping, I still receive this error with beta4 (using 3.x).

Seems to be working fine with Varnish 4.x and 1.1 version of this module

Confirmed now, there seemed to have been remainders of a former setting somewhere in the DB. After a cleanup it really works.