Hello and happy new year 2014!
On some deployment environments, when editing a node with the asset side widget enabled in it, the widget's Search form "Search" button as well as pagination links do not work and redirect to the site's home page with GET parameters added to the URL or a full-page JSON string (respectively).
- The side widgets shows up correctly and the [<] arrow button allows it to pop open.
-
On working environments (eg. local machine):
-
the following JS scripts get requested in XHR on page load :
- http://example.com/ajax/asset-widget/get/tab
- http://example.com/ckeditor/xss
- http://example.com/sites/default/files/js/js_Pi2H3bIs2PEJyHeamc2-HYK-Y1m... (which is a generated version of Views' module js/base.js)
- Drupal.views.instances JS variable exists and its constructor attribute is the asset widget's view css path
-
the following JS scripts get requested in XHR on page load :
-
On failing environments (our staging & production servers...) :
- all the above XHR JS files except the generated js_*.js file get requested on page load
- The Drupal.views.instances JS variable does not exist
- File http://example.com/sites/default/files/js/js_some_hash.js does get generated server-side in sites/default/files on page load, but the web browser does not XHR-request it :-/
Note that on both working and failing deployment environments, PHP 5.3 is used, and the website URL is subdomain.domain/ without any base path directory.
Since the Asset widget's form is a views exposed filter, looking at the related Views by clicking at the steer icon, shows that that views's AJAX is enabled (on both environments). Though on some environments the view's ajax (when clicking) does not work at all as stated above.
I've also noted that the Asset widget's view HTML exists with the same css path on both failing and working environments ( html.js body.html div#page div#main-content.limiter div#content.page-content div.region div.assets-module div.assets-module-inner div.assets-content div.tab-contents div.tab-contents-bottom div.mid div.tab form#views-exposed-form-asset-widget-search-default.asset-widget-search-exposed-form ). This path is property jQuery'd by the Drupal.views.instances's selector on working environments.
Would you have any hint how to troubleshoot or solve our issue ?
Thanks in advance !
Comment | File | Size | Author |
---|---|---|---|
#3 | Create article widget.png | 67.07 KB | Nishruu |
Comments
Comment #1
myselfhimself CreditAttribution: myselfhimself commentedComment #2
Nishruu CreditAttribution: Nishruu commentedHello,
I have the same problem with my widget for a specific node type edit page, using the last dev version.
For the node type "article", the widget is partially broken :
I can created new assets, but i can't use the search tab. When I click "search", the page is redirected to something like /?title=&type[]=image&uid=&created=.
Moreover, the appearance of the widget seems broken. We noticed two links not appearing on normal widgets : "edit view" and "configure layout" (i'm connected as admin). The pager is broken too. Screenshot attached.
Adding two js via hook_init repair the search link but not the widget's look :
- drupal_add_js(drupal_get_path('module', 'views') . '/js/base.js');
- drupal_add_js(drupal_get_path('module', 'views') . '/js/ajax_view.js');
All other node types are ok.
Comment #3
Nishruu CreditAttribution: Nishruu commentedScreenshot attached.
Comment #4
bonbonjoy CreditAttribution: bonbonjoy commentedI too have seemingly the same problem with Asset 7.x-1.0-beta4+26-dev on my development site (dev.mysite.com)
*The widget's Search form "Search" button (searching Asset type = Document) redirects me to my site's home page: http://dev.mysite.com/?title=&type%5B%5D=document&uid=&created=
* The 2 buttons for display type modes (pagination links), supposedly above the Assets listing, are missing (do I need to configure something?)
* The thumbnail images in the Assets listing are missing (again I wondered if I didn't configure something properly)
I still can use this module, but hoping for a solution, or at least hope for one in the future.
Anyone have more to say on this?
Comment #5
phillamb168 CreditAttribution: phillamb168 as a volunteer commentedI'm also experiencing the same issue, on local, dev and production.