block print
<?php
<br/>
$block = module_invoke('module_name', 'block_view', 'block_delta');<br/>
print $block['content'];<br/>
?>'module_name' = The machine name of the module (i.e. the module's folder name). This is true for core modules too, so for instance 'search', 'user' and 'comment' would all work here.
'block_delta' = The machine name of the block. You can determine what this is by visiting the block administration page and editing the block. The URL for editing a webform block, for instance, would be something like:
Drupal 7: admin/structure/block/manage/webform/*client-block-11*/configure
In this example, 'webform' is the module's name, 'client-block-11' is the block's delta.
Custom blocks will have module name of 'block' and a number for a delta, which you can also find by editing the block.
More information: http://drupal.org/node/26502
Failover
If the slave fails it is possible to fall back to the master db. This is done simply by including the master in the slave pools (see the extreme configuration example below).
Likewise, if the master fails it is possible to fall back to the slave db. This is done by including the slave in the master pools. The system will then fall into read-only mode, since there's no master available, resulting in a messsage on all pages stating that the system is in read-only mode. Remember to set the "readonly" setting to TRUE on the slave connections, in order for this to work.
Settings
This section contains a list of all the options possible to configure AutoSlave with.
The most bare-bone AutoSlave configuration will assume default values for all options:
<?php
$databases['default']['default'] = array(
'driver' => 'autoslave'
);
$databases['default']['master'] = <your master db config>
$databases['default']['autoslave'] = <your slave db config>
?>Here's an example how to use the options below:
<?php
$databases['default']['default'] = array(
'driver' => 'autoslave',
'replication lag' => 10,
'affected tables backend' => 'autoslave.affected_tables.mongo.inc'
);
?>Options
- master
- slave
- tables
- watchdog on shutdown
- global replication lag
- replication lag
- invalidation path
- use autoclave schema
- affected tables backend
- bypass page cache
- preconnect
- flag all tables
- resync on cache miss
master
Type: array, Default: array('master')
This controls which "targets" should be used as masters. Targets will be tried one at a time, providing a failover effect. To use the slave targets in the event that the master fails use (assuming the 'slave' is set to 'autoslave'):
Utilizing the Migrate / Feeds module to import data into RedHen
This document will be updated as I proceed through the data conversion process. As part of my project, I have 23,000 contacts I need to upload into RedHen.
I was hoping to use the Feeds modules to load my organization and membership data into RedHen, but I found out that Feeds does not support "non-core entities" (see http://drupal.org/node/1033202).
In the RedHen issue queue, Thinks Shout has stated that "We have near term plans for writing a wrapper classes for Feeds and/or Migration as well. Eventually, we hope to write a custom contact importer more finely tuned to RedHen and general CRM needs. Contributions / input on all of the above are certainly welcome."
So at this time, I will have to investigate the Migrate module to see.
How to configure the RedHen modules
This document is under development.
This document will explain in what sequence the different modules and sub-modules and entities to be setup and installed.
Frequently Asked Questions
Is RedHen a CRM system?
Yes.
Why build a CRM system in Drupal?
- Drupal is a content management system. Traditionally, if you wanted to manage contact information collected through your site, your best option has been to integrate with an external CRM system. The costs of integration can be high and the resulting system can be hard to maintain over time. This is an area dying for innovation and RedHen is a different approach to the problem.
- There are a lot of modules that collect contact information. There is no central place to store that information. This creates needless data silos. RedHen addresses that problem by providing module developers a common repository for contact information.
- Drupal has all these wonderful tools for interacting with authenticate user. In the contact management world, a vast majority of our contact are anonymous users. Unfortunately, we can not use those superb Drupal tools to interact with these potential users. RedHen enables this kind of interaction through its integration with other major tools and features in Drupal.