Join Now

Click here to join our
growing community:

JOIN LOGIN



Blog

Latest News
Recent Posts
Search
Archives


Comments

Infrastructure
September 4
The Command Center
August 17
Roses and Page Names
August 13



Copyright © 2020
Terms of Use
Privacy Policy
BoltWire

Roses and Page Names

Posted 09/18/20, by Dan Vis

Have you ever wondered how page names really work in BoltWire? I mean, you know they can be set to anything, but what pages names should you use? Today's memo should help...



Shakespeare once wrote: "a rose by any other name would smell as sweet", suggesting what you call a thing is less important than what it is. And generally that's true. But in Boltwire, what you name a page is extraordinarily important--because of the software's hierarchical page name capabilities. That basically means you can apply all sorts of features to any page or group of pages based on its "location" in the page name hierarchy. Change its name, and you change its features.

What do I mean by hierarchical page names? Consider a page like animals.dogs.poodles. It's a basic hierarchy, with poodles being "in" dogs, and dogs "in" animals". Or to put it differently, you can create custom characteristics for all animals, all dogs, or just the poodles page. You can learn more about how it all works in our Welcome Tour. And there's a more advanced tutorial in the concepts section of The Handbook, you may wish to take a look at.

In this tutorial, I want to list the most important page hierarchies used in the core distribution to help you in your own site development. While you can make BoltWire work pretty much anyway you want, understanding and following our basic philosophy of page names will help you get off to a good start.

Let's begin with the "core" page hierarchies that have special functions in the code:

Core Hierarchies

action: These pages are typically forms and functions you perform on another page. When you load some.page&action=edit, action.edit is superimposed over some.page, in this case enabling you to edit the content on that page. Actions are the most powerful and special page hierarchy in BoltWire.

block: Block pages are small snippets of code that can be embedded in your section to create tabs or a sitemap or banner or whatever. Blocks are somewhat related to zones, but work slightly differently. When you put <<block tabs>> in a skin file, it loads block.tabs for every page on your site. When you put [[side]], BoltWire will load the page that best fits your page location. IE, blog.side on a blog page, forum.side on forum page. Or just the "side" page if it can't find anything more specific. Note that blocks can also be included into regular site pages. The blog and forum pages for example, both use block.comments to instantly add, well, comments.

code: Code pages are special because when you view the page, it's content is automatically escaped, so no markup is triggered. This makes it ideal for including various kinds of scripts you would not be able to load on another BoltWire page for security reasons. Here are some examples of common kinds of code pages:

   code.email - email templates for outgoing messages
   code.embed - embedded scripts
   code.form - forms you want to use elsewhere
   code.js - a special page where you can store short javascript snippets
   code.message - content for outgoing email messages
   code.messages - content for our warning and success messages
   code.template - templates used in search and query functions
   code.list - optional lists, such as countries, or all 50 states
   code.skin - special pages in the skins folder used to create skins

member: This hierarchy uses some special coding to create individual member profile pages for everyone with an account on your site. So member.0017 will forward the viewer to member.profile&id=0017 which is designed to pull in their mbase member information. You do not need to create any member pages--and it's not recommended you do. Just leave this system alone--other than customizing the profile page as desired (there's also action.member.missing).

group: Group pages are simply lists of member ids used to define which members are used in a group. Some default groups are guest, member, editor, and admin. BoltWire's group management system is very flexible and powerful.

site: This is essentially the site admin section of your site, containing any pages you are likely to use in managing your site. Just go to the "site" page to see some of the resources here. Some of the most important sections include:

   site.auth - authorization pages for various features
   site.config - all kinds of site configuration options
   site.languages - managing language files on your site
   site.plugins - docs on our many built in plugins
   site.skins - tools for previewing and editing various skins

info: There are no info pages in the core distribution, but these are essentially the best place to store "info vars" on various topics (ie, lines of "field: value" pairs). There's a special auth page just for managing the data you store here and who can access it. Many sections of BoltWire use info files for processing data.

index: Index files are generated to make it easier to scan groups of pages for content. For example, a blog or forum index can be used to search for information on a pertinent topic. You can also index links, or tags, or create your own custom indexes. See the indexing tutorial for help on getting these working.

Advanced Hierarchies

In addition to the above pages, which are generally hard coded into BoltWire, you have other pages with "recommended" purposes. That is, you could change things up, but following this basic approach will help keep all your pages in the optimal location to use our core pages and plugins.

welcome: There are several welcome pages, and they generally provide tools to service visitors at your site who are not logged in. This includes your account creation process, login, and password reminder pages. I generally point most high level links to pages like welcome.blog or welcome.forum and then use those pages to check their login status and forward the user to the appropriate section. Comparing the content in those two pages for example, you can see that welcome.blog is designed to be accessible to visitors, while the forum area requires you to login. Also, note that the main starting page for people visiting your site is page "welcome". My recommendation is you use this page to forward logged in users to members (the first page they see after logging in) and create a splash page (see below) for outside visitors.

