Rikki

Members

View Profile See their activity

Posts
24,413
Joined
March 21, 2002
Last visited
2 hours ago
Days Won
84

Reputation Activity

Rikki got a reaction from MySimS3k® for a blog entry, Theme Tip: Using custom template bits April 7, 2019

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Cemmos for a blog entry, Theme Tip: Using custom template bits January 13, 2018

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from RaZor Edge for a blog entry, Theme Tip: Using Pages blocks anywhere January 10, 2017

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from Robiss767 for a blog entry, Theme Tip: Using Pages blocks anywhere July 15, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from amir_christ for a blog entry, Theme Tip: Using custom template bits May 11, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from sobrenome for a blog entry, Theme Tip: Using custom template bits May 4, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Hunter Lyons for a blog entry, Theme Tip: Using custom template bits April 29, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Using custom template bits April 29, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Shariq Ansari for a blog entry, Theme Tip: Using custom template bits April 27, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from -FP for a blog entry, Theme Tip: Using custom template bits April 27, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Veilon for a blog entry, Theme Tip: Using custom template bits April 27, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from SeNioR- for a blog entry, Theme Tip: Using Pages blocks anywhere April 26, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from SlimTall for a blog entry, Theme Tip: Using custom template bits April 26, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from kgrahim for a blog entry, Theme Tip: Using custom template bits April 26, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from LiquidFractal for a blog entry, Theme Tip: Using custom template bits April 26, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from linkmat for a blog entry, Theme Tip: Using custom template bits April 25, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Marcher Technologies for a blog entry, Theme Tip: Using custom template bits April 25, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Zen Geek for a blog entry, Theme Tip: Using custom template bits April 25, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from Stephane for a blog entry, Theme Tip: Using custom template bits April 25, 2016

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!
Rikki got a reaction from NZyan for a blog entry, Theme Tip: Advanced uses for Pages database fields April 22, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Carlos S. for a blog entry, Theme Tip: Advanced uses for Pages database fields April 21, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Haku2 for a blog entry, Theme Tip: Advanced uses for Pages database fields April 19, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from LiquidFractal for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from TAMAN for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from -FP for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Marius for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Farook for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Dylan Riggs for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Ilya Hoilik for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from Robiss767 for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from sobrenome for a blog entry, Theme Tip: Advanced uses for Pages database fields April 18, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from SlimTall for a blog entry, Theme Tip: Using Pages blocks anywhere April 17, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from Daniel F for a blog entry, Theme Tip: Advanced uses for Pages database fields April 16, 2016

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.

1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.

3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service.
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.

I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!
Rikki got a reaction from xtech for a blog entry, Theme Tip: Using Pages blocks anywhere April 12, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from Adlago for a blog entry, Theme Tip: Using Pages blocks anywhere April 11, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from Ioannis D for a blog entry, Theme Tip: Using Pages blocks anywhere April 11, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Using Pages blocks anywhere April 11, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!
Rikki got a reaction from Yurri for a blog entry, Theme Tip: Using Pages blocks anywhere April 11, 2016

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).

The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).

Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li>  </ul> </div> </nav>
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

Invision Community 5: Assign topics to moderators

Invision Community 4: Pages databases in Clubs

Invision Community 5: Live Topic Improvements

Invision Community 5: New Live Community Features

Rikki

Posts

Joined

Last visited

Days Won

Reputation Activity

More