Posted 27 December 2010 in Dynamic Widgets

Dynamic Widgets 1.3.7

Finally, a bit later than expected a new version of Dynamic Widgets is there. One of the reasons for the delay is a bug found by Mike from The Minor Site which took some time to get it fixed. It turned out when the bug was already fixed the Suffusion theme he is using, acted funny by passing unrealistic data to Dynamic Widgets which in its turn got confused. Luckily we got around it by switching the plugin to ‘OLD’ method.

Anyway, I’ve just released version 1.3.7. Compared to the previous version, the following has been added and fixed:

  • Added more l10n text strings.
  • Added French language files (locale: fr_FR) – Merci beaucoup Alexis!
  • Added language (WPML) as an option.
  • Added hierarchical inheritance support for Pages and Custom Post Types
  • Bugfix for unexpected behavior when two widgets are in opposite config of eachother.
  • Fixed a couple of l10n text strings
  • Changed UI in edit options screen (Thanks Alexis for the help!).
  • Speeded up the removing process in FILTER method.

45 Comments to “Dynamic Widgets 1.3.7”

  • Gila (11m2)
    28 December 2010 at 03:26

    Okay, I ran into a small bug or difficulty. Most of my sidebar is done in Advanced Text plugin, i.e. with image maps. I never give those Advanced Text blocks a title, since I don’t want anything displayed above.

    With Dynamic Widgets, that means that only the first Advanced Text works correctly, while the others will display regardless of language. Adding a slug name didn’t help either.

    I now adjusted the style.css to have the title display in the same color as my background. That way, the block get’s a title, and Dynamic WIdgets works. But I would have preferred keeping my usual system.

    Nevertheless, your plugin was a life-saver when I switched to WMPL. 🙂 Thanks!

    Gila

  • Gila (11m2)
    28 December 2010 at 03:33

    Awwww…. I was too haste. Still same problem. Example: http://11m2.knastschwester.com/?cat=61 Button at the bottom (Anleitung zum Kauf in England) should only display on German blog pages. If you have a solution, please let me know?

  • Gila (11m2)
    28 December 2010 at 03:42

    Know the problem – not every link in nav etc automatically includes the lang variable. Will need to fiddle with that tomorrow.

    • Jacco
      28 December 2010 at 08:20

      Hi Gila,
      So… please correct me if I’m wrong. There is only an issue with the Advanced Text plugin in combination with Dynamic Widgets when there are more than one widgets of Advanced Text?

  • Gila (11m2)
    28 December 2010 at 09:03

    Well…. I am trying to do an extensive test. Whenever I add an AT block, anything that is below that block does not react to language settings anymore. When I move the AT block to the bottom of the sidebar, blocks above work fine again. Unfortunately, that is no solution, since I need more than one AT block.

    So something in the AT block confuses Dynamic Widgets…. In case it matters, this is the code of that block that is displayed in page source:

    EN nav

  • Gila (11m2)
    28 December 2010 at 09:05

    (sorry, had to delete all mark up)

    ul id=”sidelist”>
    li id=”advanced_text-10″ class=”widget advanced_text”> div class=’AdvancedText’> h2 class=”widgettitle”>EN nav /h2>
    img src=”http://11m2.knastschwester.com/wp-content/uploads/2010/12/navi_rechts_en.jpg” width=”220″ height=”390″ border=”0″ usemap=”#Mapen”>
    map name=”Mapen”>
    area shape=”rect” coords=”69,24,217,69″ href=”http://11m2.knastschwester.com/?lang=en” target=”_parent”>
    area shape=”rect” coords=”70,69,217,112″ href=”http://11m2.knastschwester.com/?page_id=521〈=en” target=”_parent”>
    area shape=”rect” coords=”70,112,217,158″ href=”http://11m2.knastschwester.com/?page_id=133〈=en” target=”_parent”>
    area shape=”rect” coords=”70,158,217,202″ href=”http://11m2.knastschwester.com/?page_id=282〈=en”>
    area shape=”rect” coords=”69,245,214,286″ href=”http://11m2.knastschwester.com/?page_id=545〈=en” target=”_parent”>

    /map>
    /div> /li>

  • Gila (11m2)
    28 December 2010 at 10:13

    Same thing happens when I use regular Text widget, by the way. Hm…. I must find a solition somehow.

    • Jacco
      28 December 2010 at 12:29

      Hi Gila,
      I’ve found the problem. The plugin hits into the just introduced failsave because it got confused with subsequent widgets in opposite config for WPML. Just checked in the bugfix in the development version r326639.

  • Gila (11m2)
    28 December 2010 at 12:34

    Okay, you lost me at “failsave”. 🙂 Is there anything I can do right now to fix the problem? I am a decent enough webdesigner and able to adjust code… but not much of a PHP person.

    • Jacco
      28 December 2010 at 13:09

      Don’t bother the ‘failsave’. 😉 You can download the development version which has a fix in it for your WPML issue. Replace the current version you have now with the development version and you should be good to go. Does that makes more sense?

  • Gila (11m2)
    28 December 2010 at 17:21

    Unfortunately, it doesn’t work. Downloaded the zip, uploaded all new files to the plugin folder. Whichever widget is above (i.e. nav_de), that’s the language where two sidebars are diplayed. If I switch the order, the language error changes as well.

    I sooo want to get this to work…. would hate to hard-code this. Here’s the stripped output:

    !– sidebar wrap –>

    ul id=”sidelist”>

    li id=”text-11″ class=”widget widget_text”>h2 class=”widgettitle”>navi EN/h2>
    div class=”textwidget”>img src=”http://11m2.knastschwester.com/wp-content/uploads/2010/12/navi_rechts_en.jpg” width=”220″ height=”390″ border=”0″ usemap=”#Mapen”>
    map name=”Mapen”>
    area shape=”rect” coords=”69,24,217,69″ href=”http://11m2.knastschwester.com/?lang=en” target=”_parent”>

    area shape=”rect” coords=”70,69,217,112″ href=”http://11m2.knastschwester.com/?page_id=521〈=en” target=”_parent”>
    area shape=”rect” coords=”70,112,217,158″ href=”http://11m2.knastschwester.com/?page_id=133&lang=en” target=”_parent”>
    area shape=”rect” coords=”70,158,217,202″ href=”http://11m2.knastschwester.com/?page_id=282&lang=en”>
    area shape=”rect” coords=”69,245,214,286″ href=”http://11m2.knastschwester.com/?page_id=545&lang=en” target=”_parent”>
    /map>
    /div>
    /li>
    li id=”text-12″ class=”widget widget_text”>h2 class=”widgettitle”>navi DE/h2>
    div class=”textwidget”>img src=”http://11m2.knastschwester.com/wp-content/uploads/2010/12/navi_rechts_de.jpg” width=”220″ height=”390″ border=”0″ usemap=”#Mapde”>

    map name=”Mapde”>
    area shape=”rect” coords=”69,24,217,69″ href=”http://11m2.knastschwester.com/?lang=de” target=”_parent”>
    area shape=”rect” coords=”70,69,217,112″ href=”http://11m2.knastschwester.com/?page_id=533〈=de” target=”_parent”>
    area shape=”rect” coords=”70,112,217,158″ href=”http://11m2.knastschwester.com/?page_id=580〈=de” target=”_parent”>
    area shape=”rect” coords=”70,158,217,202″ href=”http://11m2.knastschwester.com/?cat=65〈=de” target=”_parent”>
    area shape=”rect” coords=”69,245,214,286″ href=”http://11m2.knastschwester.com/?page_id=131〈=de” target=”_parent”>
    /map>
    /div>
    /li>
    /div>!– /sidebar –>

  • Gila (11m2)
    28 December 2010 at 17:23

    Unfortunately, doesn’t work. Whichever widget is on top, that’s the language where the error occurs. (tried posting this twice, but doesn’t seem to appear.) Wondering if the bug is in Dynamic Widgets, WPML or the text widget?

    • Jacco
      28 December 2010 at 17:44

      Your previous comments were in the spam folder. I’ve approved one. I’ve looked at your site. Am I correct it seems to work correctly in the English version, but not in the German version? Is this using Advanced Text or just Text widget?

  • Gila (11m2)
    28 December 2010 at 17:51

    Thank you for your patience! 🙂 It is currently correct in the English version, and incorrect in German. That’s because the Advanced Text widget for German navigation is called up first, placed above the English block. If I switch position, whichever block is called first works, the second doesn’t. Also tried this with Text widget (instead of Advanced), same result.

    I am happy to have you look in the backend, btw – the site isn’t live yet. You seem to have the only language-dynamic sidebar widget out there, so having this work with WPML would be great… me thinks. 🙂

    • Jacco
      28 December 2010 at 18:04

      No thanks at all. I promise WPML support in the plugin, so you should get WPML support.
      I’d almost say wordpress.org has delivered you a wrong package. I’m going to email you the changed file with some instructions. See if that helps.

  • Tweets die vermelden Dynamic Widgets 1.3.7 | Qurl -- Topsy.com
    29 December 2010 at 19:52

    […] Dit blogartikel was vermeld op Twitter door Gila (11m2.de), Jacco. Jacco heeft gezegd: Just released: Dynamic Widgets 1.3.7 https://qurl.nl/2010/12/dynamic-widgets-1-3-7/ […]

  • Eduardo Larequi
    2 January 2011 at 18:43

    Thanks, Jacco, for this excellent plugin. While making a spanish translation, I’ve found some text strings which are not prepared to be translated by means of .po/.mo files:

    – dynamic-widgets.php, línes 567, 568.
    – dynwid_admin_edit.php, lines 153, 198, 201, 203, 505, 519, 668, 797, 814.
    – dynwid_admin_overview.php, lines 88, 90, 95, 99, 103, 114, 119, 124, 130, 135.

    In dynwid_admin_edit.php, line 401, there is another problem. The order of PHP elements doesn’t allow a correct translation in spanish. In english, you have “Edit options for xxx widget”. When translating this to spanish, we get “Editar opciones para el xxx widget”, which is not correct (it should be “Editar opciones para el widget xxx”). I’ve solved the problem by removing the code related to word “widget”, but this is not the best solution.

    I’ve made some changes in these files in order to translate the missing strings. How can I send you the .PO file, once finished?

    Anyway, thank you very much for this plugin.

    • Jacco
      2 January 2011 at 20:38

      Hi Eduardo,
      Wonderfull you are working on a Spanish translation! 🙂 I’m going to have a look to the mentioned lines and will include these into the POT file. I’ll send you the updated POT file, so you have immediately my email address to send the PO/MO files to.

  • Gila (11m2)
    2 January 2011 at 20:40

    If you need a German translation, you know where to find me? 🙂

    • Jacco
      2 January 2011 at 21:10

      Thanks Gila! 🙂 Actually someone else made a German translation a few days ago. It will be included in the next release.

  • Sosa
    26 January 2011 at 18:39

    Thanks for the great plugin, Jacco! I’m using WP E-Commerce 3.8 and dynamic widgets (1-3-7, 1-3-7-7) to restrict the Product Categories widget to the Products page and Product Category pages (/store/category) everything seems to be working fine except, with default set to yes, for WPSC Categories, the Product Categories widget is not visible on any of the Product Category pages. Is there a possible workaround that you are aware of or do you have any suggestions? Thank you for your time!

    • Jacco
      26 January 2011 at 21:16

      Right…. WPEC 3.8 is beta. And it looks like they changed a lot! Dynamic Widgets is not detecting the WPEC pages anymore. I have to fiddle around to see what exactly have been changed and how to detect it.

    • Jacco
      29 January 2011 at 15:46

      Hi Sosa,
      I’ve just uploaded development version 1.3.7.8 which has support for WPEC upgraded to 3.8. See also the blogpost about it.

      • Sosa
        30 January 2011 at 02:06

        Thank you, Jacco!
        Dynamic Widgets 1.3.7.8 works great with WPEC 3.8 beta-dev. Thank you for the quick reply, updated plugin and the extra time and thought for the generator that makes recreating the rules, after upgrading WPEC, so much easier!

  • meini
    28 January 2011 at 06:24

    Hi,

    all of a sudden I experience an issue on one of my sites in that the collapse/expand feature on the “Edit options for…” page freezes up as soon as I click on one of the headings trying to expand it. It works fine on another one of my sites though. I tried to disable a number of plugins but since the site is online, there is only so much I can do.

    Any ideas/hack? The old version without the collapsing feature worked well for me.

    Cheers

    • Jacco
      28 January 2011 at 06:51

      I’ve seen this before when the default BuddyPress theme is used. It bombs the script taking care of the fold out. Took a while to figure out how to get around that. Are you using that theme? Or did you do something with the theme you are using?

      • meini
        28 January 2011 at 07:27

        Thanks for your quick reply Jacco,
        yes I use the BP default theme but I customized it with a child theme. As an interim workaround I went back to 1.3.6 for now.

        Can I disable the script somewhere? Or do you have another suggestion? Are you planning on tackling this in the next release?

        Also, please let me know if I can assist you with testing or anything.

        Cheers
        Meini

        • Jacco
          28 January 2011 at 08:18

          It will be fixed in the next development version. Hopefully I will be able to check it in this weekend. In the meantime, when you’re familiar with PHP, you can add the following lines to dynamic-widgets.php within the dynwid_add_admin_scripts() function, before the wp_enqueue_script() functions are called.

          // Workaround fixing a js error with ui.accordion
          if ( get_current_theme() == 'BuddyPress Default' ) {
          wp_deregister_script('dtheme-ajax-js');
          }

          • meini
            28 January 2011 at 12:39

            Works well, thanks heaps. I left the condition out because I use a BuddyPress Child Theme so it would not resolve to true. Good enough for me as there is no way I will change the theme before you bring out the update 🙂

            Love your work!

          • Jacco
            28 January 2011 at 13:09

            You’re right! The condition won’t work when a child theme is used. Better use:
            if ( wp_script_is('dtheme-ajax-js') ) {
            wp_deregister_script('dtheme-ajax-js');
            }

  • meini
    28 January 2011 at 13:19

    Works – brilliant !!!
    Thanks again

    • Luigi
      31 January 2011 at 16:35

      I have the same problem. I use BuddyPress with a Advanced Newspaper Theme by Gabfire.
      I have open the “dynamic-widgets.php” and I have read this part of code

      /**
      * dynwid_add_admin_scripts() Enqueue jQuery UI scripts to admin page
      * @since 1.3
      */
      function dynwid_add_admin_scripts() {
      $DW = &$GLOBALS[‘DW’];

      // Workaround fixing a js error with ui.accordion
      if ( wp_script_is(‘dtheme-ajax-js’) ) {
      wp_deregister_script(‘dtheme-ajax-js’);
      }

      wp_enqueue_script(‘jquery’);
      wp_enqueue_script(‘jquery-ui-core’);
      if ( version_compare($GLOBALS[‘wp_version’], ‘3.1’, ‘>=’) ) {
      wp_enqueue_script(‘jquery-ui-widget’);
      wp_enqueue_script(‘jquery-ui-accordion’, $DW->plugin_url . ‘ui.accordion.1.8.7.js’, array(‘jquery-ui-widget’));
      wp_enqueue_script(‘jquery-ui-datepicker’, $DW->plugin_url . ‘ui.datepicker.1.8.7.js’, array(‘jquery-ui-widget’));
      } else {
      wp_enqueue_script(‘jquery-ui-accordion’, $DW->plugin_url . ‘ui.accordion.1.7.3.js’, array(‘jquery-ui-core’));
      wp_enqueue_script(‘jquery-ui-datepicker’, $DW->plugin_url . ‘ui.datepicker.1.7.3.js’, array(‘jquery-ui-core’));

      }
      }

      Can you help me where I must modify ?
      I ‘m a not exspert about PHP.
      Thanks a lot

      • Jacco
        31 January 2011 at 18:38

        The workaround is already in there. Do you mean you (still) have the freezing problem?

        • Luigi
          31 January 2011 at 19:11

          Sorry, but I do not understand exactly what I enter.
          You can write a chunk of code that I enter?
          Thanks

          • Jacco
            31 January 2011 at 19:46

            This is the part of code which takes care of the workaround for the BuddyPress default theme:

            // Workaround fixing a js error with ui.accordion
