Their previous system was a large Drupal 5 application managing 7 websites which we built in 2008 (and was one of our first Drupal websites). Inclind redeveloped beracahhomes.com under their custom Drupal 6 package, providing added functionality, a better administrative user interface, content delivery through XML services, billboard (rotating banners) management, and high quality video encoding capabilities. Leif Osmundson provided Beracah Homes with a new design for a fresh look and feel for the upcoming years. We’ve also implemented better search engine optimization tools to help Beracah Homes rank better amongst their competitors.

Before:

After:

Beracah Homes’ builders also have a Drupal package allowing them to manage their own website while receiving modular homes content from beracahhomes.com. The builders now have the flexibility of customizing their CMS to their needs without being conformed to the same system tie-in they previously had. It was difficult before to add functionality to one site without affecting the rest, but now all sites can scale without an issue.

Services XML, similar to our Drupal RETS implementation for Drupal real estate, allows Roger Collison (Vice President of Beracah Homes) to enter model home types, home specifications, floorplans and photos. That content is then sent to all builder sites so everyone has the same information without having to manage it themselves. This ensures that information on all the homes Beracah builds is accurate and up to date across all their websites without a salesperson in another branch having to remember to make the changes. This was a major functionality change that allowed us to decouple all the websites from a single application, providing them with the same content delivery feature while giving them room to manage their own site.

Custom Drupal solutions is what we do. If you have a website that is just idling on the internet and not doing much for your business, you are interested in getting your first website and not sure where to start, or you just need help managing your current website, give us a call at 1-302-856-2802 or stop in. We do free consulting to help you and your business on the internet.

Check out the new and improved Beracah Homes today!

Blue Hen Organics Compost Facility is located on 46 acres just west of Dagsboro, Delaware on Fox Run Road. The facility is open six days a week for material drop-off and product purchases. The Blue Hen Organics facility is the first permitted organic residual composting facility in Sussex County, Delaware, and is capable of processing over 120 tons of debris daily. This facility currently accepts all types of vegetative debris, yard waste, land clearing debris, and poultry manure.

Inclind assisted with defining branding for Blue Hen Organics, providing a fresh design, developing their website, powering it with Drupal content management system, custom modules, social media integration, and providing search engine optimization.

Visit the new Blue Hen Organics site today – in your browser, iPhone or iPad! »

Have a question about web design, content management, Drupal, or marketing your business/brand online? Contact Inclind today, we’re here to help.

302-856-2802

Accudyne Systems specializes in all aspects of custom equipment:

• Development
• Engineering design
• Fabrication
• Systems integration
• Start-up
• Support

We assisted in converting their old static HTML site into a content management powerhouse with the help of Drupal and custom Drupal module programming and provided them with a fresh new look for 2010 and beyond. Easy editing with CKEditor, eye catching images using our Billboards module, and an eye pleasing new design by Leif Osmundson.

Visit the new Accudyne Systems website, in your browser or iPhone/iPad! »

Their new Delaware Real Estate section is powered by our Drupal stack utilizing a custom in-house RETS module. Previous systems would receive listings once a day through a bulk FTP push from Offutt. Using RETS, Wilgus Associates can receive on-demand updates and data every hour.

This allows for the data to be arranged, mapped, sorted and listed in thousands of ways backed up by hourly data integrity functions to ensure the most up to date information, not to mention the worlds most flexible CMS to manage content with Drupal.

The new site also makes use of extensive search engine optimization work to help Wilgus rank better amongst their competiton. It also utilizes social media tools such as Twitter and Facebook to help spread the word and allow users to share/bookmark listings in their respective services.

What is RETS?

The Real Estate Transaction Standard (RETS) facilitates data transfer between partners in the real estate industry. Creating and improving RETS is a collaborative effort to simplify moving real estate information from system to system and simplify solution development efforts. As RETS usage matures and expands, MLS with geographic overlaps can create data-sharing policies that provide their members a single point of entry to search multiple MLS data sets.

Interested in RETS?

If you’re a broker or REALTOR, using RETS technology is the fastest way to get listings up and running on your website. Our RETS system for Drupal was built with flexibility, speed, marketing, and conversions in mind allowing us to quickly and effectively deploy it in no time.

Contact Inclind today at 302-856-2802 or email us at info@inclind.com for a free consultation on how your Delaware real estate website could benefit by using RETS.

