drupal

Some of you may remember when Wikipedia and others went dark in protest of the SOPA and PIPA. This was a huge movement that was (probably) the main reason why those bills did not get passed. It was also the first time that such a number of large websites protested in unison in such a significant way; a very monumental occasion for the Internet. Unfortunately, there are still many freedoms to protect and legislation to speak up against.

Be a Superhero!

But, you can help out! Today, the Internet Defense League launches to help make the tactics described above into a real call to action across the world on any website. "Think of it like the internet's Emergency Broadcast System, or its bat signal!"

Do you have a Drupal site?

Well, if you do, all you have to do is install the new Internet Defense League module and when the League needs you, your site will be called upon to help protect the freedoms we enjoy so much on the Internet.

I believe in this

I care about our freedoms, especially on the Internet, and will often throw some Tweets around about how people can help or important topics. But I rarely will write a blog post, even write code, for an internet movement; not because I don't care, but because its a fast changing place and its hard to tell what will really stick around the Internet. I believe in this effort: a distributed network of websites that can all speak out at once. (The main thing I worry about is how often it gets used; you can't call on Batman every day)

The first ever Drupal Mapping office hours will be held Thursday, May 10th, 2012 at 1PM EST in the #drupal-geo IRC channel (if you don't know about IRC, check out the Drupal IRC docs). Brandonian has spearheaded this effort, and will be joined by myself, phayes, and other great community members working in the Drupal geospatial sector. Besides offering general help with mapping, handling geospatial data, and related topics in Drupal, we will be discussing the following:

• Organizing a documentation sprint around an upcoming Drupal event TBD.
• Meta discussion about office hours in general/planning for next meeting.
• The state of geospatial in Drupal, specifically for a presentation I am giving at the Twin Cities Drupal Camp and possible at DrupalCon Munich.
• Event on Groups.Drupal.org

In the current D7 development branch of the Drupal OpenLayers module there are some really great interface and styling updates that will make maps a lot more exciting and more intuitive to use.

Before

After

The images above are screenshots (click to expand) of the default maps that currently come with the stable version of the OpenLayers module and library (before) and then new styling for default maps in the development branch (after). Let's go through the changes:

1. New image set based on MapBox's image set and filled in by ndagire. This is huge! The default image set that comes with the OpenLayers module is pretty ugly; see for yourself.
2. New default feature styles. This was a no brainer once we got new images. It is much better than that orange color.
3. Provided markers come with the modules, a combination of ndagire's images and a couple markers I made, the module now comes with some markers out of the box. Besides this being visually exciting, I think it will help people grok the module more easily.
4. New popup provided by Harris Rashid which goes very well with the new image set.
5. New map styling to compliment the image set. A little CSS can go a long way.
6. New Mapquest tiles by default. mikl helped get this tile set into the module core. And though it was tough to let go of the OpenStreetMap default tileset, the MapQuest tiles are actually based off the OpenStreetMap data, don't require a third-party library, are free, and look so much better!
7. Wrap dateline (not numbered) is when the tiles repeat themselves as they go past the International Date Line which means as you pan east or west, it keeps going. This is a bit nerdy, but it means that the map fills up the area completely and looks much better.

So, all in all, an amazing improvement to what was a mediocre visual experience out of the box. I am really taken back by the contributions of the community to make this happen. And considering that I have talked twice about Making Beautiful Maps in Drupal both here and here, it was about time this became more of a reality.

Map Previews

I have also been adding some interface improvements to the OpenLayers UI module that comes with the main core module. If you look at the After image above, you'll notice it says "Preview". The map building interface now has a preview button so that you can see the map before you even save it (data and all). This is really great, as before you had to save the map, then go to the display page (done with the Views module), just to see if it worked. I can't believe I hadn't done this earlier.

Style Previews

When listing styles in the OpenLayers UI, you will now see a marker preview for the styles with icons, and a little map thumbnail for vector based styling. The icon preview was done by Pol at the OpenLayers Sprint at DrupalCon London. The map thumbnails are actually little OpenLayers maps that show a random place with the style on top.

When editing styles, there is also a larger map to preview the style. This is a larger map, but same principle as the list. This also contains crosshairs so that you can see how the style is centered on the feature it is representing.

Layer Previews

Coming soon. This is not implemented yet, and a bit harder to accomplish as often layers require maps to be certain ways. But I think we can still have this doable for the majority of layers.

Testing

All this work and more is currently in the development branch. There are some known bugs. Any help testing out would be greatly appreciated. Please put any bugs into the issue queue. I am hoping to have some time over Thanksgiving to follow through with this sprint and get out another release (probably the final alpha).

I can't believe it's been just about 6 months since Drupal Copenhagen. But it's that time again to come to together in Chicago to talk on geospatial topics in Drupal. There are a number of things going on in this area. Birds of Feathers (BoF) discussions time and place should be determined on Monday.

Thomas Turnbull and I are giving a presentation about how to make your maps beautiful in Drupal on March 9th Wednesday at 1PM. This will be focusing on what are the many different levels of customizations you can do to get a look for your maps that best fits in with the design of your site. The audience of this presentation spans across site builders, themers, and developers. We will talk about many different modules like OpenLayers and GMap and tools like Cloudmade and TileMill.

