Adventures with Babel 3.0.0-beta1

I am installing Babel 3.0.0-beta1 on a fresh Revolution 2.3.3 built from git as of 11/20/2012.

When creating the contexts to prepare the installation before installing Babel, the permissions automatically given to the Administrator group are a bit odd. They are given "context" policy with an authority of 9999. The web context has the Administrator policy with an authority of 0. I'm not sure if this really makes any significant difference, but it does seem odd.

More notes on this localhost installation to follow.

I have solved another problem I've been having with Babel. I prefer to use a plugin from here https://gist.github.com/gadamiak/3812853 that does not require any web server rewrites. It's all done in the plugin.

I found that I needed to change the plugin code in two places. You may need to modify this to reflect your actual MODX and Babel configurations; in my case 'en' was the default cultureKey, and 'web' was the babel.contextDefault. You can even hard-code the values if you like; it's not likely that the default cultureKey and babel.contextDefault are going to get changed. You could also add some settings to the plugin to use in these locations.

Line 114, change the cultureKey to the web context:


and again, at line 127, change the contextDefault to the web context:


Another thing to watch for is when you create the context settings. If you're in a subdirectory, as I am on my localhost installation, make sure you have the base_url setting to be /subdir/. I've attached a screenshot of my web context settings.

Since this plugin does supply a $languages array with the cultureKey as the key and the context as the value, there should be a better way to set the context when switching the context. I'll have to look into that later.

This is nice! The interface is much nicer than the older versions I worked with! A couple of oddities, though, probably all in the complex Javascript interactions.

At one point, after clicking on a resource in the Tree to connect it to the current resource, the resource links in the Tree remained locked, and I was unable to click on a resource to edit it until I refreshed the page.

On another occasion, on saving a translated resource it complained about a duplicate alias. It only did it once, though.

The BabelLinks snippet has a problem. It makes ugly links like http://localhost/babel/fr/two.html?q=de%2Ftwo.html. Not only is the link ugly, but the q value doesn't change from the current cultureKey. Note that a link to the French two.html is correct in the base URL, but in the query string it still has the current cultureKey.

I modified line 99 to read:


The addition of the query string is probably necessary for sites using web server rewrite rules, but in my case using the non-standard plugin it's not necessary. If I manually edit the q value in the address bar, it does work.

Quote from: sottwell at Nov 29, 2014, 10:55 AM

This is nice! The interface is much nicer than the older versions I worked with! A couple of oddities, though, probably all in the complex Javascript interactions.

At one point, after clicking on a resource in the Tree to connect it to the current resource, the resource links in the Tree remained locked, and I was unable to click on a resource to edit it until I refreshed the page.

On another occasion, on saving a translated resource it complained about a duplicate alias. It only did it once, though.

It's been fixed for the next update.
https://github.com/mikrobi/babel/issues/95

Quote from: sottwell at Nov 29, 2014, 10:49 AM

I am installing Babel 3.0.0-beta1 on a fresh Revolution 2.3.3 built from git as of 11/20/2012.

When creating the contexts to prepare the installation before installing Babel, the permissions automatically given to the Administrator group are a bit odd. They are given "context" policy with an authority of 9999. The web context has the Administrator policy with an authority of 0. I'm not sure if this really makes any significant difference, but it does seem odd.

I'm not sure what Babel is doing with this, but I've done it when I wanted to use a security check in the front end to require that the logged-in front-end user be a member of the Administrator group, but not give them any extra permissions to that user. It makes a front-end script very secure to just bail if the user isn't a member of the Administrator group and makes sure that very few people can run it.

That really has nothing to do with Babel, BobRay. It's done when creating the contexts. I'm sorry if I gave the impression that I thought it had something to do with Babel.

Ah, sorry I misunderstood -- we are in the "Adventures with Babel topic.

I see what you mean about the default context ACL entries in the Manager when creating any context. I think without that entry, you wouldn't be able to see the new context and/or its resources in the tree. Maybe the 9999 is to prevent you from accidentally giving users more permissions than you want in that context. It does look kind of odd, though, and I think it may affect your ability to forward across contexts, depending on what's in the template - I could be wrong.

Just lack of clear communication. I thought this made it clear that it was the context creation, Babel hadn't been installed yet. I'm following the step-by-step instructions on the Babel documentation page, so the contexts get created first of all.

When creating the contexts to prepare the installation before installing Babel,...