Notice: Undefined offset: 1 in views_block_view() (line 618 of views.module)

We had this error before and fixed it in dev some time ago.

If you say you can't reproduce it, we can't either :)

Just reproduced this in dev by deleting an existing view and block, and creating a new one with the same machine names.

Cool so please describe us how to reproduce it.

Just wanted to add that I am getting the same error. However, the error lay dormant for a while and I'm not sure what triggered it. I did not upgrade any module between today and yesterday.

Notice: Undefined offset: 1 in views_block_view() (line 614 of /sites/all/modules/views/views.module).

I think the steps to reproduce are
add a view machine_name_x as a block and make it visible (my view takes an nid as an argument.)
delete view machine_name_x
recreate view machine_name_x as a block and make it visible in the same location
move view machine_name_x to a different location.

May be that the problem lies in there? The message appears on each page of the site, probably because the view is not restricted to only appear on node/%nid pages.

Using 7.x-3.x-dev.

Tryed to reproduce this issue with a view called "block" but it worked fine.

@nagiek
Can you look into the block table and see how the id of this blocks looks like? Is it a md5 hash?

In general line 614 seems not be the current git version, but this probably doesn't matter

Yeah, appearing as an md5 hash in the delta column.

I also wanted to say that my earlier reproduce steps don't work and I have a hard time reproducing the error. Sorry I'm not more help.

Hi. Just in case it helps someone: I had a similar issue (although on line 623, maybe not exact same version of views). What happened is that a display got corrupted. I could not delete it from the interface so I deleted the row in the 'views_display' table. However, there was still a corresponding entry in the 'blocks' table, which was apparently giving me the error. I solved the issue by simply manually deleting that entry.

for what it's worth, in my case a module created through views as a block display was deleted, yet in the block table in the database was still existing with a "1" status (=block enabled). setting it to 0 fixed the problem, or at least made the notice disappear. now, i wonder why that block is still there if its views display does not exist any more.

I get this issue whenever I change the machine name of a view... any fix coming out soon?

I'm linking mine own version that was closed as duplicate of this one: #1223624: Notice : Undefined offset: 1 in views_block_view().
Also, when I was trying to checking up the database as per #13, I found some other strange behaviour that I created a ticket for it: #1224706: Changing a block name or machine name cause random reaction in the database. Maybe it's the cause behind all of this.

I've updated to the dev version of 2011-july-19 and the notice is still there.

I've also checked the database and there was a lot of old blocks that I deleted some time ago in the table ([drupal]_block... Some are active (status=1, and still set in a region). Some have humand readable delta, other MD5ish delta...

Also, I should have 3 views block in my second sidebar, but in the database there is 8 of them! Same thing in the content, I should have 6 of them, but there is 8 of them in the database. And for the deactivated one, I should have only 1, but there is 6 in the database! Basicly that make 12 blocks are in the database but deleted from my views!

I'm doing a clean up right now, but it seem pretty much all I can say for now. If something else come up, I'll update this ticket.

I can confirm that after deleting all blocks made by views in {prefix}_block table that was not linked to anything in views the notice disappear. So I guess, that mean a solution would be to keep the table clean of all the strange things that can happen as I described in #1224706: Changing a block name or machine name cause random reaction in the database and others I haven't seen.

Here is a patch which fixes the notice, but doesn't fix the problem, because it's impossible to reproduce it at the moment.

This version of the patch fixes the notice and fixes the actual problem as well.

Please test it.

NOTE: This patch hides old wrong values. So it can't rebring you old blocks, so please test it with new views/blocks.

I've just tested the patch.
What I did for testing is this:

• Modifing an existing View
• Cloning an existing View
• Creating an new View with only a block

In each of those Views (well, most of them as I try to not break my prod. environnement) I did this:

• Changing the name of the block
• Changing the machine name of the block
• Cloning a block and renaming the name and machine name from those set by default
• Creating a new block and changing the name and machine name from those set by default
• Disabling the cloned block
• Deleting the cloned block
• Deleting the View

From what I've seen, the notice doesn't show up anymore. However, I was looking at the database at the same time, I've noticed this thing. I think these might lead to the notice (or another one) or other errors in the future.

• Upon the creation of a new Block, you need to go on the block admin page to create the new entry in {prefix}_block table. Might be WAD or forced by drupal way of doing stuff though.
• Upon the creation of a new View or a new Block, the "delta" is set to something like {viewName}_{blockMachineName}.
• After modifying the machine name of the newly created block, the "delta" is transformed to the MD5 hash. However, this seem to doesn't affect block created with older version of Views, which keep the {viewName}_{blockMachineName}.
• When disabling a block in a View, the corresponding entry in {prefix}_block stay there and the block still shows up in the block admin page. However, the block disappear from the display on the website.
• When deleting a block or a view, the corresponding entry in {prefix}_block stay there, which may lead to error (like, for who knows which reason, creating a block with the same machine name for a view with the same name).

I leave the needs review for other people to test. I the mean time, I'll update to the 2011-july-20 version of dev.

Upon the creation of a new Block, you need to go on the block admin page to create the new entry in {prefix}_block table. Might be WAD or forced by drupal way of doing stuff though.

Yeah this triggers a block_rebuild. I think you don't need the blocks, unless you want to configure the blocks. Does this makes sense?

After modifying the machine name of the newly created block, the "delta" is transformed to the MD5 hash.

That's how it should be. Perfect

However, this seem to doesn't affect block created with older version of Views, which keep the {viewName}_{blockMachineName}.

