i couldn't get the variable styling replacement working in D7 following the guide at http://drupal.org/node/754480

it had already worked in D6. in D7 ${my_field} won't get replaced for the externalGraphic setting within my style.

also note that #1098760: Attributes and Styling variable list is empty might be related but didn't solve my problem either

#16 openlayers_1127498_15.patch1.04 KBbleedev
Members fund testing for the Drupal project. Drupal Association Learn more


dasjo’s picture

from http://drupal.org/node/1000012#comment-4053594 i learn that

Styles are different than Style Plugins. Styles are just sets of configurations, while plugins are functional objects that actually process the styles on the fly.

for d6 this seems to apply and there is an example in openlayers_test. for d7 i couldn't find any info about Style Plugins so far

dasjo’s picture

i'm currently investigating into using OpenLayer's internal styling feature

any help would be very much appreciated

dasjo’s picture

finally came up with a workaround to dynamically styling openlayers in drupal 7 using openlayers rules:

add custom javascript for specific openlayers view

function yourmodule_preprocess_views_view($variables) {
  if($variables['name'] == 'yourview') {
    drupal_add_js(drupal_get_path('module', 'yourmodule') . '/js/yourmodule_openlayers_styling.js', 'file');

in yourmodule_openlayers_styling.js add the dynamics

Drupal.openlayers.getStyleMapOld = Drupal.openlayers.getStyleMap;
Drupal.openlayers.getStyleMap = function(map, layername) {
	var styleMap = Drupal.openlayers.getStyleMapOld(map, layername);
	// Add custom styling rules. Example taken from http://docs.openlayers.org/library/feature_styling.html
	var lookup = {
		"small": {pointRadius: 10},
		"large": {pointRadius: 30}
	styleMap.addUniqueValueRules("default", "size", lookup);
	return styleMap;

i'm not a javascript expert, so there might be more elegant way to override Drupal.openlayers.getStyleMap

valderama’s picture


dgastudio’s picture


seanberto’s picture


seanberto’s picture

I'm encountering this as well with the most recent dev release. I've got a view that provides a data layer. I'd like to use the content type's machine readable name as a variable in the externalGraphic file path. However, when the map renders, it looks like it's not picking up the variable correctly.

The following externalGraphic file path:


renders on the map as:

<image id="OpenLayers.Geometry.Point_47" cx="676.3802493639903" cy="531.0048292783788" r="1" x="670" y="525" width="12" height="12" href="http://local.creekfreaks/sites/all/modules/custom/MYMODULE/icons/%24%7Btype_rendered%7D.png" style="opacity: 1" fill="#EE9900" fill-opacity="1" stroke="#EE9900" stroke-opacity="1" stroke-width="1" stroke-linecap="round" stroke-linejoin="round" stroke-dasharray="none"></image>
seanberto’s picture

Found the bug. Working on a patch.

@ line 108 im openlayers.render.inc we're turning relative URLs into absolute URLs for externalGraphics. This strips the ${} from variable names.

seanberto’s picture

Found the bug.

@ line 108 im openlayers.render.inc we're turning relative URLs into full path URLs for externalGraphics. This strips the ${} from variable names. Looks like this is b/c of the url() call. Not sure best fix.

zzolo’s picture

Title: Variable Styling not possible in D7? » Variable styling syntax being urlencoded for externalGraphics links
Category: support » bug

Hi @seanberto. Good catch. So, it seems like this is just with the externalGraphic field.

I am not sure if there is an easy way to do this. The url() function doesn't have a way to turn off encoding. What can be done though, is, since we know what characters are being encoded, we can find-replace after the run through url(). A hack for sure.

dafeder’s picture

I would suggest just getting rid of the url function on that line. It's easy enough to manually set the path, but this makes it impossible to have variable marker images. We gain much more than we lose.

dafeder’s picture

Well, hadn't thought about the security implications. So a find-replace function would probably be the way to go. Will try to make a patch.

dafeder’s picture

The logic here is confusing... URL won't make the changes you'd expect because it can't see what's in the variable. If I have a full path in ${variable}, it will get wrapped again in a drupal absolute path if I pass it through URL, even if it's de-encoded. Not sure how to proceed.

Jordanmt’s picture

I removed the piece of code that transforms relative paths thinking my variable would then go through -- but it returns "undefined" instead of the variable's value (which I can see in my views data layer).


Is this a separate issue?

zzolo’s picture

Status: Active » Fixed

This should be addressed now. I did a simple replacement. It is by no means perfect, but should work.


bleedev’s picture

Status: Fixed » Needs review
1.04 KB

Hi all, new engineer from ThinkShout submitting my first D.O. patch. I suggest the following patch to check if a variable is being passed from externalGraphic field.

seanberto’s picture

Separate note - if this patch gets in, perhaps we should change the help text below the field to reference the fact that replacement patterns are accepted.

zzolo’s picture

Status: Needs review » Postponed (maintainer needs more info)

Hey @bleedev. Thanks for the patch. Maybe I am just missing something, but I am not sure I see the benefit of this extra check. Can you expand a bit?

bleedev’s picture

The extra check is to allow the externalGraphic field to use ${attribute} syntax.

zzolo’s picture

Status: Postponed (maintainer needs more info) » Fixed

@bleedev . Maybe I am missing something but I think your logic is bad. You are creating a conditional that says:

If not absolute or full URL (ie Drupal path), AND has attribute replacement, then style the URL.

This is not good because we want to style the URL is it is a Drupal path, and then we add a little logic so that attribute replacements are not blown away.

This should be working fine now. Please re-open if I am missing something.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.