About Wilgus Associates

The growth story of Wilgus Associates can be traced back to its origins as a staff of one in a one room insurance office located on the boardwalk in the Bethany Beach Bowling Ally. Since that humble and simple beginning, Wilgus Associates has grown to include three offices in Sussex County that offer a wide array of real estate and insurance services and now employs a staff of over fifty people.

Visit the Wilgus Associates website >>

Washingtons Green Grocer is the brainchild of John (Zeke) Zechiel and his wife Lisa. After identifying the need for better produce and deliverables versus store bought goods, John and Lisa planted the seeds for Washingtons Green Grocer in 1994. Every week, Washingtons Green Grocer provides customers with tentative lists of fruits and vegetables that will be available, and each customer can pick and choose what they would like delivered (yep, home delivery!) for that week through their online account.

Providing unmatched service and 100% dedication to custom satisfaction, Washingtons Green Grocer has been wildly popular and has exploded in the DC metro area. They currently serve all of Washington DC and the surrounding suburban areas in Maryland and Virginia from Severna Park to Arlington and all points in between north and south.

How does it work?

Every week, Washingtons Green Grocer selects 12 to 14 different fruits and vegetables and delivers them to your doorstep. On Friday’s, they email customers a tentative list for the next weeks delivery. If there is anything on the list you don’t want, you can log into your account and customize your box. For example, you can choose to receive only 7 items instead of the full box, or substitute items for other items. Each customer can choose exactly what they want and get it without fail every single week. You can also set custom schedules for delivery, such as every other week, or once a month, or schedule around vacation time. It’s all up to the customer!

Application

Such business growth commands the necessity of a powerful web application to tie all the logic together and keep things running smoothly. After getting tired of the shortcomings of their previous system, Zeke contacted us and we started talking about a full redesign of the front end and a re-architecting of the back end. After planning and mind-mapping the application to the last detail, Inclind began work on the project early in the summer of this year.

Their initial website was built on a rigid and inflexible Coldfusion system. The first order of business was getting all the existing data out and into the new system and giving it structure to make it easy to work with. As with all our sites, we begin with a base install of Drupal 6 to build from. Drupal is the best CMF (content management framework) available right now. Other packages that are simply CMS (content management systems- Plone, Wordpress, Joomla) are not as adaptable and flexible as Drupal.

To handle the business end of things, Ubercart takes care of the day to day transactions for customers. There are over 5,000 active customers in the system. To make it as easy as possible to get started, we ask for your basic information up front and allow you to pick your items for delivery. After your account is created, a staff member at Washington’s Green Grocer selects the most appropriate truck route for you and you will begin receiving deliverables on the next scheduled day.

At this point, a customer can login at any time and adjust their delivery schedule, items for delivery, or halt deliveries. Customers can also browse recipes on the site and submit their own. Washington’s Green Grocer promotes healthy eating habits and you will find plenty of recipes on their website for that.

Backend

Along with the new visuals and customer functionality, we needed to build and provide lots of cool administrative stuff into the backend for easy management of customers, data, and content.

We also needed to be able to actively map delivery truck routes through Google Maps on demand and be able to filter them in a variety of ways. This helps Washingtons Green Grocer visually assess their delivery routes, their customers, and orders. We also also extended on that to provide filtering tools to narrow it down further to specific routes, specific clients, specific orders or orders with specific kinds of products.

Washingtons Green Grocer staff also have a variety of reporting tools at their disposal for viewing customer trends, requests, future forecasting, and production reports.

Check out Washingtons Green Grocer today!

What is an LLC?

A limited liability company or a company with limited liability (abbreviated L.L.C. or LLC or W.L.L) in the law of the vast majority of United States jurisdictions is a legal form of business company that provides limited liability to its owners. Often incorrectly called a “limited liability corporation” (instead of company), it is a hybrid business entity having certain characteristics of both a corporation and a partnership or sole proprietorship (depending on how many owners there are). An LLC, although a business entity, is a type of unincorporated association and is not a corporation. The primary characteristic an LLC shares with a corporation is limited liability, and the primary characteristic it shares with a partnership is the availability of pass-through income taxation. It is often more flexible than a corporation and it is well-suited for companies with a single owner.

