By dzynz on
I can still create and delete blocks, and change their settings, BUT I cannot move them from one region to another! Has anyone ever had this problem? Is their a solution short of migrating my installation?
I can still create and delete blocks, and change their settings, BUT I cannot move them from one region to another! Has anyone ever had this problem? Is their a solution short of migrating my installation?
Comments
1. Which version of
1. Which version of Drupal?
2. Make sure you are changing the settings for the right theme
3. Try going into the configure option for the block(s) in question and re-submitting. I had similar problem a while back on 5.1 and this helped.
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
It started in 5.2, I
It started in 5.2, I upgraded after exhausting options to 5.3. Tried changing options and yes, this is for the appropriate theme.
Do you have any control over
Do you have any control over which region a block is displayed in? What about new blocks? What about modules' blocks (e.g. user blocks, navigation blocks)?
May be worth emptying the cache tables. Also have a look in the blocks table in the DB to see if your settings are being stored correctly.
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
I cleared the cache
I cleared the cache repeatedly, tried turning off tabbed blocks and block cache. I can create blocks via blocks module, views, tabbed blocks, etc... I just can't move them.
Here is a weird part I tried dropping the contents of the block table and nothing changed. That's with clearing the cache at the same time. No errors even, and I could still edit blocks. I still couldn't move them, though. Really, really weird.
Does the content of the
Does the content of the blocks table look OK now?
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
No man, thats the insane
No man, thats the insane part, The table is empty and it still shows all the blocks on the site and even allows me to edit them. I have the table sql saved, but still some weird voodoo is going on. Im looking at building the site over from scratch just because it seems like there are too many possible database problems
The actual content of blocks
The actual content of blocks entered via the admin interface is stored in the table {boxes}. However, all blocks, i.e. these ones plus all the ones provided by modules, should be listed in the table {blocks}. Usually each block appears multiple times - i.e. once for each theme that is active.
Silly question but are you sure you are checking the right database??????? You could try temporarily renaming the {blocks} table and see if you get a horrendous error message ... (Do a backup first ...)
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
Ok, not answering that
Ok, not answering that question... but I have determined that it is views that is somehow the source of the problem. If I disable views (and the blocks therein) it works again...
I have been rebuilding the
I have been rebuilding the site on a new install and the problem has been replicated!
Here's where it gets weirder. I set up seven views with blocks no problem, but the eighth breaks it! Doesn't matter what the settings on that 8th view are, so long as it has a block view it breaks all the blocks ability to move!
How do the actual values
How do the actual values stored in the {blocks} table compare with the admin/build/block page and what you can see in your browser? When you try to update the blocks admin page, does the {blocks} table get updated?
Somewhere here I'd probably start looking in the Views issue queue or dust of my PHP debugger...
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
It all looks about equal,
It all looks about equal, but none of the values get updated.
I've also discovered that module blocks can put the freeze on too. It seems once a certain number of blocks (at least, non custom blocks) are introduced it freezes. It does this all themes.
It all looks about equal If
If possible I'd say check that you have an exact match between what you see on the site, what the blocks admin page says and what is shown in the DB table, so we have a stable/understood starting point.
You could always manually edit the {blocks} table to set the position of blocks.
If you want to get to the bottom of it then I'd suggest:
1. Try on a different host, as per lionheart8's comment, and also
2. It would appear that something is going wrong with the updating of the {blocks} table after the blocks admin form is submitted. (Hey, I'm stating the obvious with a true sense of discovery ..!) When you submit the form, do you get the message "The block settings have been updated."? If you have access to a PHP debugger I'd use that to have a look at what is going on in function block_admin_display_submit() in blocks.module. The function looks pretty straightforward so it's hard to see what's going wrong. In the absence of a debugger I'd backup blocks.module and start putting debugging statements into it inside the foreach loop, e.g.
drupal_set_message(print_r($block), TRUE);before the SQL and/ordrupal_set_message("Block $block['module']-$block['delta']");after the SQL.Let us know how you get on. You could also install devel.module on a dev. instance of the site and turn on query reporting.
Possibly running 50 SQL UPDATEs is too much for your server but it seems a bit unlikely.
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
No. When the page loads I do
No. When the page loads I do not receive the usually welcomed block settings changed message.
I will install devel on a test site I have running right now, but I really need to push forward on my client's build and I've opted to remove block cache for now, which halves the number of blocks I have and allows me to work normally. I suppose I'll investigate file caching or something instead.
I might try this on another server when I get a chance. If anyone here has spare time and space and can try to replicate, that would be helpful.
Thanks to everyone.
No. When the page loads I do
Ahhhhhhhhh. So either the submit handler is not getting called or else $form_values has got trashed somehow. Hmmm...
Must say I hadn't fully clocked that you were using block cache (or tabbed blocks for that matter). Wonder if these modules are implicated. And glad you have a workaround for now.
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
Block cache was not
Block cache was not installed when I replicated this problem on a fresh install.
I am sad to see it go, however, on the production site.
Interesting. Let us know how
Interesting.
Let us know how you get on with any diagnostics. :)
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
You won't believe this, but
You won't believe this, but now it is happening with user access control too.
I think ritual sepuku may be in order.
Very odd. Maybe it is a
Very odd. Maybe it is a server issue as lionheart8 suggests it might be?
At this point I'd dive in with the diagnostic steps I outlined above. Should enable you to determine whether some sort of server limit is preventing the updates from being applied.
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
Okay, I can't find anything
Okay, I can't find anything with devel that alerts me to what might be the problem.
However, I set it to take me to an interim redirect page, and with access it does not. Still no watchdog message of any sort.
Here is a link to the devel output. I know this would normally be horrible to post, but it doesn't function, so whatever.
No link present ... You
No link present ...
You could still dive in here http://drupal.org/node/189292#comment-623348
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
http://72.52.149.247/files/ac
http://72.52.149.247/files/access.html
also, what would be the updated code to put on the access page since blocks are currently working ok?
blocks are currently working
Typical!
In the case of the user access/permissions page the business happens in function user_admin_perm_submit() in user.module. However I suspect that PHP is dying even before it gets there. Maybe it is something to do with submission of complex forms and the server objecting to the CPU demand ... really I don't know though!
For starters, backup user.module and put a
drupal_set_message('Reached user_admin_perm_submit()');in this function. I suspect it's not getting that far, so it will be a bit trial and error finding where it all goes haywire. Initially, the form is I think POSTed to admin/user/access (i.e. the user access settings page/form itself), for which the callback is drupal_get_form() with argument user_admin_access (this is the form ID and also is the form builder function for this page, in user.module). Would take a bit of head scratching and pondering the Form API to work out exactly what is happening here (see the very bottom of that page). I think the key is drupal_get_form(). Form API stuff lives in includes/form.inc.May also be worth checking server logs for any errors.
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
They are REALLY working (IE
They are REALLY working (IE they break still if I add more blocks) but I have the work around in place.
I'll run this test as soon as I get enough free time. Things are crazy.
Thanks for the help!
OK good luck ...
OK good luck ... :-)
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
Also this may be
Also this may be related/offer some clues http://drupal.org/node/190070#comment-623345.
Might also be worth having a play with devel.module - it can output log of all queries run during page generation. Take a backup first though before installing as devel.module can (recoverably) hose your site in certain configs!
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
Ok, I've replicated this on
Ok, I've replicated this on a fresh install with nothing but views enabled.
It seems like the upper limit of non user made blocks is about 50 before it breaks.
I replicated this by cloning the recentn comments block 50 times, but it happens just the same with any number of blocks, it seems.
What the heck???
I have had problems with
I have had problems with block changes not being saved, either after creating or editing them. That problem has also turned up at the same time with failing to make additional changes to user access permissions and have made several posts here, including http://drupal.org/node/173013 and http://drupal.org/node/164289.
The suggested remedies, including increasing memory settings in settings.php have not helped.
I started with Drupal 4.7.3 and updated to 4.7.4 => 5.0, 5.1, 5.2 & now 5.3
When I had 4.7.3 I had many dozen modules I was checking out with no problem with any of those issues. Everything functioned.
The problems started with 5.1, probably also related with some changes on the servers of my free host.
I made several new installations and in spite of considerably reducing the number of modules to those I think i really need for my community site, the problems seem to start at some point I could note define after adding modules & setting permissions as explained in those posts above.
A while back, after needing to make some changes to the layout & failing to edit blocks, I decided to put the exact copy of the site on another server with paid hosting. Everything functioned normally, ie. being able to create, edit delete or move blocks + editing user permissions!
Since this server account is not mine, I decided to change the layout on this and then got the content of 3 db tables => blocks.sql, block_roles & boxes.sql from this foreign server & replaced those with the "corrected" content on my home server. The layout was changed to what I wanted it to be.
My conclusion is there's some form of limit on the current hosting server of my free host, since the exact site functions normally on another.
I must say I have a good number of modules, listed here http://drupal.org/node/175597 where i also tried to get the above problem addressed, but got no response to it. I thought the number of modules could be an issue.
I'm having the same problem
I'm having the same problem as described here: No block settings are saved. Haven't found a solution so far..
I'm still stuck with this problem
I'm still stuck with this problem, maybe somebody can help me. I'm using Drupal 5.20 with many modules. After migrating to a different server I can't move blocks (change the region they appear in or disable them) anymore. When I configure the block settings (/admin/build/block/configure/*/*) and safe them, they are applied. But on the blocks overview page (/admin/build/block), changes are not saved and no confirmation message appears. There is no error message neither. This is the same with different themes.
There are about 70 blocks available, 6 of them are provided by the views module.
I already tried increasing max_execution_time and memory limits, but to no avail. When I change settings directly in the database (table "blocks", for example the values "status" and "region"), the settings are applied. But through the UI, no chance.
Any more ideas what could be the problem?
Edit: I just noticed that the same problem exists with access settings - no changes are saved.
Bump
I bump this because I still have the problem and I don't know what to do. Are there any more ideas on how to solve it?
I had this problem a while ago
I had this problem a while back & it was a frustrating time, because I got no solution that helped. I have at least one other post I made on this over several weeks. http://drupal.org/node/160258 ,
At that time, the free host server, was quite unreliable & was undergoing all sorts of updates & changes that affected the proper functioning of Drupal. At one time there're memory related problems at others some php functions where disabled or not working. Increasing the memory within Drupal could not compensate the grossly insufficient memory on the server for example.
Some of the issues, involved a white screen, at other times inability to save block changes & or permissions.
When those problems got solved the funny behaviour stopped.
I have long moved on though, updated to Drupal 6 as soon as it was ready & have my site on a reliable paid host server.
Actually coming to think of it, I remember at the time I was in a charge of a separate site on a separate paid server. I trasnferred an exact copy of my Drupal site there & it worked perfectly with none of those problems coming up. I made some changes which could not be saved before & when I brought the changed site back, I could not make any further changes. It was clearly something foul on the free host server in that case.
So my question is how good is the server you are on? May be something about it could be a contributing factor ... Just a thought.
Thanks
Thank you for taking your time, lionheart8. I think you're right, it's probably the server. After a crash we had to move the site to a temporarily new server. It's a virtual host that seems to have many errors in its configuration, but at least it worked more or less fine until we moved to a different host. What really bugs me is that there is no error message at all that is related to the problem. There are "MySQL server has gone away" messages in the server's error log, though (but not in watchdog). We've been trying to fix those but haven't had success so far.
>There are "MySQL server has
>There are "MySQL server has gone away" messages in the server's error log
If these happen a lot it suggests that the server is overloaded or somesuch. A good host is worth the minimal expense for the amount of time it saves you..
gpk
----
www.alexoria.co.uk
I know, I know. It's just
I know, I know. It's just that I'm still waiting for a server/provider change but it looks like that will need some more time..
OK, hope you manage to sort
OK, hope you manage to sort something out soon :-)
gpk
----
www.alexoria.co.uk
update: suhosin
Since this topic was originally opened the suhosin extension (which 'hardens' PHP to some extent) has become much more widespread. This has a setting to limit the size of a POST form submission, and this can interfere with some of Drupal's very large forms, typically the blocks admin page and the role/permissions page.
Most hosts will increase these 2 settings:
in the main server-wide php.ini if asked, or on some configurations it is possible to do it yourself in a custom php.ini in the Drupal root folder.
gpk
----
www.alexoria.co.uk