Rikki

Introduction to responsive classes IPS4's CSS framework is responsive, meaning elements adapt according to the size of the display the users chooses to use. In most cases, the existing classes already outlined in this guide take care of it for you; for example, menus automatically adjust, and tab bars collapse into a dropdown menu on mobile phones. There may be times when you need to control on which devices sizes elements show or hide themselves. For example, if you add a custom footer element, you may want to only show it on desktop, and hide it from tablets or phones. The responsive classes that IPS4 provides allow you to control this kind of behavior. Responsive sizes used by IPS4 For the purposes of the media queries we use to control responsiveness, the following sizes represent each device: Phones - up to 767 pixels wide Tablets - between 768 pixels and 979 pixels wide Desktops - 980 pixels and wider Basic show/hide functionality The CSS framework includes two groups of three classes that show or hide elements on desktop, tablet and phone-sized devices, respectively. The classes act in an exclusive way; that is, if you use the show classes, any devices that don't match will not show the element. The opposite is also true; if you use the hide classes, then the element will not show on those devices but will show on the others not specified. The classes are: ipsResponsive_hidePhone ipsResponsive_hideTablet ipsResponsive_hideDesktop ipsResponsive_showPhone ipsResponsive_showTablet ipsResponsive_showDesktop You can combine these as needed. For example: <div class='ipsResponsive_hidePhone ipsResponsive_hideTablet'> This element *will not* display on phones or tablets, but *will* display on desktops </div> Additional classes to control element display When using the show classes outlined above, you typically need to include an additional class that controls how the element is rendered. This can be one of the following: ipsResponsive_block ipsResponsive_inlineBlock ipsResponsive_inline <div class='ipsResponsive_showDesktop ipsResponsive_block'> This element will *only* show on desktop sizes, and will render as a block-level element. </div> These additional classes aren't usually necessary when using the hide classes.

It is possible to create custom layouts for the Staff Directory page. You will need to write the templates using HTML, so to do this you will need to be familiar with HTML, as well as basic PHP logic. In the AdminCP, go to Customization -> Themes and click the "Edit HTML and CSS" button for your default theme. Then, from the "New" dropdown, choose "HTML Template". You can name the template whatever you like, and fill the rest of the form out with the following details: Variables: $users Location: Add to an existing location Existing Location: front Group: Add to an existing group Existing Group: staffdirectory Application: System You will then need to navigate to your newly created template within the many on the left (it will be under core -> front -> staffdirectory) and here is where you write the HTML code for your template. The template will be passed a $users variable which is an array of \IPS\core\StaffDirectory\User objects. Your code can include template logic and template tags You can use one of the existing templates as an example. After this you will also need to create another template with the same name (and settings above) but with "_preview" appended to the name (for example, if the template you just created is called "myCustomLayout" the template you create now will be "myCustomLayout_preview") which contains the HTML to display on the form when creating a Staff Directory group in the AdminCP. Since you know what the layout will look like, you can make this quite simple. You will need to repeat these steps for every theme you have installed (except child themes which will inherit the templates of their parents). Once this is done, when creating a Staff Directory group, you will see the template you have created as one of the available options.

IPS Community Suite has two special pages which exist entirely outside of the normal theme and language systems: error.html Displayed if there is an error so severe it is not possible to display a normal error screen (for example, if your database server is offline, it is not possible to obtain the theme and language details). upgrading.html Displayed while an upgrade is in process. You create different html pages to be used in these scenarios and instruct IPS Community Suite to use your pages instead. This will ensure that even if the contents of the files are changed in an upgrade, your customizations are maintained. To do this: Create the html pages as desired, and save them in the root directory of your community's installation. If you do not already have a constants.php in the root directory of your community's installation, create one with the following contents: <?php Open constants.php and add the following lines, replacing the names of the html files with the names of the files you have created: define( 'ERROR_PAGE', 'custom_error.html' ); define( 'UPGRADING_PAGE', 'custom_upgrading.html' );

Warning You should only change your cookie options if you have a genuine need. Incorrectly setting these options may cause issues for users in your community. Why you may need to override cookie options IPS Community Suite 4 intelligently detects the most appropriate values to set cookies for your site effectively and securely. For most users these default values work perfectly and you will not have a need to override the default settings. If you find, however, that these default options are not appropriate for your site (for instance, if you are integrating your Community Suite with an external website), then you can override the default detected options through the constants.php file. How to set up overrides in constants.php If you do not have a constants.php in your site root already, create one with just the following line at the top. This file can be used to set many different power-user level options (occasionally, some settings in the ACP will have you add to this file as well). <?php After this line you can set the following constants to override the default cookie options. Be aware that you should ONLY set the values you need to set, and leave the rest of the constants commented out. //define( 'COOKIE_DOMAIN', '.example.com' ); //define( 'COOKIE_PREFIX', 'prefix_' ); //define( 'COOKIE_PATH', '/' ); // If your front end website does not serve over SSL but your community suite does, you may need to set this //define( 'COOKIE_BYPASS_SSLONLY', TRUE );