members: These pages are normally restricted to logged in members and provides basic services for logged in members. What you put here will depend entirely on your community. Think of it as a space holder.

new: There are just a couple pages in this hierarchy used in the account creation process. The new.member page allows you to collect additional information for account creation after their email has been created. Normally, no other access to the site is possible until this "intake" form is completed. Definitely worth customizing! And the new.start page is the first page they see after that intake form is received. Usually, this would be designed to initiate some welcome or onboarding tour for new members.

splash: By default, these pages are designed to use the splash skin which allows you to create full screen fancy landing pages. One sample is included, but you can make as many as you like. Editing these requires some familiarity with html. These pages are designed to serve as full featured "landing pages" for special offers. On my site, I set the welcome page (no child welcome pages) to use the splash skin and then include the splash page I want. This makes it easy to create multiple splash pages and switch them up an any time. But you can certainly create custom splash pages and provide direct links to them. If you created a series of code.splash pages, you could use them as building blocks (just include them) for rapid landing page development. I'm planning on building some of these blocks for the accelerator program--but you could do the same thing.

offer: These are more typical looking pages, used to promote special offers, like a lead magnet resource for signup, or a class enrollment page for members, or whatever. The core distribution doesn't include any offer pages in the core--but the name space is recommended for that use. The accelerator program will definitely use these along with code for various kinds of signups.

blog: Pretty self explanatory. This section is designed to display your blog posts. There's also a site.blog section for blog management.

drafts: This is where blog posts are saved while you work on them. Once they are ready to be published, the scheduler simply renames them to a blog page.

forum: Also self explanatory. The core distribution provides a single forum area. The accelerator platform allows for multiple forum discussion areas to help organize content. But you can always modify your forum to work that way if you want.

resources: There is just a placeholder for this in the core, but if you plan on providing a bunch of resources to your members, consider storing them here in the resources directory. Use a welcome.resources or members.resources page for your index, and then store each resource at resource.somename, resource.anothername, etc.

box: Box pages are primarily used for popups where you only want to display a bare bones message to the user. The action.help function can be set to popup conveniently, for example. It works simply be setting box pages to use the box skin.

Accelerator

Here is a list of a few more hierarchies used in the accelerator platform which you may want to replicate in your own site. Having a plan for your pages is half the work!

account: These aren't used in the core distribution, but in the accelerator program, these create all sorts of member support pages, like uploading a picture, changing a password, managing your payment cards, etc. I recommend you too create a special section for all your support pages related to member accounts.

class: I recommend using a dedicated class hierarchy for all your classes. If you have different kinds of classes, you could create a different for each class type, however. The second part of the page name is the class id, that is class.parenting, class.exercise, class.gardening, whatever. Within that there are several standard page types for things like class.id.day.1 (day one reading) class.id.quiz.1 (quiz one), class.exam (final exam), etc. Often this is linked with an offer.id page promoting the class. The core distribution doesn't come with a built in class builder, but there is one used in accelerator platform.

drip: The accelerator platform also has some advanced email sending capabilities. These use drip pages. So if you wanted to send a daily email to go with the readings in your class, you create a drip.id file, with the id matching the class. More on this in the pro module tutorials.

cron: Cron pages are special pages used by BoltWire to run automated processes. This is an advanced feature in the accelerator platform, but if you are familiar with cron you can use this hierarchy too, for indexing, and many other processes.

rss: Similar to the box skin, rss pages are set to use the rss skin, which allows you to create dynamic rss feeds using BoltWire's rss pro module to generate them. A great tool for automatically updating social media accounts for example.

This list is hardly exhaustive. The accelerator program uses a hotline hierarchy for its Help Hotline feature. There is a full Bible program using bible.header and action.bible.missing to tap into an external page library. There is also a messaging system which saves pages to a messages hierarchy with page names like messages.0014 or messages.0015 (one for each user). And let's not forget, there's a news page for creating a simple site news feed!

On my site for example I have a large "tools" hierarchy filled with some 20 different online apps. And there's a "team" hierarchy for organizing specialized groups. And some sections work a bit differently than described above. My blogs for example are all stored in an "article" hierarchy. And my short classes are in a "challenge" hierarchy.

You too can create your own custom page hierarchies, add pages to any of the above page hierarchies, or even change your hierarchies around a bit (in some cases) to use non-standard hierarchies. The choice is yours! It just helps to have a quick overview of our BoltWire topography in designing your site.

Good luck planning out how your site will work! It may be true that a rose by some other name would still smell sweet, but what you call a page in BoltWire can make a huge difference!

What do you think? Did you find this information helpful? Do you have questions about page hierarchies? Feel free to ask it below, or just leave a note!


Comments




No comments yet...



Join Us

To read more posts, or to leave a comment, join our FREE community...

JOIN NOW