if ( wp_script_is(‘dtheme-ajax-js’) ) {
  wp_deregister_script(‘dtheme-ajax-js’);
}

            If this does not fix your problem and you still have freezes when opening the accordion, then something else is bombing it. It might be your theme, it can be something else.

  • Luigi
    1 February 2011 at 10:14

    Ok ….. I check and I hope to find the solution or disable the our plugin.

  • Luigi
    1 February 2011 at 19:43

    …. I found the problem. 🙂
    Your plugin conflicts with the plugin BuddyPress Theme Compatibility is enabled when ‘Template Pack BP JS / AJAX’ and does not allow expansion of the windows of your plugin for the changes, however, without affecting the setup choices previously made.
    Therefore I was forced to disable this function, making the necessary changes to some dynamic widget and reactivate the function of BP Theme Compatibility.
    I hope that this report will be helpful for your work !

    • Jacco
      1 February 2011 at 19:55

      OK, cool. 🙂 Thanks for letting me know. In my opinion, a plugin should not put JavaScript needed on the front-end also include in the back-end. Or when needed in the back-end only include on their own pages. Actually a very common mistake made by plugin authors. Anyway, I’m going to look into it to see if I can find a workaround for this bad behavior. 😉

    • Jacco
      1 February 2011 at 20:13

      Found the bombing script: bp-js
      In your case you could change the dtheme-ajax-js to bp-js and you should good to go. The full code is now:

      // Workaround fixing a js error with ui.accordion
