Home » Blogs » larry's blog

Is this possible?

Posted July 14th, 2006 by larry
You know sugree, Over the last few months I've learned some very interesting stuff from your reading the postings on your site, not just about Drupal. I thank you for that. Yesterday, I read this post http://drupal.org/node/73389 over at Drupal and thought it's an interesting idea. Since nobody at Drupal seems to know the answer to this one, I'd thought I'd ask here since you always have the answers! Is it actually possible to take blocks from one Drupal site and post them on another non-drupal site. The MeCommerce.module at http://drupal.org/project/mecommerce seems to do this with ads, however after some investigating I see that goodstorm is using Drupal only as front for it's t-shirt store and the mecommerce application is actually written using turbogears. I think it would be cool, for example, to be able to share blocks of content with other sites from friends. What do you think? Is it possible on Drupal? How would someone go about doing this? I see a python section here, how would turbogears make such a thing like mecommerce? It's an interesting topic I think. Anyways, thanks again. cheers, larry

partial render

On July 14th, 2006 sugree says:
Drupal offers powerful APIs for partial rendering especially a piece of block. Anyway, there is no public interface to make the content available outside Drupal (external site). There are 2 approaches to make it work. 1. XML-RPC 2. Custom menu handler I think you might prefer the second one. It is very easy to implement a module for this task. Anyway, the most popular to publish contents to remote sites is RSS or Atom feed so that remote sites are able to format that content to fit into their themes. For MeCommerce, it is very similar to Google AdSense or other similar which uses javascript to generate inline iframe and fetch more codes from original sites. This approach is only useful when you are going to use Drupal as a backend for affiliation program. This is a generalized AJAX technique with a bit interaction that works on any browsers.
  • reply
  • th

thanks for clearing that up..

On July 14th, 2006 larry says:
Your explanations are highly interesting. While I agree with your idea on simply using RSS to send content, there are two problems I immediately see. First, most people these days ARE NOT using RSS on their sites. Yes, it's becoming more mainstream...but it's not yet ubiquitous. Second, in order to do this the receiving site must A) have an aggregator that will parse and format the feeds directly into the site's own layout and 2) updates are not realtime. The updated block will only be udpated on the remote sites AFTER the aggregator has requested the feed update. If these feed update requests are too frequent, the server gets slammed, if they are too few then my block idea is not being implemented properly to give automatic updates as they occur. Am I seeing this correctly? A DRUPAL affiliation program...that's interesting. I mean without third party add-ons. MeCommerce is actually a third party application. I have seen the affiliate.module, click_thru.module, and the referral.module...also the banner.module. None of these offer what MeCommerce does. Could such a module be made using one of the aforementioned modules as a starting point...I mean a DRUPAL only affiliation module? From what I have seen so far, the banner.module offers the best chance for this as all the tracking and click counting code is already there. What's your opinion on this? Is that a good place to start? cheers, larry
  • reply
  • at

affiliation module

On July 14th, 2006 sugree says:
This new module should utilize banner module by using it as is. As a result, the new module will offer javascripts for generating iframe on remote sites and also retrieving items from banner module to display inside that iframe. The trick here is to generate javascripts on the fly since AJAX will never work across domain by default. This is a good idea for eCommerce sites. Well, you still have to think about how to choose items for displaying on remote pages. AFAIK, Google AdSense will immediately retrieve the source page of each affiliation to check for modification and then return the right entries. To make this more open, I think that affiliation module should provide hooks for customizing items selection algorithm as additional modules.
  • reply
  • th

very nice approach...

On July 15th, 2006 larry says:
You are 100% correct. The banner.module has everything that you need already EXCEPT the ability to place it's blocks on remote sites. I've written the author about this and have gotten no response so far. However, earlier in this post you said it's easy to place blocks on remote sites. Here's an idea...simply use a block created by the banner.module and then use another module (that I am thinking on writing) to place them on remote sites. The banner.module already has the tracking stuff written in. What do you think? As far as displaying ads goes, forget google's model. You can't out-google google. Create a few dozen views (already in blocks) to choose from, then simply place them on the appropriate sites after the remote site owners have chosen them. Placing whole blocks called from drupal rather than using inline iFrames seems easier to me, or am I missing something? iFrames creates the block inline and then you have to call the content. Placing whole blocks from Drupal places the block form AND the content simultaneously. I've tried the affiliate module to see if I could use it as a skeleton for my module. Nope. It offers links, not formatted blocks...or am I missing something again? Sugree, what's your take on these ideas? cheers, larry
  • reply
  • at

quick solution

On July 16th, 2006 sugree says:
You have to implement a function for rendering a specific block you want. For example, function custom_render_block($module,$delta) { $block = module_invoke($module,'block','view',$delta); print theme('block'); exit(); } Then bind above function to a menu, e.g. custom/renderblock. So you may get a block content by retrieving the first block of module "block" at custom/renderblock/block/1 using drupal_http_request().
  • reply
  • th

Is it that simple?

On July 18th, 2006 larry says:
If I understand you correctly, then I don't need to even create a module to do this. For the last couple of days I have experimented with this function. You can place a block's content anywhere using it...as long as it's on your site. Then, if I understand you, you can simply use drupal_http_request() to call up the block from a remote site and place it's content there. I have not yet done this, but I imagine placing/formatting a block's content on another site would be a matter of placing the drupal_http_request code within a remote site's template, where-ever you want the block to go. Am I right, or way off? Should I start preparing to do a module? cheers, larry
  • reply
  • at

it is that simple

On July 18th, 2006 sugree says:
You understand me correctly. That code should be placed in a module so you can remove it off whenever you want.
  • reply
  • th

Ok..I'm almost there. My

On July 29th, 2006 larry says:
Ok..I'm almost there. My problem is, I cannot write a proper drupal_http_request to call up the block on the remote site. I've gone to the drupal API site, but I'm still not able to put together a proper, functioning drupal_http_request. The examples they give are a bit different than what I'm trying to do. I'm not exactly certain how much information I need within the request itself and how it would be structured. I can easily call blocks up anywhere on MY site, but remotely, I can never get it to work. May I ask what a proper drupal_http_request would look like in it's ENTIRETY, that is complete and functioning? thanks, larry
  • reply
  • at

drupal_http_request

On July 29th, 2006 sugree says:
It should be very simple as follow. function custom_block_get_remote_block($url) { $ret = drupal_http_request($url); return $ret->data; } And then call this function in a block.
  • reply
  • th

Post new comment