There will be a BoF focused on GIS-related developers in Drupal. This will focus on how we can, as a community, create a more consistent architecture and interoperability of geospatial functions like data storage, geocoding, and mapping.

On the flip side, we'll have a BoF discussion for geospatial modules users to converse about issues that happen, what are positives of modules, and general experiences.

I hope to see you in one of these places! Let me know if there are other things in this area that are happening that I have not listed.

BoF to learn how to review code contributions on Thursday 26 August 2010 at 16:00 at DrupalCon Copenhagen.

In just a few short days, DrupalCon Copenhagen 2010 will begin. I am super excited, especially since I was really fortunate enough to get a scholarship from the Drupal Association. I am still a bit weary of the possibility of being stranded because of a volcano again.

There is a lot happening in the Drupal world around geospatial-related technologies and putting a sense of place to data (I never know the right term to encompass all that). And fortunately, there are a couple of geospatial related events going on at Copenhagen, and hopefully lots of ad hoc discussions in the hallway. No matter your expertise, if you are interested, please come on out, and feel free to stop and ask questions (though I can't promise I have all the answers).

Mapping in Drupal with OpenLayers

Myself and Thomas Turnbull will be giving a presentation on Mapping in Drupal with OpenLayers which will focus on giving an overview of how the module works, alongside a live demo of the cool functionality that this module offers. It will be focused for mostly people that have not used the module before, but given time will discuss some architecture as well.

You can even get a sneak peak at the presentation on GitHub (not finished yet). You can also put together your own demo site with the module, make, script, feature set extravaganza on GitHub.

The presentation will be 25 August 2010 at 13:30 in the VPS.NET room (right after Rasmus' crowd-sourced keynote).

Drupal and Geo-Stuff BoF

I have also reserved a BoF space to discuss the state of Drupal and geospatial things. It'll be a very open discussion, but ideally we will focus on the following:

• The state of the Drupal GeoCMS.
• What is missing?
• What the future holds?
• How do we get there?

The BoF will be 25 August 2010 at 16:00 in the BoF Space 4.

I have the great honor of attending DrupalCon Copenhagen in a couple weeks, via a scholarship again! I am still mad for missing DrupalCon San Francisco a few months ago due to a stupid volcano. Like in SF, there is a Core Developer Summit, and like before I have put together a basic set of slides to address a simple, but important topic: The unwieldy issues with up to 400+ comments. Embedded presentation below:

Drupal 6. Please note that most of this is sound advice but that some of it is still being debated as far as what is best practice, specifically how to ensure that exportable structures are translatable. I encourage you to leave and read the comments.

The Tools

Drupal's Core Function: t()

If you have written a module, you should be familiar with t(). Almost every interace string you write in your module should be wrapped with t(). This function creates a mechanism so that the core module, locale, can offer translations for non-English languages. Without using the t() function, Drupal would have no idea what strings are translatable and this would be very limiting for sites that were not in English (or not just in English).

The limiting nature of t() is that there is no identification on strings. This means that Drupal is not really keeping track of changes in a string and there is no way to remove old strings that are no longer needed on the site. This is a bad thing for user-defined strings, strings that are entered into the interface, for example the title of a menu item, since it can change often.

The i18n Module

The i18n module (i18n is used based on the number of characters in the word internationalization), offers a set of modules to make Drupal a much better platform for multilingual sites. It offers the ability to translate some of the main structures of Drupal, like menus, taxonomies, blocks, and variables, as well as a more usable interface for translating.

The i18n module also offers a mechanism for translating strings that are based on identifiers for strings. The i18nstrings($name, $string, $langcode = NULL) function allows for better management of user-defined strings.

The Problems

Translatable Strings in Code

Though this problem is solved in core, it is still valid to point out in all of this. Interface strings (and other messages) that are defined in code, need to be translatable.

User-Defined Strings

Interface strings and messages that are inputted by the user need to be able to be translated. These almost always live in the database. The main issue here is that there needs to be a mechanism to identify each inputted string so that changes can be maintained properly.

Denoting Translatability

With modules that utilize a flexible plugin architecture or other dynamic system, one big issue is how to track what fields (or other data points) need to be translatable. This is very important to ensure that making something translatable is not hard-coded.

Exported Data

Recently (well, Views has done this well for a while), there has been a lot of work towards making Drupal structures that have the ability to be imported and exported. The main benefit of this is that it allows for setting-type structures to live in and be maintained in code. In turn, this means that a data structure that may contain interface strings and messages can be stored in either code or in the database.

The Solutions

I have always dreamed of going into space. I often ask people if they would go out into space if given the chance; I think it gives a small bit of insight into someone's personality. I doubt I will be able to make it into space in my lifetime, though I think it'll be close. But, if I can't go, this site can still move to Mercury.

Pretty cheesy intro, I know. What this actually means is that I just moved this site from being hosted at DreamHost to Amazon Cloud AWS with Chapter Three's Pantheon Mercury. The main reason to do this was performance, but I will discuss the pros and cons of this switch below.

Performance

I have done some very basic benchmarking with AB (Apache Benchmarking). By no means is this a rigorous test, but it does add some insight into the performance increase. I ran ab from a third-party server that had more consistent bandwidth and each test is for the homepage; I am running a small (default) instance. A very rough way to read all this is to say I get 50x the performance with Mercury.