When i submit my form that is being displayed in an overlay, the resultant page is unthemed. If i submit the same form from a regular page view the page is themed as expected. Not sure how to debug this?
Using XDV, Plone 4.2
First off, have you tried to port to plone.app.theming? It should be relatively straightforward (there's a guide in the p.a.theming docs), and p.a.theming ships with Plone 4.2 and is even better in 4.3. I don't think there's a straight-up incompatibility, but there could be. XDV is no longer maintained (as in, it was renamed plone.app.theming and development continues there), so porting is probably going to be necessary sooner or later.
The only other thing I can think of is whether there is some sort of condition or list of unthemed paths kicking in, e.g. may it be looking for a request parameter like ajax_load or the tail end of a path and disabling the theme?
Finally, check whether there are any errors in the console output/logs: XDV doesn't throw a site error, but will log if there's a problem.
Related
I am building site in Drupal and I need your help. I have an assignment to make one more language translation of the site, and so far so good. However, I have one trouble with one block which isn't going to get translated, even though in the settings I translated it.
Also one strange activity I noticed is that when I try to go to VIEW section of all the other languages, I get dropped to front page (where that block is actually located) but if I press VIEW from my language translation (Swedish) of the block I get to completely new page.
If I go to front page and my language is selected, that block is actually using default language.
Any help what may cause it?
For desire url aliasing you need to install pathauto drupal module. then you can configure alise from below url
admin/config/search/path/patterns
OK, I have found a solution to this problem.
It appears that Drupal 7 by default sets your new language homepage to the default homepage and that's why this block was using default language since it was relying on the front page. Anyway, to fix the issue follow the steps:
Login to adming account, go to Configuration, System, Site Information and in the field Default front page for the language you have chosen navigate to your specific node page. That's it.
I have some Computed Fields and in these fields, I get some HTML codes with simple_html_dom.php class from some sites. Codes works perfectly on pages, but when I try to get these fields to use in a View, Drupal gives the following error.
http://i.stack.imgur.com/W2Rhc.jpg
Anybody can help?
Even if it is not the best solution, after installing Views PHP module of Drupal, problem is slightly solved. I still get the error message on every time I try to change something, also I am having difficulties on making a change on the view, like saving and adding the same thing 5 times and got successfull, still it is a solution.
This message usually appears when you try to save the form before the ajax process has finished.
Try checking the 'network' tab on developer tools installed within Google Chrome or by using a tool similar to firebug. This will show you the request being made via ajax and should give you more information to debug.
I recently took over a site from someone else at a new company. Having never used Drupal before, updating things has been a bit cumbersome. There were some outstanding security updates that I applied(but I haven't updated the core yet). Anyway, after doing this, the calls to views_embeded_view have not been working. For example:
print views_embed_view('news_block');
Will break the links(by using the title, rather than alias for the link), or it will link correctly, but not follow the paging rules I have set(show 1 page, 6 items per page) instead it shows 10 items and has links for other pages.
I am not sure if the update has anything to do with it, but it seems likely. Would updating the core resolve this issue potentially?
The first argument of views_embed_view is view name, the second one is display id. If display_id is not provided, 'default' is used. Make sure that you are displaying the correct display. (i.e. default can be configured differently than some other display which you actually wish to see)
(Sorry this is rather a vague question. My attempts to be clearer [and indeed to be more code-oriented] have failed...) :-/
//
I've installed the Firebug for Drupal module, and I notice that it shows I'm apparently loading the same eight node objects on every page for no apparent reason. These are all of the same content type (the site uses many other content types).
It seems they are actually all the nodes of this one content type, excepting those produced as dummy content by the developer module.
I've flushed the cache multiple times.
Is there a way to work out where these nodes are being loaded from???
Install devel.module, add ddebug_backtrace(); inside the node_load() function. Reload the site. Now you should see 8 browsable backtraces which will tell you which function calls node_load().
At a guess, you probably have a block (from a view or module) which is querying those nodes on every request.
http://heydon.com.au/node/1044 has a short writeup on this behaviour. If so, the fix is to remove that block from the regions which are rendered, or configure it to only be displayed (and therefore rendered) on pages where you want it to be run.
Drupal caching should prevent those queries being run for anonymous users (depending on the caching and block settings, of course).
I've had this happen with 3rd party modules that were repeatedly calling node_load() needlessly. What I would suggest is for you to disable all 3rd party modules, retry you node loads and re-enable them one by one until you catch the misbehaving module.
Good-luck!
The task is relatively straightforward:
A Drupal website displays a list of articles with thumbnails. Some visitors would like to view it without images by clicking on a button/link and have that preference saved.
e.g. http://patterntap.com/collections/index/
The problem is all visitors are anonymous and given certain traffic, page cache is enabled.
My idea was to use some simple JavaScript to set a cookie, refresh the page and depending on the cookie values (or its presence/absence) display or hide the images.
Except Drupal serves cached pages quite early and the only quick way to modify the cached version that I could find is by hacking includes/bootstrap.inc and add a custom class to the body classes then hide the images with css.
A very wrong approach, I know. But I wonder if there is a way to save different versions of a page and serve the correct version?
Edit:
need to keep the same uri
the js to show/hide the images without reload and set the cookie is already in place
hook_boot() is not really called for cached pages, so can't do it via custom module
.htaccess mods?
Edit/solution:
In the end went with Rimian's suggestion. But it is possible to accomplish the task using our own cache.inc implementation as seen in the Mobile Tools module. Specifically, by extending cache.inc and updating settings.php to include
$conf['page_cache_fastpath'] = FALSE;
$conf['cache_inc'] = 'path/to/my/module/my_module_cache.inc';
So let me get this right. You wanna hide some images on a cached page if the user chooses to?
Why don't you write some jQuery or javascript and load that into your cached page with all the rest of the document?
Then, the client/browser would decide to run your script and hide images depending on some parameters you passed along with the request to that page or in the cookie? The script gets cached and only runs when you call it.
If you were hacking the bootstrap for something like that you'd really need to be rethinking what you were doing. Crazy! :)
Also take a look at cache_get and cache_set:
http://api.drupal.org/api/drupal/includes--cache.inc/6
I'm not sure I 100% understand what you are trying to do but here are my thoughts. One of your root problems is that you are trying to access what is essentially different content at the same uri.
If this is truly what you want to do, then Rimian's suggestion of checking out chache_get and chache_set may be worthwhile.
Personally, it seems cleaner to me to have your "with thumbnails" and "without thumbnails" be accessed via different uri's. Depending on exactly what you are wanting to accomplish, a GET variable my be an even better way to go. With either of these two options you would hide or show your thumbnails at the theme layer. Pages with different paths or get variables would get cached separately.
If you want the visitor to be able to switch views without a page reload, then jQuery and a cookie would probably suite your needs. This wouldn't require a page reload and switching back and forth would be quite simple.