I have two content types (in a Drupal 7.20 environment) which embed views or blocks. When I allow those content types in search results, the results page goes sideways whenever those content types are represented in the result set: the pager shows a different number of total pages from one results page to the next, or disappears entirely after I hit Next (!), fewer than 10 results show per page (yet there's a pager...), etc., etc.
If I disallow those content types (via Custom Search), I don't see any problems with pagination, etc.
What I have noticed is that the actual views/blocks get executed when the search results page is constructed - it's not merely a matter of hits being found in the search_index table.
Anybody know how to address this problem?
(I've searched through stackoverflow, and issues for Search and Custom Search on Drupal.org - no joy.)
Thanks in advance,
Lee
[Edit: fixed a couple of typos...]
[3/17/13 Edit: The problem turns out to be due to the pager for the view or block that is included in the search result set. If the view is in the result set, but doesn't have a pager, there is no problem. My solution, therefore, is to detect that I'm on a search results page in hook_views_query_alter() (by looking at the request URI) and set
$view->items_per_page = 0;
which effectively gets rid of the view's pager.
[I didn't realize I could answer my question - not sure how that's different from editing the question to include the answer, but I'll put my answer here as well, anyway.]
The problem turns out to be due to the pager for the view or block that is included in the search result set. If the view is in the result set, but doesn't have a pager, there is no problem. My solution, therefore, is to detect that I'm on a search results page in hook_views_query_alter() (by looking at the request URI) and set
$view->items_per_page = 0;
which effectively gets rid of the view's pager.
Related
I am trying to modify an existing XML package of Aspdotnetstorefront Multistore. It's an internal XML package to show the variants of a certain product. What I did to start with was to copy-paste the whole code as is and throw it into a new custom XML package. The problem is that it works fine in the original package but not in the copied package. When I try to run it the function "AddtoCartForm" crashes the page and show the following error while display in red the line that contains the function call:
An HtmlHelper is required for this method. Make sure to specify one when you call the RunXmlPackage method
The format of the function is:
<xsl:value-of select="aspdnsf:AddtoCartForm(ProductID, VariantID, 1, 1, $SelectedSize, $SelectedColor)" disable-output-escaping="yes"/>
I removed the line with the function just to be sure and then everything else works fine. I have no idea what's wrong here. Everything is identical unless by the structure of the url which calls the package:
For the internal package it is: \product\123456
For the custom package it is: \topic\packagename?ProductID=123456
I checked the XML produced by the SPs, the runtime and requested data and it's basically the same in both cases. The ProductID and VariantID values are there. SelectedColor and SelectedSize are not in the XML (not even in the internal package) so it may be just providing null value and probably it's not necessary anyway.
And there is more. If I supress the productid value from the url like this:
\topic\packagename
It won't crash the page (but also won't render because there will be not be any value to process).
In any way I cannot see why it wouldn't work just passing the variable in the querystring (that is basically what it does in the original package even in a different format) and the var value (productid) it getting there. However it seems that it is indeed the url format that is not pleasing the package but it doesn't make too much sense to me. I am over this for several days already and nothing I do seem to produce any positive result. :-(
I looked up online for some documentation but didn't get lucky and didn't find absolutely anything. In extreme cases I try to reach the Vortx support (and they usually answers me giving some valueable clue) but this time it seems that for this specific issue there will not be any help unless I pay an obscene hour fee and unfortunately it's out of question... LoL!
Any idea?
UPDATE: We don't use Multistore regular search tool. Due to the nature of our products (recycled car parts) we have a custom search tool that will try to find 'similar' items that MAY fit the user needs when we don't have the EXACT part. I don't know if you are ware of but several mechanical car parts are interchangeable among different models and makes (like alternators, AC compressors, battery, suspension, cooling system, etc), so when one of our customers needs a part to fix his car he won't tell us the part code; instead he will tell us the car model, year, and generic name of the part so we will try to find the part for him. It does mean that a certain Corolla part will fit perfectly in a Honda Accord and so on. Some times we have some parts in stock that MAY fit his car but we are not absolutely sure. When it happens we will show those parts for the customer and he will decide if he can take his chances. For the sake of customer comfort we want to show all these parts in the same page, but since they normally are variants of different products we cannot use the regular product page for this purpose (because the product page will only show variants of ONE product at time). For this reason I am going to write a package - a modified version of the product page - that will do that but I am struggling with the AddtoCartForm function. In fact I JUST found a workaround by adding the item to the cart accessing directly the /shoppingcart/addtocart script and now my problem is being to force it return to a specific url after to add the item to the shopping cart...
The error has to do with the topic token able to properly get html helper filled out.
I do question why testing is being done on a topic. To test a new product xmlpackage I normally change change the xmlpackage for just one product in a testing environment.
If chaning the product xmlpackage isn't possible then I suggest using the XmlPackageController/engine instead. Which is documented on page https://help.aspdotnetstorefront.com/1000/xml_packages.htm under the heading of "Invoking XML Packages by Themselves". If using the XmlPackageController make certain that the allowengine attribute is set to true in the xmlpackage otherwise that will throw an error as well.
I've been trying to upgrade our ng-Table code to either .083 as well as 1.0.0 but keep getting the same problem. Basically my goal is in certain situations to specifically set the page of my table to a specific page instead of defaulting to page 1.
An example would be if I was on page 3 and clicked on a table item which would take me to another partial page and I wanted to return to the same place in the table (ie: page 3 instead of 1).
When I evaluate the condition I merely set the page with the following line of code:
params.page(3)
As soon as this code executes it doesn't error (in the console) but my table will no longer page using my custom pager. It does really weird things like jumps pages as well as the data does not change in the grid. Sometimes my pager prev/next buttons disappear altogether or they jump from page 2 to 4. This same code worked flawlessly when using ng-table 0.4.1 and prior. I've looked everywhere but don't see anyone else with this problem. I've seen tons of examples where someone desires to do this but not in the newer versions of ng-table 0.8.3 forward.
Below is a simple example (with extra code removed to simplify my example).
Stuck at a trivial problem in Grails 3.1.5: Show the fields of a domain object, excluding one of them, including a transient property. Yes, this is my first Grails 3 project after many years with previous versions.
The generated show.gsp contains
<f:display bean="rfaPdffile"/>
This will include a field that may contain megabytes of XML. It should never be shown interactively. The display: false constraint is no longer in the docs, and seems to be silenty ignored.
Next I tried explicitly naming the fields:
<f:with bean="rfaPdffile">
<f:display property='fileName'/>
<f:display property='pageCount'/>
...
</f:with>
This version suprisingly displays the values without any markup whatsoever. Changing display to field,
<f:with bean="rfaPdffile">
<f:field property='fileName'/>
<f:field property='pageCount'/>
...
</f:with>
sort of works, but shows editable values. So does f:all.
In addition I tried adding other attributes to f:display: properties (like in f:table), except (like in f:all). I note in passing that those two attributes have different syntax for similar purposes.
In the Field plugin docs my use case is explicitly mentioned as a design goal. I must have missed something obvious.
My aim is to quickly throw together a prototype gui, postponing the details until later. Clues are greatly appreciated
If I understood you correctly, you want to have all bean properties included in the gsp but the one with the "megabytes of XML" should not be displayed to the user?
If that is the case you can do:
f:with bean="beanName"
f:field property="firstPropertyName"
f:field property="secondPropertyName"
And the one you don't wish to display:
g:hiddenField name="propertyName" value="${beanName.propertyName?}"
f:with
So list all the properties as f:field or f:display and put the one you don't wish to display in a g:hiddenField Grails tag
You can also try:
f:field property="propertyName"
widget-hidden="true"
but the Label is not hidden in this case.
Hope it helps
My own answer: "use the force, read the source". The f:display tag has two rather obvious bugs. I will submit a pull request as soon as I can.
Bugs aside, the documentation does not mention that the plugin may pick up the "scaffold" static property from the domain, if it has one. Its value should be a map. Its "exclude" key may define a list of property names (List of String) to be excluded. This probably works already for the "f:all" tag; bug correction is needed for the "f:display" tag.
My subjective impression is that the fields plugin is in a tight spot. It is intertwined with the Grails architecture, making it sensitive to changes in Grails internals. It is also required by the standard scaffolding plugin, making it very visible. Thus it needs constant attention from maintainers, a position not to be envied. Even now conventions for default constraints seem to have changed somewhere between Grails 3.0.9 and 3.1.7.
Performance of the fields plugin is sensitive to the total number of plugins in the app where it is used. It searches all plugins dynamically for templates.
For the wish list I would prefer stricter tag naming. The main tags should be verbs. There are two main actions, show and edit. For each action there are two main variants, single bean or multiple beans.
My answer is that at present (2 March 2017) there is no answer. I have searched the Net high and low. For the index (list) and create and edit views, the fields plugin works well enough. A certain field can be easily excluded from the create and edit views, relatively easily from the list view (by listing those that should show), and in no way I could find from the show view. This is such a common need that one would suspect it will be addressed soon. Also, easily showing derived values in the show view, like 'total' for an invoice. One can do that by adding an ordered list with a list item showing the value below the generated ordered list of values, but that is kind of a hack.
In some ways, the old way was easier. Yes, it generated long views, but they were generated and didn't have to be done by the programmer - just custom touches here and there.
n my module I use the hook_node_view to make alterations to the content when it is viewed. To do this I fetch and set $node->content['body'][0]['#markup']. It works fine, but I've lately had some trouble with my teaser views which made me track the problem to the data fetched from $node->content['body'][0]['#markup'].
It seem like what is in it depends at least on the view mode because if I do write
print $node->content['body'][0]['#markup'];
either when the mode is 'full' or when it's 'teaser' I get different results.
For some reason the content of $node->content['body'][0]['#markup'] is very short when I view the content as a teaser. Shorter then the teaser length even.
This made me wonder more about what is in $node->content['body'][0]['#markup'], and when and where it is set?
Instead of using hook_node_view I would suggest using hook_node_load.
http://api.drupal.org/api/drupal/modules%21node%21node.api.php/function/hook_node_load/7
I have a requirement to perform an indexed search across content which must include a couple of tags in the result. The tags must be a random selection. The platform is Drupal 7.12
I have created a view that manages the results of a SOLR search through the search_api. The view returns the required content and seems to work as intended. I have included a couple of Global: custom text fields as placeholders for the tag entries.
I am now looking for a solution to manage the requirement to randomise the tag values. The randomisation is not the issue, the issue is how to include the random values into the view result.
My current approach is to write a views_pre_render hook to intercept the placeholders which appear as fields ([nothing] and [nothing_1]). The test code looks like the following
function MODULE_views_pre_render( &$view )
{
$view_display = $view->display['default'];
$display_option = $view_display->display_options;
$fields = $display_option['fields'];
foreach( $view->result as $result )
{
$fields['nothing']['alter']['text'] = sprintf("test %d", rand(1,9));
}
}
I am currently not seeing any change in the placeholder when the view is rendered.
Any pointers to approach, alternate solutions etc would be gratefully received as this is consuming a lot of scarce time at the moment. Calling print_r( $view ) from within the hook dumps over 46M into a log file for a result set of 2 items.
There are two possible solutions for your task.
First approach is do everything on the template level. Define a template for the view field you want to randomize. In advanced settings of your display go to Theme: Information. Make sure that the proper theme is selected and find the template suggestions for your field. They are listed starting from most general to the most specific and you can choose whatever suits you better.
I guess the most specific template suggestion for your field would be something like this: views-view-field--[YOR VIEW NAME]--[YOUR DISPLAY NAME]--nothing.tpl.php. Create the file with that name in the theme templates directory and in this template you can render what ever you want.
By default this template has only one line:
print $output;
you can change this to:
print sprintf("test %d", rand(1,9));
or to anything else, whatsoever :)
Second approach is to go with Views PHP module. WIth this module you can add a custom PHP field in which you can do whatever you want. Even though the module hasn't been released it seems to work quite well for the most of the tasks and most certainly for such a simple task as randomizing numbers it will work out for sure.
I stumbled upon this while searching for another issue and thought I would contribute.
Instead of adding another module or modifying a template, just add a views "sort criteria" of "Global: Random".