Aug 03 2012
Aug 03

You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialize correctly.

Jun 11 2011
Jun 11

We are currently deploying an Aegir based system for one of our clients. The client provides a Drupal ‘reporting’ system for their software. They have many customers around the country. Each customer has a separate Drupal Deployment.

We deployed a feature server 2 years ago to manage keeping all the different sites at the same level. This was a rewrite of a .NET 1.x based system. And the client had lost the original source code. So, every time we added a new feature for one of our clients customers, it would break someone else. This was very frustrating. So from the very beginning, this project was predicated upon ease of maintenance and updates.

While we felt very successful with that aspect of the project, our client has grown to over 40 deployments. So, the process of upgrading each site was simply taking too much time.

This is where Aegir comes in. With Aegir, we have been able to reduce the ‘upgrade’ time from 2-3 hours down to 2-3 minutes. But there were a few issues we had to resolve.

The first big issue for us was the fact that each of these sites was maintaining an inventory of 10-250K PDF files. This is the essence of the reports. The PDF files are actually copies from the internal servers where the reports are generated. Since the information contained on the PDF files was not only private, but required protections from competitors, we had to put them into the Drupal ‘Private’ file system.

Now we are working with Aegir and discover that setting the ‘private’ file system on each site gets overwritten by Aegir on save. It always goes back to the same value.

Call us stubborn, but that is simply not what we wanted. We had those files on specific SAMBA shares and didn’t want to have to changed all that architecture. So we did a little work inside Aegir and found that the simple answer was to use the local.settings.php file that is optional in sites/[sitename].

The essence of the fix was to use the Variable overrides section of settings.php. But settings.php is controlled by Aegir and tends to get re-written. So we could not make the ‘fix’ there. But in an Aegir system they have an ‘include’ for local.settings.php at the very end of settings.php.

So that was it. We managed $conf inside of local.settings.php as follows:

global $conf;
    $conf['file_directory_path'] = '/var/private/files/standard';
    $conf['file_directory_temp'] = ‘sites/[site]/files/tmp’;

Where [site] is normally replaced with the site name.

Dec 23 2010
Dec 23

Drupal Made Easy

Here at the Worx, we love Drupal. We have been using it since 2005 and are fully commited to it. In fact, in 2008 we made the decision that all new projects that we accept will be done only in Drupal. This has worked very well for our clients as well as for us.

As we continue to learn and grow in our Drupal world, we find, as do others, that it could be made easier. And so, we have been working diligently on that effort for some time now. We have sponsored the development of a module known as Contextual Administration. This has provided excellent results.

Because of our use of Contextual Administration, we have been able to lower our training timeframe for a client from 4 hours to about 1. The client has less to learn and consider, so it is significantly easier to retain the information. This has been recognized by our Help Center because the call load for new clients has dropped by more than half. 

While this is a good thing for us, it is a great thing for the client. It means that when they get the itch to work on their site, they can do it at any time. Not just when we are available on the phone to help :)

We have been using this now for our clients for about 6 months and the feedback has been excellent. Another thing that we have begun for our clients is we now provide free hosting with the purchase of a monthly maintenance program. The obvious benefit for the client in this case is that the website cost is extremely predictable. For one flat fee, they get a site that stays current, has all the security patches applied, and a guarantee that if the security is bypassed, the 'repairs' are coved by the monthly maintenance fee. This provides the added benefit that when they want to add a new feature to the site, we don't have to include any upgrade fees because the site is already current.

May 20 2010
May 20

I’m a Command Line type of guy. I don’t appreciate have to move my hand back and forth to a mouse to get something done. 

There are some great GUI based MySQL tools out there and probably my favorite is Sequel Pro on the Mac... But that isn’t the point of this blog today.

There are many times that I am at the Command Line and need to get something done. Being lazy (see title) and not using MySQL command line tools every day, I built a script to handle some defaults and remind me of some options.

I called the script (written in Bash) simplesql. This has been published on github for your access and enjoyment.

Some of the features of this script are as follows:

* An optional configuration file where I can store server name and aliases, along with usernames, passwords, and default database names.

* a quick access CLI mode “simplesql -o sql02”. This command uses the alias ‘sql02’ to lookup the servername, gets the user/passwd from the config file, and without other instructions, goes into edit mode. Behind the scenes this basically launhes “mysql -u b3sql02.domain.com -u root -ppassword” and I am in MySQL ready to do some adhoc Command Line work.