The IPS Community Suite has the capability, which is enabled by default, to check that the IP address of the current request matches the IP address when the session was first started, and if the IP address has changed to treat the current visitor as a guest and force them to login again. This is a security precaution designed to prevent a user's session from being hijacked by someone else at a different location. While this is a good security precaution and should generally be left enabled, there can be times where this is undesirable in some hosting environments. For instance, if you are required to use the site through a proxy and the proxy IP address may change on every request, the IP address checking may prevent you from staying logged in. Changing Proxy IP Settings If you are having trouble staying logged in to your site due to this functionality, there are some settings you may need to adjust on your site. There is a setting in the ACP labeled "Trust IP addresses provided by proxies?" which allows the software to detect the original IP address of a user who is visiting through a proxy, and use that instead. In most cases, enabling this setting is what you will need to do to resolve the issue. This setting can be found in the following location in your ACP System -> Settings -> Advanced Configuration It is important to understand that enabling this setting can allow users to fake their IP address to avoid IP address bans set up in the software. On the same screen, there is a setting labeled "Check IP address when validating session?". This setting allows the software to verify that the IP address of the current request matches the IP address when the session was first started. In most environments, this should be left enabled, however in some situations (such as an intranet where all users visit from the same IP address) you may need to disable this setting to avoid session collisions. ACP IP Checks In some rare situations, you may have trouble logging in to the ACP due to the IP address checking with an error message "Your IP address does not match this session.". In order to stop this issue, you should try enabling the "Trust IP addresses provided by proxies?" setting, and if that does not resolve the issue then disable the "Check IP address when validating session?" setting, however in order to do so you must get logged in to the ACP first. There is a filesystem-level constant available that will allow you to temporarily disable IP address checking in order to get into the ACP and toggle the aforementioned setting. If you do not already have a file called constants.php in your Community Suite root directory (where conf_global.php is located), create one with an opening PHP tag like so: <?php // Constants go here Add the following line to your constants.php afterwards: define( 'BYPASS_ACP_IP_CHECK', TRUE ); Save this file, and you will now be able to access the ACP in order to change the "Trust IP addresses provided by proxies?" setting. After toggling this setting, remove the constant you just added and verify if you can stay logged in to the ACP. If so, you need not do anything else. If you continue to have trouble, add the constant again, log in to the ACP, and then toggle "Check IP address when validating session?" off and save. Afterwards, remove the constant from constants.php again and you should remain logged in to the ACP without further issue.

When you use custom templates for a Pages database, you'll often need custom CSS to go along with it to provide the styling. There's two main ways of doing this: CSS files within Pages Pages allows you to create CSS files, and then associate them with particular custom pages of your community (you create these in the AdminCP, under Pages > Templates > CSS). So simply create your CSS file, and associate it to the page that your database is displayed on. The benefit of this method is it applies to all themes, so it's great if you want your database to look the same on all themes. Of course, this is also the drawback - you can't easily use it for per-theme customization. Targeting the database classname in theme CSS Alternatively, you can target the database classname in your normal theme CSS files. When a database is inserted into a page, IPS4 helpfully adds a classname to the body element, which makes it really simple to style that page in particular. If your database key is myDatabase, then the classname added to the body element would be cCmsDatabase_myDatabase. Use this in your selectors and you can style everything exactly how you need: .cCmsDatabase_myDatabase .ipsButton_important { /* Style important buttons differently in this database, for example */ } Combine both methods! Of course, you can use both approaches when it makes sense. Create a CSS file within Pages for the basic structural styling that will apply regardless of which theme the user uses, and then in each theme target the database classname to customize it for that particular theme - perfect for the colors, font family and so on.

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change. Streamlined access to everything we offer Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more. In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important. So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website. Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on. This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature. Stay tuned!

Occasionally, you'll want to be able to change the style of a particular element on a particular page, without affecting similar elements on other pages. For example, lets say you wanted to change how the .ipsPageHeader element looks in topic view, to make the title bigger, but without changing it for all other pages that also use .ipsPageHeader. Adding a classname - the wrong way One method would be to edit the template for topic view, add a classname to the element, and then create a style using that new classname as the selector. This works, but it has a drawback - because you've edited the template, IPS4 won't be able to automatically update it for you when you upgrade to newer versions of the IPS Community Suite. We always suggest you try and avoid editing templates directly, for this reason. Using page-specific selectors - the right way There's a better way - every page in IPS4 includes some special attributes on the body tag that identify the app, module and controller being viewed. You can use these to write a CSS selector to only target pages that match the ones you want. Going back to our example, we could target .ipsPageHeader in topic view like so: body[data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="topic"] .ipsPageHeader { ...your styles } This works because topic view is generated by the topic controller, in the forums module, in the forums app. All pages in the IPS Community Suite follow this controller/module/application structure. You can mix and match these. If you want to style all page headers in the forums app only, you could simplify the above to: body[data-pageapp="forums"] .ipsPageHeader { ...your styles } You can find out the right values to use by going to the page you want to target, viewing the source in a tool like Web Inspector, and finding the body tag - look for the special data-page* attributes that are used for that page. By including these styles in your custom.css file in your theme, you can target specific elements on specific pages, without making it difficult to upgrade your community later.

