Hi you all,
I am a beginner and I am developing my own module
I am working at the _install hook and I'd like to have a block already available after the module installation process.
on my .module file I have the following definition:
switch ($op) {
case 'list':
$blocks[0] = array('info'=> t('Last Transaction Result'),
'title'=> t('Last Transactions Result'),
'visibility' => 1,
'pages'=> 'mm/mmLAST',
'region'=>'right');
what happens after the installation is that I can see my module among the disabled ones.
at this point the block entry is not on the {blocks} table.
If I edit the block via administration interface and set it to the "right" (side) region and SAVE, I get the block on my mm/mmLAST page AND I also can see the entry on the {blocks} table.
The question:
am I doing something wrong that the entry is not automatically saved ? in any case is there a way to have the block enabled after the install procedure ?
thanks in advance
benny
Comments
I guess this comment might be
I guess this comment might be helpful.
On a side note, you're threading on thin ice – if the theme has no 'right' region, block will be lost altogether (see about a dozen comments below the one linked).
Thanks Drave, I went through
Thanks Drave,
I went through it but I did not find the answer, piety.
Don't worry about theme which MUST have the right region and cannot be replaced by the user with that role.
It seems to me that the block must be manually edited and saved first before appearing on the right side...
I am sure there must be a way to enable it either via .module or .install
cheers
As I understand this, you
As I understand this, you have to:
– set status to 1, and
– use a string array index, not numerical. (I don't know why though)
almost done
Thanks again Drave.
I applied your suggestions and the block appeared on the right ONLY if I used the 'list' $op at least one time.
It looks like that $blocks array is processed only when 'listed'. In this case some call to the hook_block must be performed by the _install module.
I will try on a clean database and let you know.
regards
manimat
What if you tried to
What if you tried to put
in
yourmodule_install()or ratheryourmodule_enable()(AFAIK the latter is executed a tiny bit later)?I haven't seen any module doing this, but someone has to be the first to try. :)
unsuccess
Hi Drave,
I reloaded my justinstalled DB image and then installed my module (no additional modules but the plain 6.22 install)
I added _block_rehash(); just before mymodule_install return;
The result is that nothing happens on {blocks} table.
If I open administator->site admin->blocks (just list) and then I click on mymodule-menuentry I successfully can see the module, infact 'list' $op was read.
I am loosing a lot of time on it and I should not: It's much easier take a list at the installation time and from theninafter the installation is fine. However I cannot step over if I know this matter is behind me.
Well, yes, it seems calling
Well, yes, it seems calling _block_rehash() in .install is way too early. :(
The problem with calling it in .module, however, is that it's pretty resource-consuming (because it invokes all modules implementing hook_block), so calling it, e.g., on every block view would slow down everything. So it needs to be called only once.
I'd probably use a variable for this:
unsuccess2
Drave,
I think yours is a good idea, the one I was looking for: a sort of trigger for the first time activation. I did the test and I could easily check that only if I list the blocks mine appears on the db.
To confirm this point is also mymodule_initialized which is TRUE in the {variable} table.
I noticed that on a fresh installation Navigation and User Login blocks are already there. I will investigate on how they are born on the db.
I don't want to write the record straight to the DB from .install as it can become unconsinstent with the same definition on .module....
good evening (at least here in Italy)