if ( wp_script_is('dtheme-ajax-js') ) {
  wp_deregister_script('dtheme-ajax-js');
}
if ( wp_script_is('bp-js') ) {
  wp_deregister_script('bp-js');
}
      • Luigi
        2 February 2011 at 10:04

        Thanks. Work ok !

  • Luigi
    14 February 2011 at 14:59

    Hello Jacco,
    I discovered that the plugin has a problem.
    The defect concerns the dynamic function that is not activated in your pages while it is OK for the categories.
    I installed the new version of Developer and the problem persists.
    I even did the reset all dynamic widgets that I had previously created but the problem of visibility of the widget is dynamic pages!
    What does it depend?

    • Jacco
      14 February 2011 at 18:35

      Hi Luigi, I’m not sure if I understand exactly what the problem is. You mean there is a bug in static pages? Can you please describe what you are doing? Do you have a link for me where the problem occurs?

      • Luigi
        15 February 2011 at 12:49

        Yes, the problem inquiries concerning static pages.
        When I choose the pages on which the plugin must show the widget This choice has no effect.

        • Jacco
          15 February 2011 at 18:50

          Hmm… I’m unable to reproduce the problem. Can you please send me a dump, let me know which theme you use and if possible send me a link to a page where it goes wrong. The page ID of that page would also be very usefull.

          • Luigi
            22 February 2011 at 12:02

            Hi Jacco,
            I send you a email with “dump” file and url page.
            Thanks a lot.