I'm trying to output certain meta description depending on resource ID and parent ID using ModX Revo.
The problem is that Modx filters only can operate only one special tag (or id, or parent id, or something else), for ex.
[[*id:is=`331`:then=`<meta name="description" content="[[*description]] — Page [[+page]]" />`:else=`<meta name="description" content="[[*description]]" />`]]
In this case tag is ID. In my situation I need to add to this condition one more statement, it must work like:
if [[*id]] is 331 then...
else if [[*parent]] is 321 then..
else...
How can I do this without creating templates or chunks?
I tried some variants:
This just doesn't work
[[*id:is=`331`:then=`<meta name="description" content="[[*description]] — Page [[+page]]" />`:else=`[[*parent:is=`321`:then=`<meta name="description" content="[[*description]] - News Page" />`:else=`<meta name="description" content="[[*description]]" />`]]]]
OR
This on the 331st resource outputs two descriptions
[[*id:is=`331`:then=`<meta name="description" content="[[*description]] — Page [[+page]]" />`:else=``]]
[[*parent:is=`321`:then=`<meta name="description" content="[[*description]] - News Page" />`:else=`<meta name="description" content="[[*description]]" />`]]
I would suggest looking at pdoField or one of the other pdoTools snippets. There are already built in parameters for doing the kind of filtering and conditionals you seem to need.
pdoField DOCS
Make sure to look at the general pdoTools properties as well as those that are specific to pdoField.
You are going to wind up with duplicate descriptions, not great for SEO & probably better ways to get where you want. But that was not the question.
Your best bet is to write a quick snippet, where you want to output the meta tag:
[[!getMeta? &resourceid='[[*id]]' ]]
in your getMeta snippet:
<?php
$id = isset($scriptProperties('resourceid')) ? $scriptProperties('resourceid') : FALSE
if(!$id){ return; }
$output = '';
if($modx->getParent($id,1,'id') == 321){
$output = '...your meta tag for the funny parent';
}else{
if($id == 331){
$output = '...your meta tag...';
}else{
$output = '...your alternate meta tag...';
}
}
echo $output;
return;
Something along those lines.
- you should be creating chunks to output any HTML OR you can store the chunk in a property set.
Related
I have a site that uses Wayfinder to display the latest 3 entries from an Articles blog. Now, I want to only consider those blog entries that are tagged Highlights.
My original Wayfinder call looks like this, nothing spectacular:
[[!Wayfinder? &startId=`296` &level=`1`
&outerTpl=`emptyTpl`
&innerTpl=``
&rowTpl=`thumbnails_formatter`
&ignoreHidden=`1`
&sortBy=`menuindex`
&sortOrder=`DESC`
&limit=`3`
&cacheResults=`0`
]]
as Articles tags are managed via the articlestags TV, I thought that a &where might do the trick, but with no luck yet:
&where=`[{"articlestags:LIKE":"%Highlights%"}]`
does not yield anything. As a sanity check, I tried [{"pagetitle:LIKE":"%something%"}], which worked. Obviously, the problem is that articlestags is not a column of modx_site_content, but I'm not sure about how to put the subquery.
SELECT contentid
FROM modx_site_tmplvar_contentvalues
WHERE tmplvarid=17
AND value LIKE '%Highlights%'
Gave me the right IDs on the sql prompt, but adding it to the Wayfinder call like this gave an empty result again:
&where=`["id IN (SELECT contentid FROM modx_site_tmplvar_contentvalues WHERE tmplvarid=17 AND value LIKE '%Highlights%')"]`
Any ideas on how to achieve this? I'd like to stay with Wayfinder for consistency, but other solutions are welcome as well.
You can just use pdomenu (part of pdoTools) instead Wayfinder
[[!PdoMenu?
&startId=`296`
&level=`1`
&outerTpl=`emptyTpl`
&innerTpl=``
&rowTpl=`thumbnails_formatter`
&ignoreHidden=`1`
&sortBy=`menuindex`
&sortOrder=`DESC`
&limit=`3`
&cacheResults=`0`
&includeTVs=`articlestags`
&where=`[{"TVarticlestags.value:LIKE":"%filter%"}]`
]]
Take a peek at some of the config files [core/components/wayfinder/configs ] - I have not tried it, but it looks as if you can run your select query right in the config & pass the tmplvarid array to the $where variable.
A little playing around led me to a solution: I needed to include the class name (not table name) when referring to the ID:
&where=`["modResource.id IN (SELECT contentid FROM modx_site_tmplvar_contentvalues WHERE tmplvarid=17 AND value LIKE '%Highlights%')"]`
a small test showed that even a simple
&where=`["id = 123"]`
does not work without modResource..
A look at wayfinder.class.php shows the following line, which seems to be the "culprit":
$c->select($this->modx->getSelectColumns('modResource','modResource'));
This method aliases the selected columns - relevant code is in xpdoobject.class.php. The first parameter is the class name, the second a table alias. The effect is that the query selects id AS modResource.id, and so on.
EDIT: final version of my query:
&where=`["modResource.id IN (
SELECT val.contentid
FROM modx_site_tmplvars AS tv
JOIN modx_site_tmplvar_contentvalues AS val
ON tv.id = val.tmplvarid
WHERE tv.name = 'articlestags' AND (
val.value = 'Highlights'
OR val.value LIKE 'Highlights,%'
OR val.value LIKE '%,Highlights'
OR val.value LIKE '%,Highlights,%'
)
)"]`
I don't claim this query is particularly efficient (I seem to recall that OR conditions are bad). Also, MODx won't work with this one if the newlines aren't stripped out. Still, I prefer to publish the query in its well-formatted form.
I used snippet as a parameter for the includeDocs of wayfinder, In my case it was useful because I was need different resources in menu depend on user browser (mobile or desktop)
[[!Wayfinder?
&startId=`4`
&level=`1`
&includeDocs=`[[!menu_docs?&startId=`4`]]`
&outerTpl=`home_menu_outer`
&rowTpl=`menu_row`
]]
and then menu_docs snippet
<?php
if (empty ($startId))
return;
if (!isMobileDevice())
return;
$query = $modx->newQuery('modResource');
$query->innerJoin('modTemplateVarResource','TemplateVarResources');
$query->where(array(
'TemplateVarResources.tmplvarid' => 3,
'TemplateVarResources.value:LIKE' => 'yes',
'modResource.parent' => $startId,
'modResource.deleted' => 0,
'modResource.published' => 1,
'modResource.hidemenu' => 0
));
$resources = $modx->getCollection('modResource', $query);
$ouput = array();
foreach ($resources as $resource)
$output[] = $resource->get('id');
return implode (',', $output);
I'm using the search portlet in certain areas of my website, but I'd like to restrict the results to only search for a specific content type: for example only search the news items, or only show Faculty Staff Directory profiles.
I know you can do this after you get to the ##search form through that "filter" list, but is there a way to start with the filter on, so that the "Live Search" results only show the relevant results (i.e. only news items or only profiles).
I suspect you know it already, but just to be sure: You can globally define which types should be allowed to show up in searchresults in the navigations-settings of the controlpanel, and then export and include the relevant parts to your product's GS-profile-propertiestool.xml.
However, if you would like to have some types excluded only in certain sections, you can customize Products.CMFPlone/skins/plone_scripts/livesearch_reply, which already filters the types, to only show "friendly_types" around line 38 (version 4.3.1) and add a condition like this:
Edit:
I removed the solution to check for the absolute_url of the context, because the context is actually the livesearch_reply in this case, not the current section-location. Instead the statement checks now, if the referer is our section:
REQUEST = context.REQUEST
current_location = REQUEST['HTTP_REFERER']
location_to_filter = '/fullpath/relative/to/siteroot/sectionId'
url_to_filter = str(portal_url) + location_to_filter
types_to_filter = ['Event', 'News Item']
if current_location.find(url_to_filter) != -1 or current_location.endswith(url_to_filter):
friendly_types = types_to_filter
else:
friendly_types = ploneUtils.getUserFriendlyTypes()
Yet, this leaves the case open, if the user hits the Return- or Enter-key or the 'Advanced search...'-link, landing on a different result-page than the liveresults have.
Update:
An opportunity to apply the filtering to the ##search-template can be to register a Javascript with the following content:
(function($) {
$(document).ready(function() {
// Let's see, if we are coming from our special section:
if (document.referrer.indexOf('/fullpath/relative/to/siteroot/sectionId') != -1) {
// Yes, we have the button to toggle portal_type-filter:
if ($('#pt_toggle').length>0) {
// If it's checked we uncheck it:
if ($('#pt_toggle').is(':checked')) {
$('#pt_toggle').click();
}
// If for any reason it's not checked, we check and uncheck it,
// which results in NO types to filter, for now:
else {
$('#pt_toggle').click();
$('#pt_toggle').click();
}
// Then we check types we want to filter:
$("input[value='Event']").click();
$("input[value='News Item']").click();
}
}
})
})(jQuery);
Also, the different user-actions result in different, inconsistent behaviours:
Livesearch accepts terms which are not sharp, whereas the ##search-view only accepts sharp terms or requires the user to know, that you can append an asterix for unsharp results.
When hitting the Enter/Return-key in the livesearch-input, the searchterm will be transmitted to the landing-page's (##search) input-element, whilst when clicking on 'Advanced search...' the searchterm gets lost.
Update:
To overcome the sharp results, you can add this to the JS right after the if-statement:
// Get search-term and add an asterix for blurry results:
var searchterm = decodeURI(window.location.search.replace(new RegExp("^(?:.*[&\\?]" + encodeURI('SearchableText').replace(/[\.\+\*]/g, "\\$&") + "(?:\\=([^&]*))?)?.*$", "i"), "$1")) + '*';
// Insert new searchterm in input-text-field:
$('input[name=SearchableText]').val(searchterm);
Update2:
In this related quest, Eric Brehault provides a better solution for passing the asterix during submit: Customize Plone search
Of course you can also customize the target of advanced-search-link in livesearch_reply, respectively in the JS for ##search, yet this link is rather superfluous UI-wise, imho.
Also, if you're still with Archetypes and have more use-cases for pre-filtered searchresults depending on the context, I can recommend to have a look at collective.formcriteria, which allows to define search-criteria via the UI. I love it for it's generic and straightforward plone-ish approach: catalogued indizi and collections. In contradiction to eea.facetednavigation it doesn't break accessibility and can be enhanced progressively with some live-search-js-magic with a little bit of effort, too. Kudos to Ross Patterson here! Simply turn a collection (old-style) into a searchform by changing it's view and it can be displayed as a collection-portlet, as well. And you can decide which criteria the user should be able to change or not (f.e. you hide the type-filter and offer a textsearch-input).
Watch how the query string changes when you use the filter mechanism on the ##search page. You're simply adding/subtracting catalog query criteria.
You may any of those queries in hidden fields in a search form. For example:
<form ...>
....
<input type="hidden" name="portal_type" value="Document" />
</form>
The form on the query string when you use filter is complicated a bit by its record mechanism, which allows for some min/max queries. Simple filters are much easier.
Let say I have an text box in an HTML page as follows.
<DIV style = "display:none;">
<DIV style = "display:inline;">
<INPUT type = "text" style = "display:inline;">
</DIV>
</DIV>
In this case, the text box will not be visible to the user. How can I identify that text is not currently visible to the user.
Dont say that, I should travel up to the parent objects to find out if they are set to not visible. I have bunch of fields to be validated like this and this would reduce the application performance.
Is there any other way to find out as this object is not visible to the user?
Thanks in advance.
If you don't need it to be pure JavaScript I would suggest using jQuery. Using the :visible or :hidden selector will accomplish what you want:
if ( $('yourElement').is(":hidden") ) {
// The element is not visible
}
http://api.jquery.com/visible-selector/
http://api.jquery.com/hidden-selector/
If you need pure JavaScript and you don't want to travel up through every ancestor element, you could try checking the element's offsetWidth and offsetHeight. If the element is hidden because of an ancestor element, they should both be 0. Note: I've always used jQuery for this, so I don't know how reliable this is.
var yourElement = document.getElementById('yourElementsId');
if ( yourElement.offsetWidth == 0 && yourElement.offsetHeight == 0) {
// The element is not visible
}
https://developer.mozilla.org/en-US/docs/DOM/element.offsetWidth
https://developer.mozilla.org/en-US/docs/DOM/element.offsetHeight
I've been trying to find a way of forcing an attribute to show as a dropdown rather than a block of options but had no luck. The code current looks like this:
case 'select': ?>
<div class="input-box"> <?php echo $this->getAttributeSelectElement($_attribute) ?> </div>
<?php endswitch; ?>
Does anyone know how to make this look like a dropdown list instead?
Thanks in advance
I had the same problem earlier today and the strangest thing was that I had the attributes (drop down) with the same properties but one displaying a drop down menu and the other a multi select menu in the advanced search.
I did some testing with different settings and it turned out that in the advanced search every attribute that is a list (drop down and multi-select) and it has more than 2 options is displayed as multi-select.
I had a look at Mage_CatalogSearch_Block_Advanced_Form stored in /app/code/core/Mage/CatalogSearch/Block/Advanced/Form.php and I saw where this condition of 2 is checked. The magento core team made it like this to make sure that the 'yesno' or boolean list are displayed as dropdown.
In the above mentioned file, starting from line 173 (on the current version of magento)
is the following code:
public function getAttributeSelectElement($attribute)
{
$extra = '';
$options = $attribute->getSource()->getAllOptions(false);
$name = $attribute->getAttributeCode();
// 2 - avoid yes/no selects to be multiselects
if (is_array($options) && count($options)>2) {
. . .
If you change the number two on the last line with the number 5, advanced search will display drop down menu on every attribute that has less than 6 options.
What I did for myself is I added a new method, getAttributeDropDownElement(), bellow getAttributeSelectElement() that looks like this:
public function getAttributeDropDownElement($attribute)
{
$extra = '';
$options = $attribute->getSource()->getAllOptions(false);
$name = $attribute->getAttributeCode();
// The condition check bellow is what will make sure that every
// attribute will be displayed as dropdown
if (is_array($options)) {
array_unshift($options, array('value'=>'', 'label'=>Mage::helper('catalogsearch')->__('All')));
}
return $this->_getSelectBlock()
->setName($name)
->setId($attribute->getAttributeCode())
->setTitle($this->getAttributeLabel($attribute))
->setExtraParams($extra)
->setValue($this->getAttributeValue($attribute))
->setOptions($options)
->setClass('multiselect')
->getHtml();
}
The next thing you need to do is a small if statement within the switch of the form (see bellow) that will check the name of the attribute and base on that to call either getAttributeSelectElement() or our new method getAttributeDropDownElement(). I leave this job to you :)
case 'select': ?>
<div class="input-box"> <?php echo $this->getAttributeSelectElement($_attribute) ?> </div>
<?php endswitch; ?>
Sorry for my English...i'm french ;-)
In your admin panel, you can choose the type of your Attributes
Make sure that your attribute is declared as a list. In my Magento version, it's the third information in the attribute admin panel after code and scope.
PoyPoy
Magento has a class for generating selects available as a Mage_Core_Block_Html_Select class (/app/code/core/Mage/Core/Block/Html/Select.php).
On your design template directory template/catalogsearch/advanced/form.phtml, replace
echo $this->getAttributeSelectElement($_attribute);
With
echo $this->getLayout()->createBlock('core/html_select')
->setOptions( $_attribute->getSource()->getAllOptions(true))
->setName($_attribute->getAttributeCode())
->setClass('select')
->setId($_attribute->getAttributeCode())
->setTitle($this->getAttributeLabel($_attribute))
->getHtml();
I would like to have two search boxes on my master page.
One that would search for content and the other one that would search for people.
I see the code in the master page that searches for content:
How would i do to add another box that searches for people?
if you know or have info on how to achieve this I would appreciate it.
thank you much
W
You can do something simple which is to put an HTML text box directly in your master page. It may not be as elegant as writing a customer user control that reads the location of the Search site, but if the URL to your search results page is static then something like this might work for you:
<script type="text/javascript">
function SearchPeople()
{
var termArr = document.getElementById("SearchTextBoxPeople").value.split(" ");
var retStr = "";
for (var i = 0; i < termArr.length; i++) {
retStr += termArr[i] + "* ";
}
document.location.href = "/Search/Pages/peopleresults.aspx?k=" + retStr;
}
</script>
<input type="text" id="SearchTextBoxPeople" />
Search People
One additional benefit of this is that you can control the input to include wildcards (which are horrible out-of-the-box for people searches). The JavaScript is simply including * in the search which allows wildcard searches. So a search for jo sm will actually send jo* sm* to the search page which will then match on John Smith.