The IPS Community Suite uses CKEditor to power its rich text editing capabilities. Often, when developing a theme for you own community or for distribution, you'll also want to style the editor to match. CKEditor itself is a very large and complex project. It has many hundreds of CSS classes, and explaining how to style each part of the editor is beyond the scope of this guide. We recommend you check out CKEditor's website if you need more information. That said, here's some tips to guide you. Using custom.css to style the editor Prior to IPS 4.1, we used CKEditor's older iframe mode. What this meant is that the entire text editor existed inside of an iframe on the page (although this was seamless and transparent to users). Since styles of a parent page do not apply to the contents of iframes, the only way to style the editor was to edit the CKEditor skin that we shipped with the product. This meant working outside of the IPS4 theme system, but more importantly it made distributing your changes more difficult because you'd also have to distribute your CKEditor skin. In IPS 4.1 onwards, we use the newer div mode. Instead of using an iframe, the editor is built inside a div element right on the page. This is great news for themers, because it means the CSS styles you create within IPS4 will be inherited by CKEditor automatically. So, to start styling the editor, you can simply open your custom.css file in your theme, and using a tool such as Google Chrome's Web Inspector (or the equivalent in your browser of choice), inspect the HTML that CKEditor generates and use that to develop your styling. When you save your custom.css file, you'll see it applies to the editor too. Above: inspecting CKEditor's generated HTML with Web Inspector allows you to see which CSS styles (right) are being applied to each part of the editor, helping you identify which class names you should be using in your own CSS. Or build a standalone CKEditor skin If you intend to make more substantial changes to the editor, you may still want to consider developing it as an actual CKEditor skin instead. CKEditor has a very mature skin framework that can be used for advanced changes. Consult the CKEditor for more information on creating a skin. If you go this route, you would export the CKEditor skin, and ship it with your IPS Community Suite theme. When an administrator installs your theme, they can install the CKEditor skin in the AdminCP too. So, that seems quite straightforward - in almost all cases, simply edit the custom.css file you use in your theme, and you can customize CKEditor to match your theme! But, there's gotchas... There are exceptions, of course. Even in div-mode, CKEditor still generates some iframes. For example, when you click a dropdown menu in the editor (e.g. Font), CKEditor actually builds an iframe for the menu. This introduces the same problems we discussed above, again! Unfortunately, there is no simple answer here. As before, styles you build into your custom.css file won't apply to these special areas where CKEditor uses an iframe. For many theme designers, this won't be a huge problem - being able to edit the 95% of CKEditor available to custom.css will be sufficient. But if you really do need to style the contents of those iframes, the only option is to do it within CKEditor's own skin system (since it loads those CSS files within its iframe). This isn't too problematic if you're only concerned with styling your own community. The CSS files CKEditor uses can be found in /applications/core/interface/ckeditor/ckeditor/skins/ips (if your theme uses the default CKEditor theme we provide). Edit the editor.css file in this directory to adjust the styles (this is a compressed CSS file, so add your own CSS at the end - don't edit existing CSS in the file!). If you plan to distribute your IPS4 theme, however, and you need to style these areas of CKEditor that still exist in an iframe, you'll need to go back to using CKEditor's skin system, and distributing a CKEditor skin with your theme.

By default, IPS4 has a maximum body width of 1340 pixels, and is fluid at sizes smaller than this. However, we ship the software with a customizable theme setting allowing this to be easily overridden, should you want to change the behavior. Using the Easy Mode theme editor If your theme was made using the Easy Mode editor, you can adjust the body width on the Settings tab when designing your theme. First, click the magic wand icon to launch the Easy Mode editor: And then the Settings tab. There's two settings you need to adjust; turn on Enable Fluid Width, and then change the percentage value in the Fluid Width Size setting. To have it take up all available space, set this to 100%. Using the standard theme editor If your theme was created using the standard theme editor in the AdminCP, you adjust the theme settings also in the AdminCP. Click the edit icon next to the theme you want to adjust: And on the Custom tab on the edit screen, you will see the Enable Fluid Width and Fluid Width Size settings.

By default, we use the 'comments' icon from FontAwesome to represent forums on the read/unread badges. IPS4 also includes an option to upload an image that will be used instead of the icon. But what if you want to use a different FontAwesome icon for each forum? The good news is this is possible using some custom CSS. Each forum row in the index template includes a data attribute with the forum ID, meaning we can write a style to specifically target each individual forum and overwrite the icon it uses. Note: Although this method isn't terribly complex, it does require editing custom CSS and working with unicode characters. Determining the icon unicode value The method we're going to use involves replacing the icon using a CSS rule, rather than changing the icon classname in the HTML. The reason we take this approach is it won't make upgrading your templates difficult later - our custom CSS persist through IPS4 versions easily. What this means however is that we need to identify the unicode value that FontAwesome assigns to the icons we want to use. To do so, head over to the FontAwesome icon list on this page. Locate the icon you'd like to use, and click it. On the information page, you'll see the unicode value for the icon. Make a note of this code. For example: Do this for each icon you'll want to use. Adding the CSS We're going to add our CSS to our custom.css file so that it persists through upgrades. In the AdminCP, go to Customizations -> Themes, and click the code edit icon next to the theme you want to change. On the CSS tab, open the custom.css file: The rule we need to use looks like this: [data-forumid="..."] .fa-comments:before { content: "\f123"; } You'll need to adjust this code to include the forum ID for the forum you want to change. You can find the forum ID by hovering on the link to the forum, and noting the number you see in the URL: You'll also need to replace the f123 unicode value with the one for the icon you want to use that you noted earlier. Example Let's say we have forum ID's 1 and 2, and we want to use FontAwesome's bicycle and car icons, respectively. We note the unicode values for those icons, which are f206 and f1b9. The CSS we'd add looks like this: [data-forumid="1"] .fa-comments:before { content: "\f206"; } [data-forumid="2"] .fa-comments:before { content: "\f1b9"; } Once we save it, we can see the result:

For more advanced sites built with Pages, you may want to change the output of a custom HTML or PHP block depending on which page the user is viewing. For example, if you have a custom menu, you may want to highlight the active item. We can implement this in Pages by checking the underlying page URL parameters. Although you access a page with a friendly URL (FURL) like http://<yourcommunity>/section/page, behind the scenes this is mapped to a raw URL, such as http://<yourcommunity>/index.php?app=cms&module=pages&controller=page&path=/section/page. Notice the path parameter allows us to identify which page we're accessing. When we access the \IPS\Request::i() object, we can compare against this parameter, like so: {{if strpos( \IPS\Request::i()->path, 'section/page' ) !== FALSE}} <!-- We know the user is on /section/page --> {{elseif strpos( \IPS\Request::i()->path, 'othersection/otherpage' ) !== FALSE}} <!-- We know the user is on /othersection/otherpage --> {{endif}} Note that for reliability, we're using PHP's strpos function to check for the presence of the page URL in the path parameter, rather than a simple comparison. Example Let's assume we've created a Manual HTML block, we're adding HTML to show a menu, and we want to highlight the correct item based on the page. Here's what our block contents might look like: <ul class='ipsList_inline cMyMenu'> <li {{if strpos( \IPS\Request::i()->path, 'help/home' ) !== FALSE}}class='active'{{endif}}> <a href='/help/home'>Home</a> </li> <li {{if strpos( \IPS\Request::i()->path, 'help/faq' ) !== FALSE}}class='active'{{endif}}> <a href='/help/faq'>FAQ</a> </li> <li {{if strpos( \IPS\Request::i()->path, 'help/tutorials' ) !== FALSE}}class='active'{{endif}}> <a href='/help/tutorials'>Tutorials</a> </li> </ul> If we had many items to show, it would get tedious to list them all like this. We could instead do it as a loop: // Using a PHP variable to store an array of pages => page names that we'll loop over {{$myPages = array('help/home' => "Home", 'help/faq' => "FAQ", 'help/tutorials' => "Tutorials", 'help/qna/listing' => "Questions", 'help/qna/recent' => "Recent Questions", 'help/contact' => "Contact Us");}} <ul class='ipsList_inline cMyMenu'> {{foreach $myPages as $url => $title}} <li {{if strpos( \IPS\Request::i()->path, $url ) !== FALSE}}class='active'{{endif}}> <a href='{$url}'>{$title}</a> </li> {{endforeach}} </ul> Now to add new items to our custom menu, we just have to add them to the array.

We now have a complete, working database for our recipe section! Feel free to take it further - experiment with the other options we haven't used, or if you have any familiarity with HTML coding, try creating your own templates. There's a couple of other handy features in Pages that it's worth pointing out. Database Filters When we created the Cuisine field, we enabled the Allow Filtering option. In Pages, database filters are available as a sidebar block that you can drag and drop wherever you wish to show them. On the front-end listing screen, open the sidebar manager and drag the Database Filters block to the sidebar: Block Manager Exit the sidebar manager, and you'll now see the Cuisine field available for filtering: Database Filters Category Listing It's often useful to have the list of categories shown even when you're already in a category. There's also a Pages block that adds this feature for you. Simply drag the Database Category Menu from the sidebar manager to your sidebar to show it. Here's both of the sidebar blocks we've discussed: Category Listing

Custom fields are what you use to make a database that is specific to your needs. IPS4 supports a wide range of field types so that you can collect data in the appropriate formats, from text and numbers, to upload fields and YouTube embeds. We're going to create a few different fields to gather information about each recipe that we can then display in our database. They are: List of ingredients Prep time Cook time Cuisine A link to a YouTube video recipe We don't need fields for the recipe title, or the instructions. Databases already provide a title field, and we'll also use the built-in content field for the recipe instructions. We'll see how to set up the custom fields, as well as how to customize their appearance. Ingredients field 1. To create a new field, hover on the Pages tab in the AdminCP, and then click the Fields link under the Recipes database in the menu. The screen will show you the default built-in fields for your database, including Title and Content. 2. Click the Create New button; you'll see a form where you configure your field. 3. For Title, enter "Ingredients". This is the field title users will see when adding/viewing recipes on your site. 4. For Description, enter "One per line". The description is only shown on the add/edit record form, so it's a good place to enter special instructions for filling it in. 5. For the type, we'll choose Editor in this case, because it will allow the user to format the list if they wish. The other fields on the form will change depending on which field type you choose, since each has specific options. 6. We don't require a maximum length, but we do want to require this field to be completed, so leave these settings at their default values. 7. On the Display tab, we'll configure how the field content is shown to users. First, enter ingredients as the field key. This key is how IPS4 identifies this field in templates. We won't actually be using it in this tutorial, but it's good practice to set it anyway so you can use it later if needed. 8. We don't want our list of ingredients to show on the listing screen, so disable that option. 9. We do, however, want it to show on the record display screen, since this is the main screen for viewing a recipe. A badge isn't ideal for showing content from an Editor, so change the Display View Format to the simple Label: Value option as shown: Display View Format 10. We'll show the list of ingredients above the main record content, so make sure Above the item content is selected for the Display option. 11. Finally, there's no need to allow this field to be updated when viewing a record; instead, users will go to the full edit form. You can leave the Editable when viewing a record option disabled. 12. Save the form to create the field. Other fields Other fields Other fields are created in the same way, so instead of going through the whole process again, here's the configuration options you need for each field. Where a configuration option isn't listed, leave it at its default value. Note: Some field types, including the Select Box type that Cuisine uses (see below), support a fixed set of options from which the user can choose. You'll set these up as key/value pairs in the AdminCP, but the user will only see the values when they select them. The key is just used internally by IPS4 and in custom templates to identify the value, and is best kept as a single lowercase word. Prep time Name: Prep Time Type: Text Required: No Template key: prep-time Listing view format: Label: Value Display view format: Label: Value Cook time Name: Cook Time Type: Text Required: No Template key: cook-time Listing view format: Label: Value Display view format: Label: Value Cuisine Name: Cuisine Type: Select Box Content: (key/value) indian / Indian italian / Italian american / American mexican / Mexican Allow filtering: Yes Required: Yes Template key: cuisine Listing view format: Label: Value Show to right of listing area: Yes Display view format: Label: Value Display: Above the item content Video recipe Name: Video tutorial Type: YouTube Embed Required: No Template key: video-tutorial Show in listing template: No Show in display template: Yes In a record, display as: Embedded Player That's it! If you now head over to the front-end page for your database, click into a category, and click the Add New Recipe button, you'll see your fields on the form, ready to collect information! Feel free to add some sample records to try it out. You'll also see the Record Image field that the database provides automatically (discussed earlier). When you upload an image here, you'll see it is automatically included in the record view for you. Here's an example recipe in our database: Listing View Record View

The next thing we're going to focus on is creating our categories. If you've created categories in the other IPS4 applications, it's a very similar process. How to set up categories When you hover on the Pages tab in the AdminCP, you'll see your database is now listed as a menu item, and a link for Categories is available underneath. Click this link to view the current categories. You'll see a default "Records" category. Click Create New to add a new one. We'll name this category Main Courses as an example. There's no need to manually enter a manual Friendly URL 'slug' (the slug is the part of the URL that identifies this category, e.g. <yourcommunity>/recipes/main-courses/record) - one will be created automatically based on the category name you enter. Category Creation We do want to show the record listing for this category, since it'll show recipes. We can leave Star Ratings disabled, and we'll leave Set Custom Permissions disabled too. However, if you were creating a category and wanted to use permissions different to those you set up for the database, you could enable that option and do so here. Finally, we'll leave the default database templates selected. If you had a situation where you wanted to use different templates for individual categories, these settings allow you to do so. We will ignore the other two tabs on this form for now; we aren't using the functionality they control. Refreshing our front-end, you'll now see your new category: Category List You can now go back and either delete the Records category, or edit it and rename it and adjust the settings to match. You can also create other categories, for example: Appetizers Desserts Snacks

How to add We now have our page ready, and the database created (albeit completely default and without any customization yet!). The next thing we'll do is add the database to the page. Since we created page as a Page Builder page, we can do this just by dragging and dropping. To open the page builder, first go to the page listing in the AdminCP, at Pages -> Pages. Click the magic wand icon to the right of your recipes page: Pages Listing This will take you to your community, with the sidebar manager ready to use. Open the Pages category, and drag the Database widget into the middle widget area on the page: Block Manager You can then click the Edit button on the widget to select the Recipes database: Select Database That's it! Click Finish Editing on the sidebar manager, and you'll now see your (empty) database on the page. Recipe Front End

What is a database? The Databases feature in Pages gives you the tools you need to create your own custom data-driven sections of your community. You define the settings and fields in the database, and Pages gives you support for categories, comments, reviews, ratings and more - just like full IPS Community Suite applications. Creating the database Databases are set up in the AdminCP, by navigating to Pages -> Databases. You'll see a listing of the current databases in your community. Click the Create New button to add a new one. Details tab On the first tab, we'll set up some basic details about our database. For the name, enter Recipes. This name is how users will see it presented throughout the community, such as on the search form. Enter a description if you wish; this will be shown on the homepage of the database when users visit the page. The next two settings determine how this database will handle categories and records. You can choose whether to use categories at all (the alternative being that records don't exist in categories, and are simply listed in the database), and if you do use categories, whether the user will see a category listing as the homepage or a blog-like article layout. For our use, we are going to use categories, and we want to show the category listing, so select the appropriate options: Details tab Next, we choose the templates this database will use. In our advanced tutorial we create custom templates to change how the database looks, but for this database, we're going to stick with the defaults so that we don't have to edit code. Finally, there's the database key. This is how IPS4 identifies your database internally. You can leave this blank; it will automatically create a key for you. Language tab The fields on the language tab allow you to customize the words that IPS4 will use to refer to the records in your database (since 'records' is generic and non-descriptive in most cases). Because different languages have different grammar rules, there's five variations you need to specify. For English, we'll use these: Language tab Options tab The options tab is where more fine-tuned configuration of the database happens. We don't want wiki-style editing here (which is where any member can edit any record), and we don't need to store revisions for our use. We will enable searching, though. We'll also allow both comments and reviews. Therefore, the first half of the form looks like this: Options tab Following these fields, we can set up the ordering of records in the database. Some built-in sort options are available in the dropdown list, but when you've added custom fields to the database later, they would also be available for sorting here. However, for our use, sorting by the built-in Publish Date and Descending is perfect - it means new records will show at the top, and be ordered in date-descending order. The final section of this tab deals with the record image. This is a special built-in field that allows users to upload an image to represent each record. We'll use this functionality since it suits our purposes. The default settings will work for us: Record image settings Forums tab The forums tab sets up the Pages/Forums integration for records, meaning a topic is automatically posted when new records are added. We won't be making use of this functionality, so you leave it disabled. Page tab The final tab handles the page for your database. We created a page manually in the first step, so we don't need to do so again here, but this form is an alternative way of doing so. Leave this option set to I will add this database into an existing page. After saving the form, you'll set up the permissions for the database, so configure those to your liking. Note that if a group doesn't have permission to access the page we created in Step 1, they won't be able to access this database even if you grant permission here. Also note that in Pages databases, individual categories can override these permissions if desired, allowing you to set up defaults for the database here, but have categories where access is restricted to only certain groups (staff, or premium members, for example). Adding the database to a page

The first thing we're going to do is create a page, into which we'll insert our database later. A page is the foundation of almost everything in Pages; it gives your content a place to be accessed by users. Sometimes, a page may just have static text using a WYSIWYG block. Other times (like in our case), they may be a container for a database. To manage your pages, navigate to Pages -> Pages in the AdminCP. You'll see a listing of your current pages and folders. Click Add Page to create a new one. Add Page There's two ways of creating pages: using the drag and drop Page Builder to add content, or by manually coding a page using HTML. We're going to use the Page Builder, so ensure that option is selected, then click Next. On the next screen, you'll set up some basic configuration for your page. The name is how the page will appear in the browser window, in your menu navigation etc. Since we're creating a recipe area, enter something like Recipes. The filename is how the page is accessed in a URL. Enter recipes here - this means we'll access our page at the URL <yourcommunity>/recipes. For the layout option, choose single column. Pages includes a few default layout options, and for other kinds of pages, you might want a different layout. For databases, a single column tends to work best so that it has enough space to display properly. We're going to ignore the second and third tabs (Page Includes and Title & Meta Tags) on this form for now because they aren't important to what we're doing. On the final tab, Menu, you can easily add this new page to your navigation menu. Add Menu Item Click Save when you're ready. The next screen will ask you to configure the permissions for this page, in much the same way as you'd configure permissions for a forum or gallery. Set them up to your liking, and then save the form. That's it - our page is created, and right now it is empty. We'll come back to it later and make it display something, but for now we'll move onto the database itself. Creating the database

As mentioned in the Introduction to Pages guide, unlike our other applications Pages is a blank slate. Its purpose is to give you tools to build your own areas of your community. As a result, it can seem a little intimidating to new users, and especially non-coders, because it's up to you to build what you need with the tools provided. This tutorial aims to help you get started by walking through the creation of a simple recipe section. The concepts we cover here can be applied to all kinds of sections you might want to build. Who is this tutorial for? Unlike our advanced tutorial, this one doesn't assume you have knowledge of coding. Instead, we'll be using the visual tools available in Pages, the built-in formatting options available for data, and sticking with the templates that IPS4 ships with. Our aim is to give you an understanding of how to build data-driven sections of your site from scratch. Creating a page

Database URL Structure Databases exist inside a page you've created with Pages. Individual categories and records in the database are accessed via the URL of the page. For example, if you had a page with the URL <yourcommunity>/mypage and this page contained your database, you might have a record that's accessed via the URL <yourcommunity>/mypage/category/record, where category is the category name and record is the record name. Your URLs would dynamically update themselves if you renamed your page or moved the database to a different page. To facilitate this approach, databases can only exist in one page at a time. They can't be duplicated on other pages (although you can create blocks showing data from the database and use them on other pages). Fields More advanced uses of databases require custom data to achieve their goals, and fields can be set up to gather this data. Fields are created in the AdminCP, and when a user adds a new record, the fields are shown on the form. IPS4 supports a wide range of field types, allowing you to capture data of a specific type easily. Here's the supported types: Address Provides a special auto-completing address field, powered by Google Checkbox A single on/off checkbox Checkbox set A group of several on/off checkboxes Code Provides a way to syntax-highlight code Date A date field, with a date picker Editor Provides a rich text editor for WYSIWYG editing Database relationship An advanced field type that allows records from different databases to be associated Member Provides an auto-complete member search box Number A number input box (on older browsers, reverts to a simple text box but with number validation) Password A password input field Radio A group of radio boxes (meaning only one of the options can be selected) Select box A drop-down menu containing the provided options (can allow multiple selections if desired) Soundcloud A Soundcloud embed field Spotify A Spotify embed field Telephone A telephone number input field (on older browsers, reverts to a simple text box) Text (default) A one-line text input field Text Area A multiple-line text input field Upload An IPS4 upload field URL A URL input field (on older browsers, reverts to a simple text box with URL format validation) Yes/No A toggle field that can accept yes or no values YouTube A YouTube embed field Many of these field types have additional options specific to them. For example, select boxes have an option to allow multiple values to be selected, whereas the upload has options to allow multiple files, and a way to restrict file types. Field Formatting Fields can have automatic formatting applied to them. For non-coders, a range of badge colors is available to choose from, and you have some control over the location that the field shows in the listing or record display. For coders, however, you have full control over the HTML output for each field, including having use of IPS4's template logic. This means you have the ability to use the data stored by IPS4 for each field in some very interesting ways - for example, you might take the value of an address field and use it to output an embedded Google Maps map, or even create some fields that you don't output, but instead use to control the layout of your record templates. There are a huge number of possibilities. Permissions There's multiple levels of permissions at play with databases: Page-level Since pages have their own permission settings, if the user doesn't have permission to see the page, they won't be able to see the database either. Database-level Permissions can be set at a database-level, which forms the default permissions for categories in the database too. Category-level A category can optionally override the database-level permissions and provide its own. This is useful for hidden categories - perhaps staff only, or a category only for premium members. Managing Databases Databases are managed by going to Pages -> Databases in the AdminCP. You'll also find that databases are listed in the Pages menu in the AdminCP for quicker access. From this screen, you'll see some simple information about each of your databases, as well as menu items to manage each part: Managing Database Records can be added either via the AdminCP (click the icon) or via the front-end page that displays the database. This means users don't need AdminCP access to add/edit records. Creating Databases To create a database, click the Create New button on the screen above. There's a number of configuration options available to you. Details The basic settings for this database. At the bottom of this tab, you can choose the templates you want to use for this database. If you haven't created them yet, you always do this later. Language On the Language tab, you set up the words that will be used to refer to records in this database (rather than the generic 'records' terminology). For example, if you are creating a database for guides, these language choices will mean IPS4 will refer to your database in context, such as "Search Guides", "There are 5 guides in this database" and "Create a new guide". Options This tab more finely controls how your database will work, including comments, reviews, tagging, and the 'wiki-style' editing we covered earlier. Sorting options are also available here, allowing you to choose the order of records, and more importantly, the field on which they are sorted. For example, if you had a database containing records about dinosaurs, you may want to sort the records by Era (a custom field you will have created). You can return to this tag after creating your fields later to configure it. Forum This tab configures the aforementioned Forums integration for the database (individual categories can override these settings too). Page Since a database requires a page in which it displays, you can easily create one here as part of the database creation process. Alternatively, you can add it to one of your existing pages later. Adding to a Page If you don't create a page as part of the database creation process (above), you can do so manually by using a special database tag in your page content. On the Details tab of the database form, you specified a database key. This is how this database is included in pages. If the key is my-database, you'd insert it into a page by placing this: {database="my-database"} As mentioned above, a database can only exist on one page at a time; trying to use this tag on multiple pages won't work correctly.

Templates, CSS and JS files are the means by which coders can take the default output of the various parts of Pages, and customize them to build unique parts of their site. Note: only those familiar with HTML, CSS and some PHP should consider modifying their templates. Since they involve editing code, it's easy to break the output of your site unintentionally! Types of template in Pages Templates are the key to customizing areas of your Pages website so that they're unique to your site and to your particular use of them. There's three primary types of template you can customize: Database templates Databases templates let you change the output of just about every part of your databases. There's four main types of template: Category Index The templates that render the category index of a database, and subcategories when browsing the record listing. Listing Templates that render the record listing Display Templates that render record view itself, including comments & reviews Form Templates for the add/edit form, allowing you to customize this form per-database Page templates By default, a page will use the suite wrapper, which includes the header, navigation, user bar etc. leaving your page content to control the actual content area. However, you can instead choose to use a custom page wrapper, allowing you to control the entire output of the page. Wrappers are created as page templates, and selected when you create your page. Block templates When you create a plugin block showing a feed of data, IPS4 uses a default template. You can however customize this template or create a new one, allowing each block to have a unique appearance. What can blocks contain? Blocks can contain the full range of IPS4 template syntax, which affords great flexibility. The data available to each template will depend on its type (for example, a database listing template will receive data from the database category, but a block template will receive data that matches the block's filters), but all templates can access the full underlying IPS4 PHP framework. Creating & Editing templates Database and page templates are managed in the Pages template editor, accessed by navigating to Pages -> Templates in the AdminCP and clicking the New button. Default block templates are also managed in the template editor as above, but can also be customized per-block within the block configuration themselves, by going to Pages -> Blocks in the AdminCP and then editing the block in question. CSS & JS files To fully customize sections created with Pages, it's often desirable to add custom CSS and Javascript. Pages offers a built-in way to write and use these resources and then assign them to a page for use. CSS and JS resources within Pages are managed by navigating to Pages -> Templates in the AdminCP, and then clicking the CSS or JS tabs in the editor. New resources can be added by clicking the New button. To assign them to a page, simply select them on the Includes tab when creating or editing a page in the AdminCP.

What is a database? Databases are one of the most powerful and flexible features available in the Pages application. With some configuration and customization, they enable you to add complex, data-driven areas to your community, using some of the basic underlying functionality that full IPS4 applications have. Databases, as the name implies, are designed to hold data and display that to the user. This might be as simple as a table of records each containing a title and a body, from which you could make a very simple blog-like section, or it might be as complex as a completely custom interface backed by a large number of custom data fields specific to your needs - and the possibilities for this are endless. Features Searching Databases are searchable by default (although you can turn this off if desired). Each database is treated as a distinct area of your community, so on the search form, each database is listed as a first-class area to search, much like the Forums app for example. Core suite features Pages provides a range of core application features to databases that make even the simplest database feature-rich and well-integrated with your community from the outset. Commenting and writing reviews for records is available (although this can be disabled per-database). Users can also follow categories and records to be notified of new content wherever they are in the community. Social features such as reputation and sharing to other social networks is also built-in and available for records. Tagging and full moderation of records is also supported by default, and integrated across the suite as you'd expect. Wiki-style editing In terms of adding/editing records, databases in Pages behave much like you'd expect from our other applications; that is, when a user with permission creates a record, they 'own' it. However, databases have an option for wiki-style editing, whereby any user can edit records after they are created. This approach is great for community-curated content. Revisions Databases also support revisions for records. This means each time a record changes, the previous version is saved as a revision that can be accessed again later - you can also revert to an earlier revision if desired. Forum Integration Finally, databases has special integration with our Forums app. When posting a new record to a Pages database, IPS4 can optionally cross-post the record as a forum topic, to a category of your choosing. But it goes further - you can even use the forum topic as the comments for the record, rather than the standard commenting interface that records have. What does a database consist of? There's a few key components in a database to be aware of when creating one: The database itself Naturally, you need to create the database itself. This is where you configure options that affect that database as a whole, such as sorting, permissions, and so on. Categories If your databases uses categories (you can optionally choose not to), they add another level of structure and permissions. Fields We'll cover fields in more depth shortly, but you can create custom fields for all kinds of data that you might need for your database. IPS4 supports a wide range of field types, from simple text boxes up to YouTube embeds, upload fields and intra-database relationships. Templates Templates allow you to customize the output of the database. Default templates are supplied with IPS4, and if you aren't a coder, using these defaults allow you to get a database up and running quickly. For coders, however, customizing templates is the best way to build complex data-driven applications. Templates, CSS & JS

What's a block? In Pages, a block is simply a section of reusable content. These can come from the applications in your community, be custom ones based on other built-in blocks, or be entirely custom. If you're comfortable with code, custom blocks allow you to achieve some complex results since the full range of IPS4 template logic is available to them. If you aren't comfortable with code, you can still create blocks based on built-in blocks using a simple wizard. Blocks can be inserted into your own custom pages, but also into any page generated by IPS4 (if the sidebar appears on the page, this can be done with drag and drop from the sidebar manager, or you can manually show the block by including its tag in IPS4's templates). What can blocks be used for? There's a huge range of uses for blocks. Custom blocks based on built-in blocks are a great way of highlighting worthwhile content in your community. For example, you could create a block showing a feed of the most popular topics in a particular forum you specify, and use the block to cross-promote that forum in related areas of your community. Custom blocks are larger in scope by their nature. They can range from simple HTML that you want to use in multiple places to reduce repetition, all the way to custom PHP that can be used to dynamically generate content. Common uses for custom blocks include providing a convenient way to insert Javascript in your page, building page headers with dynamic elements based on the page in which they're used, and including site notices in your community pages in an easy-to-edit way. Managing blocks Blocks are primarily managed in the AdminCP by going to Pages -> Blocks. Blocks can be organized into categories, although this has no impact on users - it's simply for ease of management via the AdminCP. Creating blocks Blocks are created from the same screen. When you click the Create New Block, you're prompted to choose between Plugin and Custom. Plugin A plugin block is one based on an existing data source from the IPS Community Suite, such as members, forum topics, upcoming calendar events and so forth. Although the data source provides the data, the block configuration you set up allows you to define filters to customize what subset of the data is shown. For example, you could create a feed of topics, from a particular forum, with more than 10 replies. Plugin blocks use a default template, but you can choose to override or customize this template with another. Custom A custom block can be created using a rich text editor, HTML (including IPS4's template logic), or pure PHP. Using blocks Using blocks On pages built using the Page Builder, blocks can be dragged and dropped into position by using the sidebar manager (the available areas on the page to receive the block will depend on the layout you chose when the page was created). On pages built using custom HTML (or if you want to insert the block in an IPS4 template), a special tag is used to insert the block: {block="block_id"} Block caching Custom blocks can optionally be cached, meaning the resources required to render the block are reduced. If your block is dynamic in any way (such as rendering differently based on the user viewing it, or the page it is being shown on), you should ensure that caching is not used. For plugin-based blocks, IPS4 handles the caching behind the scenes for you. Databases Part I

The foundation of Pages (the application) is the page (the thing). Tip To alleviate confusion in these tutorials, the application "Pages" will always be referred to with a capital letter; pages within the application or community will be lowercase. What is a page? A page is a container for content. Depending on your needs, a page can simply contain simple content (whether that's plain text, or rich content with images, embeds, and the other things you're used from our other applications), or more complex content like blocks and databases (see later steps to find out more about those). If you are comfortable with code, you can also use all of our standard template logic in a page, allowing for some highly custom results. For those who aren't comfortable with coding, there's an easy page builder, allowing you to drag and drop components into your page. A page has a URL, and can be automatically added to your menu navigation when you create it, if you wish. A page can also have custom permissions, allowing you to restrict who can or cannot access the page. This is great if you want to build special sections of your site, perhaps for staff or premium members only. Prior to Invision Community 4.3, Pages were not searchable (although external search engines such as Google will index them). However, if you have a database on a page, the content of the database will be searchable. Creating Pages Pages are created via the AdminCP, by navigating to Pages -> Pages. A directory listing of your current pages will be shown. Folders are supported here as you'd expect; the URL of the page will reflect this structure. For example, a page called index in a folder called guides will have the URL <your community URL>/guides/index. When you click the Add Page button, you are asked whether you want to use the Page Builder or Manual HTML. Page Type Page Builder After creating the page in the AdminCP, you'll be able to go to the front-end to add content to your page, using drag and drop from the sidebar manager. This option is best for those not familiar with HTML. Manual HTML When you choose this option, you'll be provided with a code editor to create your page. Within this code editor you're free to use HTML, as well as the full range of template logic supported by IPS4. With this method, you insert other items (blocks, databases etc.) into the page by using special tags. A sidebar on the editor show you the available tags. Managing content in pages with the drag and drop editor If you've created a page using the Page Builder options, after saving the configuration in the AdminCP, you can head over to the page on the front-end to manage its content (click the View Page option from the menu on the page listing screen to easily navigate to it). By default, the page will be empty. Click the sidebar toggle to open the sidebar and see the available widgets. All of the usual widgets are available to you from across the suite, but under the Pages category are a handful of special reusable widgets: Block Manager Of these, WYSIWYG Editor is the one you'd be most likely to use when setting up your pages. It gives you a standard IPS4 rich text editor to add content to the page. Simply drag it into a location on your page, then click the Edit button to access the editor. We won't cover the other blocks here since they are specific to other kinds of functionality within Pages. Managing content in pages using Manual HTML When you create a page using manual HTML, you can choose how much of the standard IPS4 wrapper you start with. By default, the suite wrapper is included in the output. This encompasses the header, menu navigation etc., meaning the content of your page is inserted inside this wrapper. With this option disabled, the suite wrapper isn't used - you'll be responsible for providing this (you can however choose a custom page wrapper you've created). If you use the suite wrapper, you can also choose whether the standard sidebar is included in the output. The content you enter into the code editor forms the main page content, and the sidebar will be managed as usual with drag and drop on the front-end. Adding to Navigation When you create a page, you can easily add it to your site's main navigation menu under the Menu tab on the page edit screen. Alternatively, you can add it to the menu manually via the normal menu management process. Setting as Default Often you will wish to set the pages application as your default application, so that you can show a page you created as your default homepage. For this, along with how to create a basic homepage, please refer to the following guide. Blocks

Introduction Pages is our application that is designed to allow you to build custom areas of your community. These could range from custom reusable blocks to use in your sidebar, all the way up to complex applications built using our databases feature. Whereas our other applications provide a regimented (although customizable) front-end that's ready to use right after installation, Pages is a little different. Think of it more as a toolbox - it provides features that you use to build your own front-ends. Therefore, you need to put in some work once you start using it before you have anything to make live. This guide will cover the core concepts and features in Pages to help you get started. Who is Pages for? Pages has features for everyone! It has easy-to-use features like drag'n'drop page building, but under the hood, the entire IPS4 framework is available for power users to take advantage of. The wider your knowledge of HTML & PHP, the more advanced solutions you'll be able to develop, although no experience of HTML & PHP is required to get started with Pages! Pages