That's from my perspective somehow hard to fix, because this old blocks aren't known anymore for views.
What it could do is to manually delete it from {block} when a view is deleted. That's a bug from my perspective of block_rehash.

When disabling a block in a View, the corresponding entry in {prefix}_block stay there and the block still shows up in the block admin page. However, the block disappear from the display on the website.

When deleting a block or a view, the corresponding entry in {prefix}_block stay there, which may lead to error (like, for who knows which reason, creating a block with the same machine name for a view with the same name).

See above.

Thanks, really thanks for this great review! All people here should model oneself on you!

I hope I'm not just lumbering into this, but on the issue I posted, I was told that my issue appears to be similar to this one. My issue is at http://drupal.org/node/1227904 . I've read the postings here and for some reason it's going a bit over my head. Here's the problem I'm seeing:

I cloned a view that includes a Block display, however that block display does not show up in the Blocks page, so I can't add it to pages.

For example, I cloned my "Recent News" view. renaming it "News Stream" and making some changes to the filter criteria etc. News Stream is nowhere to be found in the list of blocks.

I noticed later that when a view is cloned, it's machine name appears to stay the same. So, for example, I noticed that the machine name for Recent News page and block displays were view_page_1 and view_block_1, respectively. They were the same for News Stream. I changed them manually to news_stream_page and news_stream_block, in case the duplicate machine name was making the new block unable to be recognized by the Blocks functionality. It didn't fix the problem.

I have cleared the caches literally 20 or more times since I created this clone, in case that helped. It didn't.

Is this problem related and is there a fix for it?

For #22,
The problem doesn't look related, but with the symptom you describe it looks like the solution will be related.

If you can do again your cloning using the last dev version and watch in between each step the changes in your database in the table {prefix}_block (and maybe also in the tables related to Views, which I don't remember by heart the name). The first two step to watch the changes would be:

1. Cloning the View
   • Watch the tables
2. Going to the block admin (/admin/structure/block)
   • Watch the tables

After that, do whatever step you think is necessary to setup your cloned view and watch for any changes in the tables. I think the most important columns to watch are bid and delta.

bid: Look closely if there is any entries with the same delta, but different bid for a single theme.
delta: Look closely if it's a machine name or MD5 and for any changes.

PS: If you're using phpMyAdmin for watching the tables, use the research options and set module LIKE views and theme LIKE {name of your theme}. It will help to only watch the block affected by Views and on your current theme.

Once you've done that, if you can report your step and the thing you have noticed that seem odd or not working properly, just answer here! :)

On #21,

Yeah this triggers a block_rebuild. I think you don't need the blocks, unless you want to configure the blocks. Does this makes sense?

Yes, this makes sense. I'm not used yet to all the way of Drupal is doing stuff (but I noticed that there is a lot of *_rebuild stuff around!) it seem! ahah

That's from my perspective somehow hard to fix, because this old blocks aren't known anymore for views.
What it could do is to manually delete it from {block} when a view is deleted. That's a bug from my perspective of block_rehash.

Hum, I'm wondering, when you say "old blocks" do you mean deleted/disabled blocks (either directly or recursively by the View) or blocks created by older version of Views (like 7.x-2.x-dev or "last week dev version in 3.x-dev") but still active?

I'm asking because you answered that on a part (However, this seem to doesn't affect block created with older version of Views, which keep the {viewName}_{blockMachineName}.) that was applied to a block that is still very active and working in Views, so it's kinda strange to say that those blocks aren't known anymore for Views, but are still working and I can modify them, etc.

Although the answer makes sense if applied to the two last quote, corresponding to deleted/disabled blocks.

I'm having exactly the same issue as somatics.

I'm asking because you answered that on a part (However, this seem to doesn't affect block created with older version of Views, which keep the {viewName}_{blockMachineName}.) that was applied to a block that is still very active and working in Views, so it's kinda strange to say that those blocks aren't known anymore for Views, but are still working and I can modify them, etc.

Well but the error shouldn't exist on this kind of blocks?
Because the index is only then not existant if it's unknown to views...

Pretty new to Drupal. I hope this can help someone.

I had this error (notice) but the line reported was 623 in my case. It happened when I changed the machine name of the block. The problem was in that I also had a mini panel containing this block. When I reverted the machine name to previous value, the notice had gone. Then I removed the block from the mini-panel, changed the machine name of the block and reassigned the block into the mini-panel.

Obviously, mini panels link to containing blocks by their machine names and are not updated when they change. Maybe a Panels module issue?

If you get this error, try checking whether your block that should appear instead of notice message is referenced in some other part of your site.

(Drupal 7.7, Views 7.x-3.0-rc1, Panels 7.x-3.0-alpha3)

I'm having this issue as well. I deleted some content that made up a view.

I looked through my block table and can't find any md5 hashed values.

Are there any other solutions any one can think of? Mine is also on line 623

Edit:

I should have read the replies a little better, there actually was an MD5 hashed value in my block table under delta.

Just commited the patch as this fixes a somehow quite major bug.
Please create a new issue if there are new bugs on this topic

dereine
Thanks, this patch works fine for my problem "Notice: Undefined offset: 1 in views_block_view() (line 623 of views.module)"!!!

Do I use drush and enter the patch in the command line ?

@Andy1966uk check this guide out for information about how to apply a patch: http://drupal.org/node/707484

I was just having this issue also. I was adding a new view for a RSS feed when I received the following error message: Notice: Undefined offset: 1 in views_block_view() (line 623 of.......

Solution: Delete the views you created and then create a new block view. After you create your new block view, place it in a block region and then flush the caches.

Let me know if it works.

Good luck!!