Extended content type options. Full block settings for administrators.

I just wanted to stop by and say major kudos for the work involved. You've obviously analysed this module thoroughly and hit all the right nails.

I haven't tested the patch yet, I'll wait for other devs to eye ball the code first and comment.

A major +1 for this. I just set it up on a site I'm working on and the functionality is very useful. My only complaints are minor quibbles -- it would be nice to change the 'This content type will automatically generate a block' message into a normal markup element, rather than a fieldset, if that's the *only* thing that will be in the fieldset. It seems a bit awkward to hide a single line of text. Other than that, I love it.

Hi Jose,

I just found a small issue. The Block title setting seems not to stick.

Setup:
Drupal 5.1, i18n.
i18nblocks on
nodeasblock: "create translation blocks automatically" on.

If I edit a nodeasblock and set the block title on the node edit form ("Block specific settings") to it works fine. But if I go back to edit the node, the block title is blank (it should show ). The effect is that, after saving, previous settings to block title are lost.

Thanks, Jose. Next time I will file a i18n ticket.

In order to avoid TinyMCE to f* with the page specific settings, I had to add 'nodeasblockset-pages' to the list of exceptions of textareas in the moxie theme function:

phptemplate_moxie_theme($init, $textarea_name, $theme_name, $is_running) {
  switch ($textarea_name) {
 // ...
    case 'description': // taxonomy terms
    case 'nodeasblockset-pages':
      unset($init);
      break;
// ...
}

What's missing for getting this patch in?

I like where this patch is going. I've noticed I can't create new blocks. I'm going to check this patch in as I have made a couple of small changes, but perhaps someone else can fix the new block problem? The problem comes in the nodeasblock_nodeapi in the insert op. The problem is this SQL statment:

        db_query("UPDATE {blocks} SET status = %d, region = '%s', weight = %d, visibility = %d, pages = '%s', custom = %d, title = '%s' WHERE module = '%s' AND delta = '%s'", 
          $block['status'], $block['region'], $block['weight'], $block['visibility'], trim($block['pages']), $block['custom'], $block['title'], $block['module'], $block['delta']);
  

For new blocks, no record exists, so nothing gets updated.

Perhaps someone can write an equivalent insert statement.

Grab the latest 5.x-1.x-dev code, as most of the rest of the patch is going in right now.

Thanks.

subscribe

Subscribing.

Almost all the features requested in this thread are implemented in the current development version. I am going to close this old issue, if you guys find anything that should be re-considered again, please, open a follow up issue.

I love this module, but there is one feature missing that I think would be very useful. I'd like to be able to expose the "Role specific visibility settings" and "User specific visibility settings" from inside the "node as block settings" without needed to grant the full "Administer Blocks" permission.

In my use case, I am using NodeAsBlock, and have created a content type called "Block" and allowed my client (the website administrator) access to create nodes of type "Block". I have removed the "Administer Blocks" permission because it exposes all the other system blocks that I want sole control over. So far, with the current state of this module, my client can determine the region of the "Block" node, set Block specific settings for Block title, and set Page specific visibility settings. It would be idea to have "Role specific visibilit" settings" and "User specific visibility settings" as well, but only if I (as the site's webmaster) can keep sole control over the system blocks (/admin/build/block) page.