Delaware LLC is built on our custom Drupal CMS package. It was designed from the ground up by Creative Director Kevin Howett, and put together in a collaborative effort between newcomer Matt Oseland, Kevin Howett and Bryan Cordrey. Efforts were focused on a pleasing, business-minded design, effective search engine optimization, and funneling/encouraging customers to begin the process of forming an LLC in Delaware.

As Rick’s customers go to him and Harvard Business Services for their LLC/incorporation expertise, Rick came to Inclind for our expertise in clean, effective websites and powerful web application development under Drupal and our deep knowledge of content management systems such as Drupal. We also got to flex our system integration skills with Drupal, PHP and Coldfusion.

About Delaware LLC & Harvard Business Services

With more than 25 years of experience, over 20,000 clients worldwide, and offices in both the United States and Europe, Harvard Business Services, Inc. is the premier provider of registered agent and business formation solutions.

Rick Bell formed Harvard Business Services, Inc. in March, 1981. Competitors then were big and well established. But Rick conducted business with a philosophy that allowed Harvard not just to survive but to thrive, emerging over time to become an acknowledged leader in the business formation industry.

His philosophy focused on a highly personalized style of customer service, understanding that beyond the mechanics of forming a business there were dreams and aspirations. A customer’s individual questions and concerns were important and special, and that’s how they were treated.

Rick also decided that a customer’s business formation costs should be fixed, predictable, affordable, and customers should get a lot of value for their money.

After almost 30 years and tens of thousands of business formations later, that same approach is still the signature of our culture and way of doing business: speed, efficiency, expertise and affordability, all delivered with the Harvard legacy of personal service.

Headquartered in Lewes, DE, Harvard Business Services, Inc. today is the leading provider of business formation services. Along with the Harvard Business Services brand of fast, personalized service, customers soon discover a number of other traits that set Harvard Business Services, Inc. far apart from the rest.
———————————————–

If you have any questions regarding content management systems, Drupal, Coldfusion or systems integration, we are here to help. Give us a call at 302-856-2802, send us a tweet @inclindinc, or stop by our office. We have been the leading web development firm in the area for over 10 years running and have fourty years of combined web experience under one roof.

Lets take a look at how you bring in files as part of that node as well. From the previous example, before calling node_save($node), I call another function to process files. Name it however you wish. My module is called homes_sync, so my hooks and functions begin with that as per Drupal standards.

1
2
3

homes_sync_get_files($node, $nid, $sessid);
// save the node object
node_save($node);

homes_sync_get_files() is passed the $node object and will return it after adding (or removing) data. To have a reliable file sync, we need to only update files if they are newer, and remove them if they no longer exist.

In this specific example, the project I am working on has two CCK file fields. One is for a floorplan (a PDF) and the other is an image field. In a node, there is only 1 floorplan, but can be up to 2 dozen images. If you had a more generic node that just has a CCK filefield of ‘client_files’ for example, your code would be slightly different.

Before we add any files to the node, the first thing we should do is compare the list of files from the remote site to the local site. We start that off by getting $files via xmlrpc, and loading the node object if $node->nid is present. If any are found on the local site, and not the remote site, we can safely remove them from the node object. The two arrays are iterated over and remove files if necessary.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