* a Dump, Import, Copy, Clone, & Export set of commands. Export will output CSV formatting for a table.

* run a ‘top’ like program to provide statistics for a particular server.

* A couple of Drupal specific commands. One is a dump without the watchdog, session, & cache data. The other is a mass updated to change the admin password

Security is a big issue and some of the features of this script are more geared for a smaller or mid-sized environment. I have left those features in the script as they were very useful to us until our growth demanded a higher focus on security. Today we do not use the external storage of password in the config file. That was a policy change but the feature should still work. Another security issue is that early on, we would have a common ‘admin’ password. So, the alter command came in very useful to do mass changes to that password with personnel turnover. Use it at your own risk  

Well, that is about it.... It has save me a lot of time and trips to the man pages over the years. I hope you might find it useful too.

May 03 2010
May 03

My client wanted to be able to search their list manager archives (uses mailman) with Solr. We already had a pretty major investment in Drupal with about 80K PDF files. In the past, each of the different databases were managed by seperate dtSearch indexes. With the new, Drupal system, we are now able to consolidate everything into one master index. With the special ‘faceting’ that is provided within Solr/Drupal, it becomes very easy to drill from the general request down to the specifics.

Well, this article is going to get a bit specific on the why and how of the integration we did between mailman data and Drupal.

Mailman keeps its archives in a directory structure that provides a single file <listname>.mbox and a directory <listname>. I selected the directory as my driver for getting all the files across. After I got everything written, some more research indicated that I might have been better to use the <listname>.mbox file, as this is ‘authoritative’ for each list that mailman handles. But, I have working code now, so I will live with this decision for the time being.

The general process is as follows:

A) One Time Procedures

1) create a directory under sites/default/files. I called mine mailman. This is where all the list subdirectories will live.

2) create a Content Type in Drupal using just Title and Body.

3) install my Python script in the directory from step A.1 above.

4) Make sure that a current release of drush is installed

5) install my drush script in the sites/default directory

B) Repeat procedures

1) rsync all of your lists that you want from the mailman server to the A.1 directory

2) run the Python script. This will create a list of all the eligible archive files, and then call the drush script once for each file found.

Mar 23 2010
Mar 23

Websites are a critical component for any business striving to succeed in today’s competitive landscape. But just having a website is not enough, you need invested knowledge and expertise into the site design for the most efficient and effective online presence possible. Every website has the potential to reach its target audience and maximize its return on investment, but not all websites succeed. It is the sites that are consistently using professional Drupal website design components to exude credibility and trust that experience true online success.

The first component to a Drupal website design is the look and feel, or presentation, of the site. It is the visitor’s first impression of your site, brand, and company as a whole. Professional illustrations, graphic design and photography always enhances a site’s look and feel, but not at the expense of the other components. Visual elements should always act an appropriate enhancement of written content and functionality.  You don’t want to be too flashy or techno-savvy because it may look too expensive (or hokey) for the company’s budget. Drupal website design consistency is also essential in providing the user with confidence and freedom to find information on your site.

In recent years, website usability has become increasingly important for delivering a quality user experience. Website usability is the ease at which a visitor can use the site. It starts with good site architecture, or structure, for quick navigation and links to easily accessible content. It should also be a priority to stay current with the latest web and accessibility standards, such as XHTML 1.0, JavaScript, or PHP and use them to your advantage.

Effective content writing is one of the most important aspects of the overall website design. Your company’s call to action, value proposition, and product or service should be the all-star of the homepage. The written content needs to be compelling, informative, and relevant to your target audience. Most visitors will only scan content, rather than read as meticulously as you do, so extra attention must be invested to optimize its scan-ability.

Your website can be the epitome of design, but it won’t be appreciated if no one sees it. A website will fail if it doesn’t have quality traffic. Quality traffic comes from three different sources. People who come directly in their browser, through a search engine, or a link from a different website. Search engine optimization (SEO) and marketing will drive traffic to your website through careful planning and execution of internet marketing and correct coding.

The most important goal of a Drupal website design is to create results for your business. For most companies, this means generating leads and prospects and converting them into sales and clients. If your site’s presentation, usability and content are professional and you are getting quality traffic, you stand a great chance of winning business and increasing your overall conversion rates.

