Work in blocks

No this is currently not supported. I will not focus on this feature so i hope somebody else volunteers for this.

exactly the same problem here

As blocks are no nodes, just read up http://drupal.org/node/823430#comment-3341782 .. thats the reciepe how to implement this.

I have not found any solution on the last link.

Please include support for blocks, otherwise is half useful for many.

Very promising module.

Well it rather full usable for 95% :)

Iam not going to work on this issue, so please provide patches, thanks.

I am a just a designer, so it is hard for me to modify modules yet.

There are lots of textareas beside nodes, and blocks are just one of them, so I think it is a fair request and I am sure we don't have statistics of how are people exactly using Drupal, (Except for the module installation rates and the tons "garland-i don't use blocks nor panes" sites ) so since you are not interested, I just post this hoping any other user jumps in.

Use panels - panes + exisiting content + nodes.

the scope of this module is the end-user which writes articles, news, blogs or any kind of content. Its not primary the "site builder" or even designer. They should have other skill to place images, including templates or imagefield + inline.

But blocks dont have CCK either...

You can use a block, and simple node_load / render a node in there. You can change the node and the block is changeable. There are tons of ways to do this. A blog is a container in drupal.

Anyway, iam willing to include block-support but i guess someone else has to implement it.

I finded a workaround with CKEditor.

Create a node, insert two empty lines, insert the image using wysiwyg_imageupload button, insert two empty lines.

Save the node.
Select the image, copy it.
Create a block and paste the image.

If you don't delete the node the image is visible in the block.

Enjoy!

Subscribing

I still find funny this issue. We users should be able to use drupal in different ways if we want to call drupal flexible.

I find very common my clients wanting to place a banner or a logo in a block or changing it.

But my interest now is not on opinions but rather the code. What is the drupal limitation for uploading files when browsing the new block page?

@pitxels:
Agreed, I haven't had a client that wants to put images in nodes and not blocks.
Also, the fact that the button is there but just doesn't work isn't great.

There is no technical limitation, the functionality just has not been added yet as the maintainer doesn't have the time to do it, which is understandable.
As mentioned in #7 he will accept patches that add the functionality.

I've only scratched the surface with respect to looking into this, and I'm not an expert in this module. These are just some thoughts about one possible approach to getting support for this.

The spirit of this module seems to be in line with extension as opposed to adoption in core. So, maybe instead of adding block support to the main module, we add a contrib module to support it.

Here's a thought about how this might be possible.

• add an "extension" field to wysiwyg_imageupload_entity. The value of this might be "wysiwyg_image_upload_block", the name of the extension module.
• each extension then adds another table to track extension specific information (wysiwyg_imageupload_entity_block)

Every extension module would need to implement the access hooks

• wysiwyg_imageupload_access($iid, $op) - for blocks this might be user_access("administer blocks") or maybe everyone can see all images uploaded in blocks.

Every extension module would need to handle updates/garbage collection as is the case for nodes and node comments. IE, currently, when a node is saved or deleted, hook_nodeapi is used to track changes and deletes of images in that node. Same with hook_comment. I think the only way to do this in blocks and other desirable locations is with hook_form_alter. That sounds kinda iffy but doable (at least for blocks).

In addition, the browser and possibly views support would need heavily modified (last I looked it was tied to node revisions). I'm not really sure how that would work with views and all. Maybe an ideal browser would return an image on the left and then instances of usage on the right (see attachment). Then to insert the image, you'd click on the usage, which would get you the caption associated with that particular iid.

Any thoughts on this? Would it be a good approach? Is there a better one? I skimmed through the issue on d7 and see you're looking at media as a backend (good move). Not sure what the implications of that would be to an extension model.

Personally, I can live without image support outside of nodes, at least until we move to d7. We already use imce for document file handling (pdf, doc, xls, etc) and it would not be too hard to allow (png, jpg, gif) for "advanced users".

I'm torn about whether or not implementing this would be worthwhile with d7 on the horizon. However, if it's something Eugen's interested in I can try to whip up a patch and proof of concept.

Hi Jason,

i like your idea and approach. But it could be more could then actually fixing the core. You correctly identified the core-issue.
There is a must-have relation between an image and the content. Yet, the content ist "harcoded" to be a node or a content. That was pretty bad by design by me, no doubt. Saying this, we have "nid, vid, cid" fields in the entity database.

To correctly fix this issue, we just need to first change or DB structure to use a relation to the entity, that means, we dont have "nid, vid, cid" anymore, rather an entity type and entity id, just very generic. So we end up having
- type: block ID: 112
- type: node ID: 213
- type: panel id:12312
- type: comment ID: 12321

But thats actually not all of it. As nodes can have revisions, and comments are attached to nodes, we need to let those types decide about their relation, that means we add a other part of the tuple, the Inline id ( IDD ). That said, an object would be identified by ( iid, id, type ). When an object gets loaded, a class like Wysiwyg_imageupload_load_$TYPE is search, given the iid, id, type tuple into the constructor, returing a Wysiwyg_imageupload_image object. That one can be loaded by WYSIWYG in the editor and in the view later.

Important, we need an base-class for the type and image object class, as we will need to have an interface for the view-loader.

E.g the Wysiwyg_imageupload_load_node class would actually be a submodule, which needs a extra-table, were it will store the relation between its id ( nid ), the iid and the vid. Wysiwyg_imageupload_load_comment will store the relation to its nid, if that is actually needed at all ( i expect that to be in the core db already ).

In addition, we will need to have at least the "access" method in Wysiwyg_imageupload_load_$TYPE, so access can be calculated.

Thats it :)

By the way, with this change, we can later port to D7 very easy, also use different backends like media.

+1.

I have a client who was happily uploading images to blocks with the FCKeditor module and is now very unhappy because I replaced the module with WYSIWYG + ckeditor and the client can no longer upload images to blocks.

@Tanis.7x:
Sounds like the cause of your problem is not actually WYSIWYG image upload :)

Try the Node Blocks module http://drupal.org/project/nodeblock, its a great module anyway to set node types as blocks, works great for me. I do think it would be nice if someone could put on the module page that it will not work in blocks, and maybe a link to Node Blocks, so people can make a decision before installing and racking their brain on why its not working in blocks :) Thanks for the cool module though.

Well that one is a pretty cool suggestion Codigo Vision. I will put this one on the module page. Thanks!

That is the solution I have been using for a while now also.

It is a decent work around but it isn't as good as using blocks from a performance point of view because you then have the overhead of the node system and the block system when rendering your blocks.

Although nodes are more flexible with what you can do with them and it is easier for users because they only have to know how to edit nodes and they don't have to know how to edit blocks (a lot of end users don't like editing blocks in my experience).

You might also find it a good idea to do a specific node tpl in your theme for your node block content type so that you don't have excessive node markup in your blocks.

Will the 6.x-3.x branch support blocks?

nope, not planned. I will not work on this activly myself

I was hoping to find progress in this issue, Imagebrowser module works on blocks, so I guess there is a way to workaround any core limitation.

While creating a block as a node is nice, it adds a layer of complexity to a final users.

@EugenMayer would you consider paid customization?

In General yes, but in this case not. This would need some more or less changes, which I don't have the time and neither the motivation to work on. So I really only consider contributions in this field, I'm sorrz