function homes_sync_get_files($node, $nid, $sessid) {
 
	$files = xmlrpc(REMOTE_SERVICES_URL, 'file.getHomeFiles', $sessid, $nid);
 
	// first, compare list of files from parent server with local files
	// if our local files has something the parent server doesnt have
	// it was probably deleted. so we need to unset it from the node object
	// when it gets passed back through node_save, cck should delete it proper
 
	if ($node->nid) {
 
		$current_files = node_load($node->nid);
 
		if ($current_files && !$files) {
			// we have files locally, but none on the parent server. 	
			// remove all
			unset($node->field_floorplan);
			unset($node->field_image);
			watchdog('homes_sync', 'Remote copy of @node no longer has files. Removing all local files for @node.', array('@node' => $node->title), WATCHDOG_NOTICE);
		} elseif ($current_files && $files) {
 
			// build comparison arrays
 
			foreach ($files as $remote_file) {
				$remote_files[] = $remote_file['filename'];	
			}
 
			foreach ($current_files->field_floorplan as $local_floorplan_file) {
				$local_files[] = $local_floorplan_file['filename'];
			}
 
			foreach ($current_files->field_image as $local_image_file) {
				$local_files[] = $local_image_file['filename'];
			}
 
			// now lets see whats missing
 
			if (is_array($local_files) && is_array($remote_files)) {
 
				foreach ($local_files as $local_file) {
					if (!in_array($local_file, $remote_files)) {
						// parent site does not have this file in the node anymore
						$files_to_delete[] = $local_file;
					}
				}
 
				if (!empty($files_to_delete) && is_array($files_to_delete)) {
					foreach ($files_to_delete as $key => $file_to_delete) {
						// CCK field arrays exist in node objects even if they have no data
						// we can assume if the first record is NULL, there is no data
 
						if ($node->field_floorplan[0] != NULL) {
							foreach ($node->field_floorplan as $file_key => $floorplan) {
								if ($file_to_delete == $floorplan['filename']) {
									watchdog('homes_sync', '@file file does not exist on parent server anymore for @node. Removing.', array('@file' => $floorplan['filename'], '@node' => $node->title), WATCHDOG_NOTICE);
									unset($node->field_floorplan[$file_key]);
								}
							}
						}
 
						if ($node->field_image[0] != NULL) {
							foreach ($node->field_image as $image_key => $image) {
								if ($file_to_delete == $image['filename']) {
									watchdog('homes_sync', '@image image does not exist on parent server anymore for @node. Removing.', array('@image' => $image['filename'], '@node' => $node->title), WATCHDOG_NOTICE);
									unset($node->field_image[$image_key]);
								}
							}
						}
						unset($floorplan);
						unset($image);
					}
				}
 
			}
		}
 
		unset($remote_files);
		unset($local_files);
	}

Now that we are through with our deletion process, we can begin processing the remote files. For each file id ($fid) we call xmlrpc and get all the data and the file itself and bring it down to our local site. Based on the file extension, we begin building a query so we can look to see if this file exists locally, and what its last timestamp was. We do this so we know if a file should be replaced or not. For example, if you have MyHome.PDF on your local site, and a new version is uploaded on the remote site, simply comparing file names is not good enough. With a filename and a timestamp comparison, you are certain that it should be processed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

	if ($files) {
 
		foreach ($files as $fid => $remote_file) {
			$file = xmlrpc(REMOTE_SERVICES_URL, 'file.get', $sessid, $fid);
 
			if ($file) {
				// set filepath to save to
				// decode our content file
 
				$file['filepath'] = file_directory_path().'/'.$file['filename'];
				$file_data = base64_decode($file['file']);
 
				// set content type db table, and field to search on.
				// Load up the CCK field
 
				$filetype = explode('.', $file['filename']);
 
				if ($filetype[1] == 'pdf') {
					$content_table = 'content_type_homes';
					$fid_field = 'field_floorplan_fid';
				} else {
					$content_table = 'content_field_image';
					$fid_field = 'field_image_fid';
				}
 
				$file_details = array();
 
				// check if it's the same file coming over
				// only applies if the node exists in the first place. otherwise its a new import on a new home
				// if there is a file match we dont want to do anything but skip the creation
				// i think if you dont keep the node->file field prefilled, and returns those fields empty, it causes the file deletion on the server
 
				if ($node->nid) {
 
					$result = db_query("SELECT f.filename, f.fid, f.filepath, f.timestamp FROM {files} f
											INNER JOIN {%s} ctype ON f.fid = ctype.%s
										WHERE f.filename = '%s'", $content_table, $fid_field, $file['filename']);
 
 
 
					$file_details = db_fetch_array($result);
 
				}
 
 
 
				if ($file_details && $file_details['timestamp'] < $file['timestamp']) {
 
					// if file exists and has not changed remotely, skip it
 
					watchdog('homes_sync', '@file already exists for @home. Skipping.', array('@file' => $file_details['filename'], '@home' => $node->title), WATCHDOG_NOTICE);
 
				} else { 
 
					// save file
					// REPLACE because we can be certain we will not have duplicate files
					// so we will only ever receive unique ones here
 
					file_save_data($file_data, $file['filepath'], FILE_EXISTS_REPLACE);
 
					//write record in files table
					drupal_write_record('files', $file);
 
					$result = db_query("SELECT fid,filepath FROM {files} WHERE filename = '%s'", $file['filename']);
					$file_details = db_fetch_object($result);
 
					$file_data = field_file_load($file_details->fid);
 
					watchdog('homes_sync', 'Uploaded @file into @home.', array('@file' => $full_file['filename'], '@home' => $node->title), WATCHDOG_NOTICE);
 
					if ($file_data) {
 
						if ($filetype[1] == 'pdf') {
							$node->field_floorplan[] = $file_data;
						} else {
							$node->field_image[] = $file_data;
						}
 
					}
 
				}
 
 
			}
		}
	}
 
	return $node;
}

After the file is saved to the file system and database, field_file_load() is called to load the file data. With a populated array now, we can add that to our node object by simply putting $node->field_floorplan[] = $file_data or $node->field_image[] = $file_data to append the existing array with data. The $node object is returned, and node_save($node) is immediately called, and our node data and file data are saved. Just like that, we have a simple content distribution system from one parent site to potentially many remote sites.

This is just a simple example, your mileage may vary. We are utilizing this technology to hook companies together under different Drupal installations on different servers. Using Services you could also distribute Views configurations, users, and system settings.

Up to that point, we had done every project in Coldfusion hosted on Windows (and eventually Linux). There is a price tag that came with that though, whether it be hosting, Coldfusion licensing/upgrading, or development costs. As people were let go due to the economy, we also realized that it is difficult to support proprietary code for a proprietary solution someone else wrote. Why? Because that person is the only person in the world who knows why they made the application/code that way. When something goes wrong, you spend hours trying to find the issue, and even more time coming up with a tested reliable solution.

Proprietary solutions are sold as the best thing since sliced bread, but what customers don’t know is that they are getting locked in to that company. You can’t easily cut ties with a firm and take your site someplace else. Proprietary applications are the brainchild of whoever developed it. Therefore, when you need support, you won’t get it. That developer is long gone, but you are stuck with their code. These firms put you in a box and want to keep you there- that is the whole point of proprietary systems. Why do you think you can’t install OSX on a PC? Why do you think video games are built only for Windows, and not Linux or Mac? It’s all about client retention.

With that, we decided to start fresh and drop our proprietary Coldfusion CMS and Ecommerce platforms. Everyday we were tied up in fixing Inclind Commerce, or trying to meet the needs of each client for Inclind CMS. Pete and I went as fast as we could, but we pretty much knew there was no way to compete with the rest of the world. We turned to open source solutions to provide us a solid base to build off of, instead of starting each project from scratch (which all essentially had the same core functionality as it were). Developing Coldfusion in Fusebox framework is/was an absolute nightmare and probably still is. It is a disjointed unauthentic implementation of MVC style framework despite what they say, and requires you to hold its hand every step of the development process.

We knew Wordpress would not be a solution at all. At best, it is a blogging platform and nothing more. You may read lots of articles that say how awesome Wordpress is and is a CMS, but it is not a CMS. You’ll also see that those articles are written by designers too, not developers. It’s a pain in the ass to develop for, it has patches every other week, plugins are prone to XSS attacks or theme hacking, and cannot sustain the level of development we perform. It is not a prime-time application for websites.

We also tried Joomla. Knowing it was based around Mambo, my expectations were low for it based on the experience I had working with Mambo. Even 5 years later, it had an ugly backend, scattered developer community, and little support. The developer area is full of confusing rules, practices and jargon. Take this for example, from the Joomla extensions page:

• Component – Mini-application to render the main page body.
• Module – Renders small html blocks on any page.
• Plugin – Changes code behavior dynamically.
• Language – Provides language translation.
• Ext. Specific Addon – Specific addon that requires another ext. to operate.
• Tool – External application that helps with creating or managing Joomla! site.

What the hell is the difference? All 6 bullet points say the same thing, yet they are 6 different kinds of extensions for Joomla. We couldn’t see ourselves training clients around the confusing backend or having lowered development time with their overly complicated extension system and scary licensing rules.

We came to Drupal. I had heard about this one on and off in various circles, generally more good than bad. After a week of successful proof of concepts for different kinds of websites, we decided Drupal was the best solution for us in terms of what we needed to accomplish.

Out of the box, Drupal provides:

• Database abstraction
• Auto-discovery of custom modules
• Managed workflow
• Robust Development API
• Experienced and organized developer community
• Intuitive administrative backend
• Easy integration of custom modules through the hook system

There is a solution for just about any scenario in the Drupal world. They have a very good approval process for modules. For example, if a module has security loopholes or bad coding practices, it will not be accepted until those are corrected (I don’t see this happening in other projects). If someone is trying to submit a module that already exists in some form, they are encouraged to merge efforts so the community isn’t littered with duplicate modules with the same functionality. It is differences like these that make Drupal the most widely used, highly regarded, best open source CMS bar none.

Our choice was the right one, proving vital in our relevance to custom web development and is a reason why we are still here and still the top choice for web design / web development / website building on the peninsula. We are able to deploy websites with a consistent codebase and backend in rapid succession. Clients are pleased with the added functionality and easier administrative UI. We’re at the point now where we can take Drupal and make it do anything we need it to do, big or small. We’ve been able to provide scalable solutions from the collaboration of many people providing a solid product. Instead of a couple of people making an in-house solution, we’re working with hundreds on a more polished result. We changed our entire development process so we could have a streamlined workflow and tighter communication between ourselves and the client with great results.

We have some pretty cool projects in the pipeline for 2010 utilizing Drupal and hope to have some things to show off in the next few months. iPhones, region-free real estate integration, content distribution, big boy stuff. Lookout.

There are a handful of ways to do this. One way would be to create an external database connection, talk to it, and update the data in our database through raw PHP. But that’s not really good, not to mention slow, and also very un Drupal.

Another way would be to utilize Domain Access, and publish content to affiliated sites. That works in some cases, but what if these sites are independent from each other with different companies managing them? You would then have the nightmare of dealing with prefixed tables, back-end training issues, and the occasional node overlap from misconfiguring Domain Access.

A third way would be to utilize FeedAPI (or its successor, Feeds), to read from an RSS feed. Then you could parse and import that content at regular intervals. Sounds great, but if you plan on importing custom node types that have extensive CCK fields, files and images, prepare to sit down and code plugins and parsers galore to support CCK as data sources to target.

The third way is the one I thought I could get working. It seems so simple in theory that you can create an RSS/XML/JSON data structure with Views, and then tell Feeds to take that feed and parse it. True, it works if you are using a basic content type like Story or Page, but all bets are off once CCK comes into play- and who doesn’t use CCK these days? Hats off to Alex Barth / Development Seed though on Feeds, its a great start and sure to grow into a monster data consuming module. I do want to use for future projects, just not for this function.

One way that most people are not aware of is to take advantage of Drupal’s XML-RPC functions through the Services module. In short, the Services module provides:

A standardized solution of integrating external applications with Drupal. Service callbacks may be used with multiple interfaces like XMLRPC, JSON, REST, SOAP, AMF, etc. This allows a Drupal site to provide web services via multiple interfaces while using the same callback code.

So, then we got the idea to have the ‘master’ Drupal site act as a SOAP server with the Services module, and provide our own custom services in order to get the job done. This runs once an hour, requires no user interaction, fails silently, and only requires two modules. Effectively, it also allows us to not have to use:

• Domain Access
• FeedAPI/Feeds
• Multi-site Setup

The benefit of this is every site can run independently from one another and be customized various ways, while still receiving key content from the parent website. Thus is the beauty of XMLRPC/SOAP.

The next part was to create my own custom method so I can request a list of node ID’s from the parent server. There is no method of getting all node ID’s out of the box, but you can easily create them. Here is what I came up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119

<?php
 
// CODE ON PARENT SERVER
 
function homes_service_service() {
	return array(
		array(
			'#method' => 'node.getAllHomes',
			'#callback' => 'homes_service_node_get_all_homes',
			'#return' => 'array',
			'#help' => 'Return a list of node id\'s that are of the Home content type.',
		),
	);
}
 
function homes_service_node_get_all_homes() {
	$result = db_query('SELECT nid FROM {node} WHERE type = "%s"', 'homes');
 
	while ($home = db_fetch_array($result)) {
		if ($home['nid']) {
			$homes[] = $home['nid'];
		}	
	}
 
	return $homes;
}
 
// CODE ON REMOTE SERVERS
 
function homes_sync_get_node_list() {
 
	// user authentication code here
	// connect as 'services' user with 'services' role
	// that way, drupal permissions are respected
 
	// user.login method used
	// we get a successful login if the return is an array and the array values match our login information
        // this needs a little more work so the parent server knows exactly who is requesting information       
 
	$user = 'user';
	$password = 'password';
 
	$authenticate = xmlrpc('http://upgrade.beracahhomes.com/services/xmlrpc', 'user.login', $user, $password);
 
	if (is_array($authenticate) && $authenticate['user']['name'] === $user && $authenticate['user']['status'] == 1) {
 
		$node_ids = xmlrpc('http://www.parentsite.com/services/xmlrpc', 'node.getAllHomes');
 
		if (xmlrpc_error()) {
			$error = xmlrpc_error();
			watchdog('homes_sync', 'Error getting node list from parent server. Error: @error.', array('@error' => $error), WATCHDOG_CRITICAL);
		} else {
			foreach ($node_ids as $nid) {
				$nodes[] = $nid;
			}
			variable_set('parent_home_nodes', $nodes);
			watchdog('homes_sync', 'Successfully retrieved node list from parent server.', array(), WATCHDOG_NOTICE);
		}
	}
 
	homes_sync_perform_update();
}
 
function homes_sync_perform_update() {
 
	$node_ids = variable_get('parent_home_nodes', 0);
 
	foreach ($node_ids as $nid) {
		$data = xmlrpc('http://www.parentsite.com/services/xmlrpc', 'node.get', $nid);
 
		$result = db_fetch_array(db_query('SELECT n.nid, n.title, n.type FROM {node} n WHERE n.title = "%s" AND n.type = "%s"', $data['title'], 'homes'));
 
		if (xmlrpc_error()) {
			$error = xmlrpc_error();
			watchdog('homes_sync', 'Could not perform XMLRPC request. Error: @error.', array('@error' => $error), WATCHDOG_CRITICAL);
		} else {
			if (is_array($data)) {
				$node = "";
 
				if ($result && $result['nid']) {
					$node->nid = $result['nid'];
				}
 
				$node->type = $data['type'];
				$node->uid = 1;
				$node->status = $data['status'];
				$node->created = $data['created'];
				$node->changed = $data['changed'];
				$node->comment = $data['comment'];
				$node->promote = $data['promote'];
				$node->moderate = $data['moderate'];
				$node->sticky = $data['sticky'];
				$node->tnid = $data['tnid'];
				$node->translate = $data['translate'];
				$node->title = $data['title'];
				$node->body = $data['body'];
				$node->teaser = $data['teaser'];
				$node->format = $data['format'];
				$node->name = $data['name'];
				$node->data = $data['data'];
				$node->path = $data['path'];
				$node->field_type[0]['value'] = $data['field_type'][0]['value'];
				$node->field_number_of_bathrooms[0]['value'] = $data['field_number_of_bathrooms'][0]['value'];
				$node->field_number_of_bedrooms[0]['value'] = $data['field_number_of_bedrooms'][0]['value'];
				$node->field_number_of_floors[0]['value'] = $data['field_number_of_floors'][0]['value'];
				$node->field_square_footage[0]['value'] = $data['field_square_footage'][0]['value'];
 
				node_save($node);
 
				unset($node);
			}
		}	
	}
}
 
function homes_sync_cron() {
	homes_sync_get_node_list();	
}
?>

For some reason, I can’t have two instances of wp-syntax in a single post, so bear with me. The above code is part of two seperate modules, one on the parent server, and one on the remote server (as notated with the PHP comment).

The module code (after CODE ON PARENT SERVER) resides on the parent server. This uses hook_service to talk to Services, and says expose node.getAllHomes as a request. That request method then calls the homes_service_node_get_all_homes function, which does a SQL query returns an array of node id’s that I am looking for.

I could easily return all nodes as their full node objects, but for performance reasons, I’d rather get a short list and save them on the receiving end. That way, I can create/update a handful at a time instead of all at once, which lightens the load on the database and application server.

On the receiving end, we need some code that creates the request that is sent to the parent server. Using hook_cron, I can send this request on an automated basis. The module code (after CODE ON REMOTE SERVERS) looks for the node list locally, and constructs single requests to retrieve node data one at a time. From there, it constructs a node object and saves it all with node_save. If the node already exists, based on type and title (our node ID’s will not match, but our title certainly will, since child sites cannot create or edit these nodes) it grabs the node ID from the local database and puts that in with the node object. node_save is a great function that can handle creating or updating data with the same structure. So, if the update runs again and passes us the same data, it will recognize it already has it, and update the record instead of create duplicates. Slick.

So what do we have? If we deploy the remote code on multiple remote sites, they can all sync up specific content with the parent website without anyone having to do anything special. So long as the parent site admin provides content, everyone will get it.

This is a quick implementation of course. I am fleshing out the authentication further as well as staggering the amount of data updated every cron run. With the core functionality in place, I can focus on security and speed. The next step is retrieving files and images using the same methods, and I will go over that in another post when I get a chance.

I hope fellow Drupalers found this useful, because I found that documentation on this is touch and go (and probably a reason not many utilize XMLRPC/Services). It’s a very powerful feature.

There are some ‘gotchas’ though if you develop custom Drupal modules like we do. During the install process, Drupal only bootstraps the bare minimum to get the job done. I’ve noticed that if a module’s install routine calls functions outside of the .install file, the expected result tends to fail because files other than .install are not included during this loading process. It seems there is a special case for the file to be included, or you have to specify in your install profile to explicitly include the file (which takes a lot of time to do). To be specific, I have seen this happen with Drupal Boost, Drupal Gallery Assist, and our custom module Billboard, which tipped me off to this problem. The issue has since been fixed in Boost (and Billboard).

For us, the issue was creating custom ImageCache presets during a module’s install routine. This worked perfectly if you were going to the Drupal Modules page and enabling Billboard. What happens was the hook_install() function fired, included a definition file, and created presets based on that file. This fails during a Drupal install profile, where you use a script to install and configure Drupal automatically. This same issue occurs in Gallery Assist, and here is how I got around it:

It was pretty apparent that the code needed to come out of the install function. However, I needed to be sure that where I put the code would be compatible to the module loading process, and I’d need to be sure ImageCache was both installed and loaded before running the following code. Otherwise it would error out, and no ImageCache presets would be created.

Drupal has a crucial hook for modules. hook_init() allows you to perform tasks every time the module is loaded. In this case, I wanted to tell it to run a function and check for two default ImageCache presets. If they didn’t exist, create them. This approach solves three issues:

1. Getting around install profile limitations
2. Provide default ImageCache presets for Billboard module when it is enabled
3. Recreate the ImageCache presets if they are accidentally deleted by the user (or developer )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

<?php
 
function mymodule_init() {
    mymodule_create_default_imagecache_presets();
}
 
function mymodule_create_default_imagecache_presets() {
 
    $default_size = imagecache_preset_by_name('mymodule-default');
    $thumb_size = imagecache_preset_by_name('mymodule-thumb');
 
    if (count($default_size) == 0 || count($thumb_size) == 0) {
        if (count($default_size) == 0) { 
            $mymodule_default_size = "600";
            $mymodule_thumbnail_size = "80";
 
            $presets = array();
 
            // Default size.
            $presets['default'] = array (
            'presetname' => 'mymodule-default',
            'actions' => array (
 
                  'weight' => '0',
                  'module' => 'mymodule',
                  'action' => 'imagecache_scale',
                  'data' => array (
                    'width' => $mymodule_default_size,
                    'height' => '',
                    'upscale' => 0,
                  ),
 
              ),
            );
 
            imagecache_preset_save($presets['default']);
            $presets['default']['actions']['presetid'] = db_last_insert_id('imagecache_preset', 'presetid');
            imagecache_action_save($presets['default']['actions']);
            imagecache_preset_flush($presets['default']);
            imagecache_presets(TRUE);
 
        }
 
        if (count($default_size) == 0) { 
            $presets['thumb'] = array (
            'presetname' => 'mymodule-thumb',
            'actions' => array (
 
                  'weight' => '0',
                  'module' => 'mymodule',
                  'action' => 'imagecache_resize',
                  'data' => 
                    array (
                      'width' => $mymodule_thumbnail_size,
                      'height' => $mymodule_thumbnail_size,
                      'upscale' => 0,
                  ),
 
              ),
            );
 
            imagecache_preset_save($presets['thumb']);
            $presets['thumb']['actions']['presetid'] = db_last_insert_id('imagecache_preset', 'presetid');
            imagecache_action_save($presets['thumb']['actions']);
            imagecache_preset_flush($presets['thumb']);
            imagecache_presets(TRUE);
 
        }
    }
 
    return;
}
?>

What that says basically is ‘hey, do our default ImageCache presets exist?’ if not, it will create them at runtime.

I have tested this a handful of times with positive results, and, it works with install profiles since hook_init() is called after Drupal loads. Food for thought for all you Drupal developers out there. If there is a better way to achieve this feel free to leave a comment.