Being found on the internet is a difficult, but rewarding achievement. Once traffic is flowing onto your site, it is critical that a credibility and trust awaits the visitor via presentation, usability, SEO, and quality content. Only then can you ensure quality  targeted traffic and increased, consistent conversions. However, not all businesses have the internal capacity or resources to invest in these design components. The Worx Company is an Oklahoma-based business with over 10 years of experience developing Drupal website design. We are a team of highly efficient consultants, coordinators, designers and programmers, all dedicated to providing the highest quality and best service for your Drupal website design project.

_____________________________________

Author: Ethan Luke. 10.01.09.

Mar 21 2010
Mar 21

If you've been following my blogs about the various administrative interfaces we've been playing with, you'll know that I've proposed the idea of building a system through which these sorts of administrations could be deployed by site administrators without the need to understand what it would take in terms of module development to do so for themselves.  Since I started playing with this stuff ctools has really become very common place, and it's page_manager module is perfect for doing this sort of work.  With that in mind we're announcing Contextual Administration module.

Contextual Administration is a ctools dependent module designed to deploy single page interfaces that would be impractical to deploy in a panels type interface.  It comes with a number of built in plugins for things like node creation, user creation, and taxonomy administration.  Creating your own plugins is easy (though I'm still working on the documentation for that particular feature).

Why not just use panels?

This is a completely legitimate and understandable question because well... panels is awesome.  The reason our plugins don't just interface with panels is because while having node_creation forms as plugins to panels would be cool, it gets impractical pretty quickly if people start trying to utilize multiple forms together.  For the sake of simplicity (and sanity) we chose to just provide our own interface to page_manager.  The upside to this is that we get the ability to mix our variants with panels variants so we still get the best of both worlds and it's simple enough that anyone can deploy a context_admin page without needing to understand everything that panels can do.

What features come with it out of the box?

Our main focus in developing context_admin was to provide a menu based administration system that could be deployed anywhere at any time.  Personally I use this to deploy new administrations through "tabs", or MENU_LOCAL_TASKs for the more technically inclined.

Since we've interfaced with page manager, these page definitions can already be exported, and will bundle into features module with no additional work.  You can bundle them just like you would a panel.

Out of the box we currently (beta4) provide plugins to allow for:

  • node creation of node type X
  • node creation of node type X as a menu child of the parent node (requires a node/%node/* path currently)
  • node creation of node type X with an automatic node reference (requires a node/%node/* path currently)
  • taxonomy term edit
  • taxonomy vocabulary edit
  • taxonomy vocabulary term list
  • taxonomy vocabulary term add
  • taxonomy term add as sub term (requires taxonomy/term/%term/* path currently)
  • user creation (with tons of configuration here, you can auto-assign roles, status, and more)
  • Node administration of node type X via a views_bulk_operations style view (requires views_bulk_operations module)
  • Administration Sections (these can only be used in conjuncture with a /admin/something path.  You simply add one of these, and then add links to that through the typical menu system, and it will build up your own administration section just like "site building" or "site configuration")

We intend on doing a user administration via VBO as well but it's not in the current beta release just yet.  We may also provide our own actions that don't require various user perms to make the VBO based administration a bit more usable without having to hand out administrative privs to users.

WHOA?! Isn't that a security issue?

Uh... "YES", yes it is a "security issue". With that said, let's cover that topic for just a moment.  Any time we're allowing for nodes to be created w/o the user having the perm to do so, that's a "security issue" as well.  What is worth pointing out here, however, is that there's still security here, it's just up to the site administrator instead of being hardcoded by drupal core.  Drupal 7 has already been altered to work this way in a number of places, not the least of which is node creation and user creation.  It's frankly sad that VBO was forced to alter its existing functionality to cripple this power to begin with.

What that really means is this:  Drupal 6 utilizes a number of additional checks over those already provided by the menu system to determine if user X should have access to perform task Y.  Now the menu system actually did this check already (for example, "create page nodes").  The menu system is already running a user_access() check against that perm, and if it's NOT it's because some other module has altered the menu to do something else.  The node_add() function does an additional check against this same set of parameters before it will allow a user to actually even visit the node creation form for pages.  If the menu is altered, then this blows up spectacularly (which is why context_admin is actually providing its own version of node_add()).  This same is largely true for user creation, except it's a lot messier there.  Both of these functions have gotten some love in drupal 7 so that the menu system is the one in control, and thankfully this means that as developers we got a LOT more flexibility out of drupal core.  It also represents a bit of a shift from a security perspective in that we're recognizing that the menu system really should be in charge of these things.  Thus I would say the logic goes for VBO (and context_admin) in the same way.  The site administrator is in charge of preventing users from visiting these administration pages, and if he doesn't it's not actually a security issue for the module.

Why are you bringing this up?

It's sort of odd to be pointing out issues in a module I just released, but I'm afraid I need to make my argument FOR my approach before I start getting security issues filed against me.  I feel VBO was unfairly picked out in this regard as well, as views provides a perfectly good solution for access control to a view.  The point is, drupal 7 has already embraced this logic in many places, and we get a LOT more development power out of it.

Quick aside, I've been using this in production for a while and am quite happy with it.

Kris "EclipseGc" Vanderwater

Mar 07 2010
Mar 07

MacHeist is up to their same tricks and have just released a new bundle. Inside that bundle is a product called MacJournal that has tempted me.

So, I have downloaded a 15 day trial and started to play with it. The first thing I wanted to do was make sure that I could use it for my blogging.

Here are the highlights, if you don’t want to deal with a 22 minute video <grin>

At the address “admin/build/modules," in the Admin section, set on Blog API (in core optional).

At “admin/user/permissions” set “Administer content with blog api” for the roles you want to have this access. You will also want to set “Administer node”.

At “admin/settings/blogapi” enable the content type(s) that you want to be able to post to. This would be at least ‘blog’. But you can use others.

Optional Steps:

If you want to allow for images in your blog, then at “admin/settings/filters/list” make sure the <img> tag is allowed for your role.

I found this step to be optional, and in my case, unnecessary. Install Content Access found at http://drupal.org/project/content_access

admin/content/node-settings If you are still having problems with all the permissions, you “May” need to rebuild permissions here.

Dec 01 2009
Dec 01

Here at the Worx, we often build Drupal websites as intranets. These have on many occasions, become full office automation centers and allow for faster work and better communications. But, they are also VERY custom and require a large degree of testing by the customer as we move towards production.

There are a variety of 'tests' that an application must go through before it becomes production. Most of this is done behind the scenes by the developers as they work their way through the development of your new application.

There are also a variety of 'tests' that only the client can perform. If the website being developed is more of an 'application' then just content for general consumption, the client responsibility goes up dramatically.  Like any other application that is written, this needs extensive testing. This usually includes at least beta testing and often, parallel testing. In many cases, this is done one section at a time.

Beta testing really means that you are aware that errors WILL occur. This is the 'dry run' time where you try every function of the application multiple times. Does it do what is expected? Is it consistent? Is the user interface acceptable? All of this testing should be done with a notebook by your side and extensive notes taken to feed back to the developers any problems you may encounter.

Parallel testing is used whenever you are replacing an older application with something new. In this instance you will do all your processes TWICE. Once in each system. The basic question here is simple. Do you get the same results out of both systems? If not, is that what you expected? Part of the reason for the replacement might be improvement and correction. But in most of the application, you should get the same results or be able to explain why based on new functionality.

Any time an application is being replaced, it is absolutely imperative that a parallel test occur. To go directly into production with an untested application is suicide. If you take a new application and begin using it for production WITHOUT parallel, then you simply failed to test and will get problems. Usually lots of problems. 

So, in summary… If you have a new application with new functionality, you will go through a Beta phase. If you are replacing an old application with a new application, then you will go through Beta AND Parallel. Don't skip the Parallel or you may never know what the problems are in the new application until it is much too late!

To truly enjoy your new application, remember that testing is a very important part of the client responsibility.

Oct 19 2009
Oct 19

We had a client requirement that a single view be the combination of:

  1. a random list of attorneys with offices in a given state
  2. a random list of attorneys that are licensed in a given state.

There should be no duplications and all of list 1 must precede list 2. We could not accomplish this with views alone. After talking to Earl, we were able to access the created SQL statement within views. Here we built each of the two queries. Then, we defined a 'pre' exit and replaced the query in our view with a new one.

The new query is in the form of:

SELECT node.nid FROM ( ( select #1 ) UNION (select #2 ) ORDER BY .... ) AS node.

This is especially important in that we absolutely have to name our selected fields the same as what views would typically name them. If you don't preserve the same naming structure it will simply not work. Now this is only true for the selected fields. Fields on which you join, filter, etc can utilize any naming convention you desire. Of course, both of the select statements were required to provide the exact same column output.

So, as an example the statement looked something like: (with LEFT JOIN detail left out for easier reading)

SELECT node.nid
FROM (
  ( // First select statement
    SELECT node.nid, RAND() as _order
    FROM node node
    WHERE node.attorney_state='%s'
  )
  UNION // concatenate to next
  SELECT
  ( // Second select statement
    SELECT node.nid, (1+RAND()) as _order
    FROM node node
    WHERE node.licenses_state = '%s'
  )
  // This does the sort on all the selects together.
  ORDER BY _order
)
// Now, for Drupal, this outer select MUST be aliased as 'node'.
AS node;

Some of the secret sauce was:

  • use of an outer select with an internal union
  • The outer select needed to be aliased to node for it to work.
  • we only needed the nid as all the data was pulled using node-> syntax.
  • There seemed to be bug in cck based on this, obviously, edge case and it took 2 lines of code to fix.
    • cck expects 'vid' to absolutely have a value.
    • wrapping an if ($vid)... around that expectation removed the warning error that we were getting.
    • bottom line... we hacked it, but hopefully it will make sense to the cck authors and it can be submitted back to the module.
  • the views hook was hook_views_pre_execute(&$view) and we altered the query directly via $view->build_info['query']. If you'd like to preserve the dynamic nature of certain aspects of the views interface, you must respect your $view->build_info['query_args']. This may require some alteration as well.
  • Note that we did a RAND() and 1+RAND(). This is because RAND() returns a random decimal between 0 and 1, thus 1+RAND() would be a random decimal between 1 and 2, allowing us to order by this random number and be sure that our second query's results ALWAYS come after the first query.
Oct 10 2009
Oct 10

If you've ever used the drupal views module, chances are at some point you've needed to suppress any output until AFTER the user has made a selection from one of your exposed filters.  Views actually DOES make this possible, but it's not exactly self-evident.  I'm going to run you through a quick "howto" on this as I'm sure many people have needed it at some point.

As I mentioned above, this is possible but not particularly self-evident.  Views has a number of different "global" group items.  The most common of these is probably the Random Sort.  Within arguments you also have another member of the global group, the global NULL argument.  This is basically a way of attaching your own rudimentary argument to a view.  Through the use of the default value (as custom php) and custom validation (again through php) you could cook up just about anything.

With our global NULL argument in place, the following settings are about all we need to make this really work:

1.) Provide a default argument
2.) Argument type -> Fixed entry (Leave the default argument field blank as what gets passed is irrelevant to our needs, we simply needed to make it to the next level which is validation
3.) Choose php code as your validator
4.) Check through the $view->exposed_input array.  I recommend using devel module's dsm() function here because it will respond on the ajax that view is using (unlike drupal_set_message()).
5.) Set "Action to take if argument does not validate:" to "Display empty text"

You can get as fancy in step 4 as you need, but it's just down to good old php if statements at that point.

I hope this howto helps other people.  We've found it rather useful, and since it's sort of arcane, I wanted to share it.

Thanks to Earl Miles (merlinofchaos) for pointing me in the right direction on this one!

Oct 09 2009
Oct 09

Currently there's a pretty in depth discussion surrounding hosting install profiles on drupal.org and what the legal/other implications of such a thing are.  I feel this is an important issue to highlight to the community at large, and since I feel rather strongly about it, I'm using this forum to point it out, and also to focus a bit on my own feelings concerning this.  For those of you who would like some context, read this post on drupal.org.

This specific issue is surrounding the wonderful new possibilities revealed by the new drush make library on drupal.org.  In short, drush make provides the ability to build a simple file that drush will process and from which, build a full drupal platform.  In terms of install profiles, this could be exceptionally useful as authors could easily build a robust platform of all dependencies that their install profile will need to work properly.  Now the work of building the profile still has to be done, but install profiles are essentially a set of configurations for the various modules your profile specifies. 

Currently install profiles are distributed "as is" on drupal.org.  There is a proposal to start providing profiles as fully built tarballs that are simply ready to be installed, and drush make would make this rather simple to do, however there is a bit of fear that this will open up drupal.org to a large level of legal issues due to various licenses of the softwares involved.  This may seem like a "what?!?" at first, until you understand that drush make can actually pull software from external sources.  In short, if you were inclined to have a fully functional wysiwig editor in your install profile w/o the need for custom configuration/installation, this would be totally possible.  However, the community typically utilize tinymce, or fckeditor which are all external programs from drupal itself, thus the legal issues ensue. (In fact this is just the tip of the iceberg, drush make can even apply patches posted to specific issues on drupal.org, but I digress)

So, all the legal mumbo-jumbo is... non-trivial.  And I'm certainly not trying to trivialize it, however we HAVE to recognize that this is THE killer feature of drupal in years to come.  If we nail this profile thing, you could literally build profiles that replicate the other platforms we compete against, and we'd all still be benefiting from the same core/modules as necessary.  Want a wordpress clone? Want a Joomla! clone? Want a profiles with a simple UX approach to the same core you know and love?  We know that where competition thrives, so does innovation, and the drupal 7 release, while I'm sure it will help significantly with some of our UX woes, is not the "be all, end all" of UX bliss.  Make profile distribution on d.o easier, more powerful and come up with a solution that doesn't exclude external code libraries and we will be well on our way.

In short, fully realized install profiles are a game changer for the entire CMS market (in my opinion).  It essentially reduces "Drupal" to a development platform, and leaves the "content management" needs up to the profile developer. Drupal.org needs to step up and support this as much as possible.  If d.o doesn't I can guarantee that some other site WILL, and that will not benefit the community at the same level.

Sep 19 2009
Sep 19

It's about freaking time!  As a professional web development shop, sometimes your website can suffer from the "cobbler's kids" effect, namely you're so busy working on other people's websites, that you haven't taken any time for your own.  I've been working to remedy that for a little while now, but I'm always up for trying something shiney and new, so... I decided to do it in the (fairly) newly released Panels 3 module. For those of you who have not yet tried Panels I can offer no stronger encouragement than to say it is the best thing since cck and views. I've not yet had the pleasure of exporting panels into their own module (think views export) but the maintenance possibilities here are very exciting.

I can tell you that the vast majority of the public facing portions of the site are built entirely in panels.  The front page is it's own special layout, as well as the internal pages.  Panels has made creating your own layout plugins incredibly simple (never mind the flexible layout that's included in core).  I've tried to donate back what knowledge I've gained as I've done this through a couple of patches (some documentation for panels, and the footer message page element for ctools).  It's sad to me to see panels show up so late in the D6 cycle, but despite that, it's so promising with the various features and powers it provides, this alone could revolutionize the way you build Drupal sites.  Panels has ACTUALLY simplified my theme.  The ability to represent the layouts I wanted within panels, without the need to build a page-front.tpl.php and a page-blog.tpl.php etc etc was really empowering.  I utilized Zen for this version of our look (which we'll be updating soon) and I actually simplified zen's default page tpl file by removing $title, $tabs, $footer_message and a few more things.  True, I had to re-configure these things within panels, but the simplicity of doing so, and the flexibility of the end product made it well worth the effort.

There were a number of SEO wins as well.  The primary win was that of node titles and h1/h2 issues.  There are a number of ways to solve this particular problem, but as I mentioned before, I removed title from the page tpl file in zen.  This is because panels allows me to override the individual node's title (with nothing in this case) and then have it displayed in the page title (h1) instead of the typical node title (h2).  This is great for singular nodes, again panels simplified any sort of alterations I might normally have made to my theme layer by just providing the options I wanted right out of the box.

The removal of tabs from the page tpl was an administrive aesthetic one.  I didn't want my tabs over the entire panel, I wanted them in with the content to which they pertained.  Again the panels tabs page element provided this right out of the box (you need to be running dev version of ctools to get more than one page element on screen at the same time).  In addition to this, I wanted my footer message as a page element, but it wasn't part of ctools plugins yet.  Merlinofchaos has made it very easy to add in new plugins of these types.  With just a little bit of work, I had my own footer_message plugin built very quickly. It worked exactly as I had hoped it would, and allowed me to build a great footer minipanel.

Minipanels really are a wonderful tool as well.  I built an additional layout style specifically for my minipanels so that I could utilize them with the most efficient markup possible.  Panels, by it's nature, adds a little bit of markup to whatever you may be doing layout wise, but most of this is helper markup for node edit links and things of that type.  Howere, if I know for certain that the content I'm dealing with is going to end up in a div of its own at the end of the day, having minimal (or no) markup surrounding it, but still having the ability to group it together is very powerful.  For the footer I built an "empty" layout, that was literally one region with no markup.  This meant that utilizing minipanels to build up grouping of content that would be the same from one page to the next made a great deal of sense.  With that in place, I built my footer once, and simply included it into the same region of the various panels again and again.

In all, panels is an amazing tool.  I will certainly be utilizing it more.  The new apis it provides are very empowering, and can simplify your maintenance needs pretty significantly.  If you haven't tried panels yet, I'd heavily encourage you to do so.

Jul 08 2009
Jul 08

We have installed a 'solr' server for the use of our Drupal sites. It has been an interesting experience so far. Many thanks to all who have blazed the trail ahead of us.

I started getting the error

"500" Status: Internal Server Error in apachesolr_cron

on our main testing Drupal site recently. The error was showing up in  Adminstration -> Reports -> Recent log entries. I ran a few google searches and didn't find an answer. The index on this system is on the order of about 100K nodes. We had done some updates that required a 'rebuild' of the index. The error started to show up late into the rebuild process.
Well, I was looking in the wrong place. The 500 error was NOT coming from our Drupal server. It was coming from the Solr server. Something that just wasn't obvious from the error message that I could see.

Anyway, turned out that the error was very simple. The 'rebuild' of the index ran the system out of disk space. I killed off some old logs and all the RPMs that were used to install the solr system, and that provided enough space for the rebuild to finish and the old index to be removed.

All is well again, but , for all the Google searching I did on this error, and the lack of response, I thought it would be a good thing to share what fixed it for me.

Enjoy

Kurt

May 12 2009
May 12

Oklahoma's very first Drupal Meeetup is happening tonight!  We have a relatively small Drupal community here, but we are getting together tonight to meet each other, and discuss how we can further the Drupal community in Oklahoma.  We are guessing between 5-10 people will attend at Panera Bread for an informal gathering.

The Worx Company has been collaborating with Francis Tuttle Votech to formally create a Drupal Users Group (DUG).  Francis Tuttle has expressed an interest in furthering the Open Source community, but wasn't sure how they would go about it.  Working with us to create a DUG in their facility may be the first step to what's to come!  We will be planning regular DUG meetings soon.

If you live in Oklahoma and would like to attend our first meetup, it's tonight (May 12th) at 7:30pm, at Panera Bread.  (Meridian & Memorial, across from Mercy Hospital)  See you there!

Apr 24 2009
Apr 24

So, I have been inspired from a recent video to go play with AEgir. I thought I would try it on my laptop, so off to install DAMP.

I must say, I was very impressed with the DAMP install. Simple, straightforward, quick. Oh yea, and it 'Just Works'! Very impressive. I played with the Drupal install for a few minutes and it all seems in order.

So, a little light reading on the AEgir page and it seems I need to start with installing 'drush'. A quick read of the instructions and well, this is different. A download from d.o that is NOT installed as a module. No problem and off we go.
Run through the steps in the README and change to the drupal base directory. Run drush and there are a few problems. Some warning messages. I push a little deeper and find that DAMP doesn't include the 'mysql' client. The server is there, but no client command to run. It seems that drush needs this for some of its 'sql' features. Another thing that I noticed, but thought was related to the missing client was that the 'drush sql conf' command returned an empty array. We will come back to that in a moment.

Well, I thought, ok, let's install MAMP then and see if the client is there. Sure enough, the mysql client is part of MAMP. Got them both running. Ran an export from the DAMP side. Ran an import on the MAMP side. And then copied the Drupal install into the MAMP directories.

Back to that empty array. I don't have any idea how Drupal under DAMP was accessing the database. I really need to dig a little deeper. This could be interesting. The $db_url entry had a purely generic setting. No real userid, password, or database name. So, of course, after the copy, I still had that generic entry. I replaced that with $db_url = 'mysqli://root:[email protected]:8889/acquia_drupal'; (these are the defaults) and the acquia install came up just fine in the MAMP environment.

So now I get to go back and play a bit more with drush. The 'drush sql conf' command actually displays the expected output, so it seems that it must be reading the settings.php file.

So far, I would say that the DAMP installer could use:
#1) a mysql client
#2) a conventional settings.php file entry for $db_url

It should be noted that I have just started playing with the whole drush / [DM]AMP environment and have probably made some incorrect assumptions or outright mistakes.

I'll keep plugging away at it and see what else I can find.

First thing to look for is the right place to post this where the developers can see it.
So many different interacting parts though. Not sure if it should go on AEgir, drush, or acquia (DAMP).


About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web