Getting Multiple Object Fields — FAST

In some previous articles, we discussed a fast way to get individual object fields in MODX Revolution with getValue(), but what if you need more than one field?

In this article, we’ll look at a very fast way to get multiple object fields and place them in a PHP array without retrieving the whole object.

 

MODX logo

 

The Method

This is an example that gets several resource fields from the resource with the ID 12:

$query = $modx->newQuery('modResource');
$query->where(array('id' => '12'));
$query->select(array(
    'ID'        => 'id',
    'Class'     => 'class_key',
    'Context'   => 'context_key',
    'Published' => 'published'
));
$results = array();
if ($query->prepare() && $query->stmt->execute()) {
    $results = $query->stmt->fetchAll(PDO::FETCH_ASSOC);
}

echo print_r($results, true);

 

The code above will display something like this:

Array
(
    [0] => Array
        (
            [ID] => 12
            [Class] => modDocument
            [Context] => web
            [Published] => 1
        )
)

 

Note that the terms on the left side of the select() array are arbitrary “aliases”. You’re free to use the actual field names, but whatever you use will provide the keys for the $results array. That allows you to use them as captions in the output instead of the actual field names, as in the example below. The values on the right must be the actual field names.

 

Things to Remember

In order to use this method, you need to know the actual names of the fields you need. You can find the available fields for each MODX object here.

As we saw in the previous article, the results will be in a nested array, even if there’s only one result. It will be an array where each member is an array of 'fieldname' => 'value' pairs representing one row of the table. If we had used the code below for the where clause, we’d get many results, each nested under the larger array:

$query->where(array(
    'published' => '1',
));

 

You also need to remember that, just like in the previous article, you will be getting the raw field values because the data is not being passed through the xPDO get() method. Date fields will be in the form of Unix timestamps and fields like the modUser object’s extended field and the properties field for resources and elements will be returned as JSON strings. If you are getting a TV values, you’ll also get the raw, un-rendered values, which might be @INHERIT, for example.

 

Walking

Because we created our own array keys in the code above, we can walk through and display the array with nested foreach loops, like this:

foreach ($results as $result) {
    foreach ($result as $key => $value) {
        echo "\n<br/>" . $key . ': ' . $value;
    }
}

The output of that code for each object would look something like this:

<br />ID: 12
<br />Class: modDocument
<br />Context: web
<br />Published: 1

 

This double foreach loop will only work if you can display the raw field values without processing any of them.

 

Using Tpl Chunks

Rather than the double foreach loop shown above (which usually isn’t very practical), you can use a Tpl chunk with placeholder tags to format the data, and still have very fast page-load times. Using our example query above, here’s an example using a simple Tpl Chunk.

 

MyChunk Tpl Chunk

<p>ID: [[+ID]]</p>
<p>Class: [[+Class]]</p>
<p>Context: [[+Context]]</p>
<p>Publisher: [[+Published]]</p>
<p>&nbsp;</p>

 

The PHP Code

$output = '';
foreach ($results as $result) {
    $output .= $modx->getChunk('MyChunk', $result);
}
return $output;

 

At first glance, this looks like the standard way to process results using the Tpl chunk, but it’s not. Notice that the placeholders are not the actual field names — they are the “captions” (more correctly, the “aliases”) from the *left* side of the $query->select()array we used above to get the data. In the standard Tpl chunk usage, we call toArray() on the objects and the actual field names are the “keys” of the resulting array. In this case, we were able to create our own aliases in the select() call.

That said, it’s usually a good idea to use the actual field names (assuming that you know them) for both the select() call and for the placeholders just so that, when entering the placeholders, you don’t have to remember exactly what aliases you used. If you already have the Tpl chunks and are converting to this method, you’ll definitely want to use the actual field names for the aliases — that way the Tpl chunk won’t need to be changed.

 


For more information on how to use MODX to create a web site, see my web site Bob’s Guides, or better yet, buy my book: MODX: The Official Guide.

Looking for quality MODX Web Hosting? Look no further than Arvixe Web Hosting!

Tags: , , , , | Posted under MODX, MODX | Leave a comment

Opencart – color mind games

Believe it or not, the color you choose for you website involving backgrounds, fonts, lines, designs, images and other things is super important to keeping customers on your website. Color is not something designers take into consideration nearly enough and as a result, customers are lost because of short page visits. The psychological aspect of colors and how they play on the eyes could determine the exact length of time a user will stay on your website. Sometimes people that end up closing the browser down don’t even know why they did it. I’ve actually studied this and designed enough websites to know that this is valid.

Learn More

Tags: , , | Posted under OpenCart | Leave a comment

Remove or edit the crawler block on Textpattern index pages

admin-ajax

If you’re using the default Textpattern CMS theme included from 4.5.0 onwards, it’s likely that some of your index pages will not be included in reputable search engine results. That’s not necessarily a reflection of the quality/quantity of your content, it’s more likely to be be the way the template code is constructed. When I refer to index pages, that typically refers to URLs where multiple articles are listed in succession. There’s a school of thought in search engine optimisation (SEO) that dictates you should minimise duplicate content in your website. These reputable search engines – and I’m generalising a little – prefer unique content, and if you have a website with a front page of articles, sections with articles and individual articles, you could have three or more instances of the same article.

To that end, Textpattern’s default theme has directives for search engines to index certain URLs and ignore others. The code in question is:

<txp:if_search>
<meta name="robots" content="none">
<txp:else />
<txp:if_category>
<meta name="robots" content="noindex, follow, noodp, noydir">
<txp:else />
<txp:if_author>
<meta name="robots" content="noindex, follow, noodp, noydir">
<txp:else />
<meta name="robots" content="index, follow, noodp, noydir">
</txp:if_author>
</txp:if_category>
</txp:if_search>

Let’s figure this out line by line. The opening tag, `<txp:if_search>`, will run its contents if the URL being viewed is search results – the contents in this case being `<meta name=”robots” content=”none”>`, which is a directive for search engines and crawlers (robots, if you like) to neither index or follow the links on the page, essentially ignoring the content and treating it as transient. The `<txp:else />` tag that follows starts a new condition that runs the innards if the URL is not search results. So, essentially, if it’s search results – ignore it, and if it’s not search results then start processing the new tags after the `<txp:else />` part.

This is a great example of tags in tags, or tag nesting if you prefer. There’s no official term for it, so choose whatever works for you. If the URL is not search results, there’s a check to see if the page is a category listing – if it is, then the directive instructs the search engine (robot) to not index the content, but to follow the links elsewhere, opt-out of the Open Directory Project at dmoz.org and opt-out of the Yahoo! Directory. The same goes for the next tag in a tag – if the URL is the result of an author article listing, it does the same thing: no indexing, follow the links, opt-out of Open Directory Project and Yahoo! Directory. The final part of the tag tree is, essentially, if none of the above are true, index the content, follow links, but still opt-out of Open Directory Project and Yahoo! Directory.

Any or all of the above can be flipped, edited or completely removed. If you’d prefer to let the search engine, reputable or otherwise, figure out what’s best for its listings, then deleting the above code from your page template will achieve this result.

Looking for quality Textpattern Hosting? Look no further than Arvixe Web Hosting and use coupon TEXTPATTERN for 20% off your first invoice!

Tags: , , , , , , , , , | Posted under Textpattern | Leave a comment