You are qualified if :

• You are developing an application within the Symfony framework
• You make heavy use of your own javascript files because you don’t want to produce that much inline javascript code
• You really need to use dynamic javascript, maybe you want to integrate with the built-in i18n framework
• You’ve never ever heard of dynamic_javacript_include_tag() and use_dynamic_javascript() or weren’t able to make them work

So here is my solution:

The helper function “use_dynamic_javascript” just doesn’t work (or at least I wasn’t able get it to work). Lump it and dump it. We’ll use the other function, which does its job. Here’s how:

As we have to place our dynamic JS within an module you should decide which module you want to use, say we just need i18n in JS so let’s call it “modI18n”. Later we probably include more stuff in this module, so we won’t use the index action. Instead let’s create an empty action called “JsI18n”. You can obviously decide on your own whether you want to use a single file (JsI18nAction.class.php) or the gathering actions.class.php (function executeJsI18n) variant.

Next, create a template called “jsI18nSuccess.js.php”. You already know the rest, don’t you? This is the place where you can mix up Javascript and PHP, great! In my case this file looks like this:

var i18n = {
  'Hello World': '<?php echo __('Hello World')?>'
}
function __(key) {
  return (i18n[key] ? i18n[key] : key );
}

Almost finished, only one point is left: How to actually include this? If you stick with the default routing, there’s nothing easier than that, just type

<?php echo dynamic_javascipt_include_tag('modI18n/JsI18n') ?>

in the head section of your layout or anywhere in your template (the earlier the better) and you’re done. If you use custom routing rules, you may have to add a corresponding route for the action and use this route in the helper. Now you can easily access translated strings within Javascript with the well known __() function. Of course you have to maintain the template, however it seems this is worth the work.

Summing it up this is a bit more convenient than other methods, but nevertheless you’ll end up writing many additional lines of code.

~~~Cheers

• [fix] uninstall method changed
• [fix] another try to avoid doubled entries
• [fix] hide-if-empty was broken
• [add] now the plugin carries some cool ready-to-use layout variants (fully customizable, of course)
• [change] the built-in layouts now feature robust, CSS-driven tooltips
• [add] there is a new special tag for variables %VARIABLE:<name-of-variable>:<value-of-variable>% which is only useful in built-in configurations and needed for things like API keys.
  • upon widget layout selection, this special tag is recognized and a javascript window pops out asking for the value. Up to now, only one variable per configuration is possible.
  • this gets used in the GoogleMaps event layouts to ask you for your domain-specific API-Key, which you can sign-up for here.

It is important that you select a layout (or write you custom one) after changing type or adding a new widget, otherwise the formatting would be uninitialized and the widget will be empty.

I hope I did not introduce new bugs and everybody is satisfied with this release. As of this version I am able to include arbitrarily many example configurations with the plugin, so here is another way to contribute: Submit your custom configuration or demand something specific I really should include in the next release.

Upgraders beware: I don’t think your customized widget configuration will get lost during the upgrade, but for increased safety you should make a backup.

Recently I was asked a support question considering the format of date (and time). As the industrious reader of readme files should know, this is currently handled by the translation files, what means tinkering around with it is not as easy as it should be, I guess. So in fact there are at least 5 affected tags (starttime, endtime, startdate, enddate, date) for which an elegant idea would be highly appreciated.

Last but not least I want to thank #benniy and ongonkov for making helpful bug reports.

• improved wordpress 2.7 compatibility (css, un-installation)
• further clarified options layout: Users reported to be overwhelmed by the number of options, so I split it up in normal and advanced options, utilizing the built-in thickbox script.

So please download the new version via the wordpress plugin repository (or the cool auto-update function) and report bugs in the forums or directly here.

Upgraders pay attention: It’s most likely that your options get reset to default, so I recommend a backup. From version 0.6.1. on this should not happen anymore.

I’m planning to further de-complicate the usage of the plugin by including a few more sample configurations per widget type which might be selected via an additional option. Also I think there is a need for another widget type: “Top Tags” and/or “Related Artists” whose implementation won’t be very complicated.

~~~ Cheers!

Anyhow, I ran into quite a few problems, for some of which I had to edit the source – and in case you’re also facing one or another of these, here are the solutions.

Mass category assignments in the calendar

One of the new features I really like – but which doesn’t work out-of-the-box. It came out that its a small typo bug, in egroupware/addressbook/inc/class.addressbook_ui.inc.php, rewrite line 1976 to:

  } else if (selbox.value == "cat_add") {

I don’t know why this made it in the release version, but as it was the bug which was easiest to fix, I don’t care.

Email notifications

I think you got this one only under following circumstances:

1. You don’t use felamimail, but maybe you’ve tried – in my case it didn’t work because of some missing php-pear stuff.
2. Saving a item (an infolog entry in my case) which should trigger a notification works, but there is an unexpected halt while saving. That means you won’t get a confirmation, the window won’t close and will show an completely empty page.
3. No e-mail is sent ;)

The solution is not so obvious and it took me about 5 hours of echo-debugging of quite some source files. The failure is, EGroupware checks for preferences of felamimail, and if it got them there is no fallback to your smpt configuration in your headers. But unfortunately EGroupware can obtain a preference-object of felamimail, but cannot obtain preferences out of it… That’s weird, uhm? So here is a solution.

Rewrite line 58  of file egroupware/phpgwapi/inc/class.send.inc.php to:

    if (false) {
//  if ($bopreferences) {

This makes the fallback default and is a modification which will still use the fallback with enabled felamimail. Now you should be sure, that your SMTP settings in header.inc.php are correct and it should work. At least in my case it did. In case you get felamimail working don’t forget to undo this modification, since sending mail via one user’s smtp account feels a lot better.

MyDMS enhancement

This is not a bug, but an enhancement I already did to the old installation – so I had to re-enhance the new version (I worry that this won’t be the last feature I have to re-introduce). So MyDMS was used in favor of the file manager because of usability and revision management. Very handy came the possibility to link MyDMS documents from the wiki – but you had to decide for a specific version number. With this tiny enhancement, this is past. Just omit the version number within the download link and you will get the latest version. To get things going expand line 35 of file egroupware/mydms/op/op.Download.php to look like:

if ($version == NULL) {
  $content = $document->getLatestContent();
} else {
  $content = $document->getContentByVersion($version);
}

And that’s it.

I hope you gained some insights, do not hesitate to ask questions but keep in mind that I do not offer general EGroupware support, which Stylite would be happy to be paid for.

~~~ Cheers!