Getting started

This book is for the person who runs a hub. It covers the administrator interface — the back end at /administrator — and the settings, screens and extensions you reach from it. It starts from a hub that is already installed and answering; it does not cover installing the software.

What a hub manager does

A hub is a Hubzero site: a public front end that members browse, and a private back end where you configure it. Almost everything in this book happens in the back end. The recurring jobs are:

• Configure the site: its name, its template, its menus, and the components that provide its features.
• Manage members: their accounts, the access groups they belong to, and what each group is allowed to do.
• Curate content: articles, resources, publications, and whatever the hub's members submit for approval.
• Install and configure extensions: components, modules, plugins, and templates.
• Keep the site healthy: support tickets, cron jobs, site notices, and the spam filters.

Read this first

The administrator interface explains how to reach the back end, who is allowed in, and what each of its menus contains. Read it before anything else in this book; every other chapter assumes you can find your way around those screens.

Then, if the hub was installed this week, work through The first week with a new hub. It puts the decisions a new hub needs — the site name, mail, registration, access, which components to keep, the front page and menu, and the scheduled jobs — into the order that works, and links to the chapter covering each one.

How a hub fits together is the short chapter that explains what the hub is doing underneath those screens: the two halves of the application, how a page is assembled out of a component, a template and its modules, where the platform ends and your hub's own material begins, and what you can and cannot break. Every other chapter in this book assumes it. Read it whenever a change made in one screen turns up somewhere you did not expect.

Then

• If the hub is new, go on to Advanced setup and Configuring. Between them they cover the global configuration, the site template, the menus, and registration — the choices that are hardest to change once members have started using the hub.
• If you are taking over a hub that is already running, go to Daily maintenance and Users.
• If you are looking for one particular screen, the Components and Extensions chapters are organised the same way the Components and Extensions menus are.

Every setting the interface offers is also listed, component by component, in the generated configuration reference.

The first week with a new hub

What to do first with a hub that has just been installed, in the order that works. The software is running, the site answers, and you can sign in to the back end — and now several dozen screens are asking for decisions, some of them painful to change once members have accounts and content. This chapter puts those decisions in order, links to the chapter that covers each one in full, and says which shipped defaults surprise people.

It is for the person who has just been handed a new hub. It does not repeat what the linked chapters say; read it beside them. If you are taking over a hub that already has members, this is the wrong chapter — go to Daily maintenance and Users instead.

One example runs through the chapter, because the right answer to most of these questions depends on what the hub is for. Take a hub set up for a soil-carbon project shared by three universities: about forty named collaborators today, working on data they are not ready to show anyone, and a public data release in a year and a half. That hub wants accounts somebody approves rather than accounts anyone can create, mail that reaches people at three different institutions, and — well before the release — a decision about whether published material is reviewed before it appears. A hub meant as a public front door for a lab answers several of these the other way, and each step says which.

Before anything else, read The administrator interface. Everything below happens in the back end, and every step names a menu path through it.

The order

1. Take the site offline while you work.
2. Set the site identity — name, address, time zone, environment.
3. Make mail work, before anything that sends any.
4. Decide how people register.
5. Decide who can do what.
6. Turn off what the hub does not need.
7. Give the site a front page and a menu.
8. Schedule the recurring jobs.
9. Bring the site back online.

The order is not arbitrary. Each step either supplies something the next one needs, or closes a door the next one would leave open.

• Offline first (step 1), because every step below changes the site under anyone who is already looking at it.
• Identity before mail (steps 2 and 3). The confirmation mail signs itself <Site Name> Administrator and its subject begins with the site name, so the name you set in step 2 is how the hub introduces itself to a stranger in step 3.
• Mail before registration (steps 3 and 4). This is the one that costs people a weekend. New User Account Activation ships set to Self: the hub mails the new member a link, and the account does nothing until they click it. On a hub whose mail does not work the account is created anyway — the row is written before the mail is attempted — and then sits unactivated for ever. The member never gets the link, cannot sign in, and cannot tell you, because the hub's contact routes are mail too. If the send fails outright the form says so; if the machine accepts the mail and quietly drops it, nothing says anything at all. Prove mail works before you let anybody register.
• Registration before permissions (steps 4 and 5), because deciding what New User Registration Group should be is really a question about what that group is allowed to do.
• Permissions before pruning (steps 5 and 6), so that when you decide a component stays, you already know who will be allowed to use it.
• Content after the pruning (steps 7 and 8), because the front page and the scheduled jobs depend on which components survived step 6. There is no point building a menu item for a component you are about to disable, or scheduling a job for one.
• Online last (step 9), so the first thing a visitor sees is the finished arrangement rather than a half-configured one.

Steps 3, 4 and 5 are the ones that are hard to undo — not because the screens resist it, but because by the time the mistake shows, other people have accounts.

1. Take the site offline

Site > Global Configuration, Site tab, Offline Settings.

Field	Default
Site Offline	No
Offline Message	Use Custom Message
Custom Message	This site is down for maintenance. Please check back again soon.
Offline Image	empty

A new hub is online. Set Site Offline to Yes and the public front end returns the template's offline page with a 503 Service Temporarily Unavailable status:

			if ($this->app['config']->get('offline') && !User::authorise('core.login.offline'))
			{
				$file = 'offline';

				$response->headers->set('Status', '503 Service Temporarily Unavailable', 'true');
			}

Anyone holding core.login.offline still sees the real site. On a new hub that permission is granted to the Manager access group and inherited by Administrator below it; Super Users hold core.admin and are allowed everything. So you keep browsing while visitors get the notice. The administrator interface is not affected either way.

The 503 is the right status to send, and worth knowing about: it tells a search engine that the page is temporarily away and to come back, rather than that it has gone. A maintenance window does not cost the hub its listings.

This step is optional, and it is worth the two clicks only if the hub is already reachable from outside. Undo it in step 9.

2. Set the site identity

Site > Global Configuration, Site and Server tabs. See Global configuration for the whole screen.

The installer already asked for a site name, a time zone and an address, so this is a check rather than a first entry. Four fields matter now:

• Site Name — used in page titles, in mail subjects, and by any component that asks the hub what it is called.
• FQDN — the hub's fully qualified domain name.
• Server Time Zone, on the Server tab. Cron recurrences and every displayed date are read against it.
• Application Environment, on the Site tab. Set it to Production on the hub people use, and to anything else on a copy of it.

Two of those deserve more than a glance.

Site Name is not only a heading. Registration mail is sent from <Site Name> Administrator, and its subject line begins with the same name, so this is what a stranger sees in their inbox before they see the hub. Use the name the project uses in public, not the internal one. Changing it later is one field and breaks nothing, but the mail already sent keeps the old name.

Application Environment is not the error-detail switch, whatever the name suggests. That one is Debug System, on the System tab, and it ships No. What the environment setting does is gate the things that should only happen on the hub people use: the Google Analytics and Google Gtag modules render nothing unless the value starts with production, the Application Environment module shows a banner naming the environment when it does not, and super group repository provisioning runs only on production hubs. So the setting matters most on the copies. A staging clone left on Production reports its own traffic into the live hub's analytics, and a live hub left on Development records none of its own.

Global Configuration writes plain PHP files under app/config/. If the save reports that it could not write, fix the directory's permissions rather than hunting for the setting elsewhere.

3. Make mail work

Site > Global Configuration, Server tab, Mail Settings.

Almost nothing on a hub notifies anyone until this is right: account confirmation, password resets, group announcements, support tickets, every digest. There is no test-mail button anywhere in the interface, so the only way to know is to trigger something that sends — registering a throwaway account is the usual test, which is why this comes before step 4.

Mailer offers three choices: Sendmail, SMTP and Mandrill (SMTP). Set the Sendmail Path, or the SMTP host, port, security and credentials, to match the machine.

					case 'sendmail':
					case 'mail':
					case 'native':
						$dsn = "sendmail://default";
						break;

					case 'mandrill+smtp':

The value the installer writes into app/config/mail.php is mail, which is not one of the three options the drop-down offers. It behaves as Sendmail, as the code above shows, so the hub does send mail — but the field renders without a matching selection, and the first time you save Global Configuration it becomes a real Sendmail. Nothing breaks; do not be alarmed by the change.

From email does more than name the sender. It is also the address the hub notifies when an account is created — the new-account mail is addressed to the same address it is sent from. Point it at a mailbox somebody reads, not at a no-reply address. On the example hub that is a shared address the staff at all three institutions can open, not one person's inbox: members see it as <Site Name> Administrator and reply to it whether you meant them to or not, and a hub whose only administrative address belongs to someone who has moved on is a slow, expensive problem to unpick.

4. Decide how people register

Two screens, both in the Members component. Read Registration for both in full.

Users > Members, then Options in the toolbar, Component tab, holds the decisions:

Option	Default	What the default means
Allow User Registration	Yes	Anyone can create an account.
New User Account Activation	Self	The member gets a link by mail and activates the account themselves. Nobody reviews it.
New User Registration Group	Registered	New accounts land in the Registered access group.
Guest Access Group	Public	Visitors who are not signed in count as Public.
Notification Mail to Administrators	Yes	Nothing here. See the note below.
Send Password	Yes	Nothing. No code reads it.
Simple Registration	No	Nothing. No code reads it.

Three of those options do not do what the screen implies, and all three are recorded in docs/plan/review-findings.md:

• Send Password and Simple Registration are declared on the form and described in the help text, but nothing in the tree reads either value. Setting them changes nothing.
• Notification Mail to Administrators is read from the User - Hubzero plugin, not from the Members component, so the copy on this screen has no effect. The one that works is Notification Mail to Administrator under Extensions > Plug-in Manager, on the User - Hubzero plugin, and it also defaults to Yes. The mail it sends goes to the global From email — the same address it is sent from.

The default that surprises people is New User Account Activation. A new hub is open, and confirming an email address is all it takes to get an account — there is no approval queue. If your hub is for a named group of people, set it to Admin, which adds a review step before the account works, and set Email On Account Activation to Yes so the member is told when you approve them. If the hub is closed entirely, set Allow User Registration to No and create accounts yourself under Users > Members.

The example hub takes Admin. Forty named collaborators is not a number that needs a self-service front door, and an approval step is the only thing between the hub and whoever finds the form. A hub that wants to be a public front door leaves it on Self and spends the effort on Spam instead. Either way, decide it now: switching to Admin later leaves the accounts already created untouched, so the decision only ever applies going forward.

One more decision sits on a different tab of the same Options screen. The Defaults tab holds Default Privacy, which sets the viewing level stored on every new profile: Public, meaning anyone who finds the address can read the member's profile page, or Private, meaning nobody but the member can. It applies at the moment an account is created, so it decides what your members' pages look like to the outside without their ever choosing it.

Users > Members > Registration is the second screen: a grid of fields against the four moments a member's details are collected, each cell Required, Optional, Hide or Read only. Decide here whether you are asking for an organisation, a phone number, a reason for joining. It is easier to relax a required field later than to collect one you did not ask for at the start — the Update on Next Login column exists for exactly that repair, but it costs every existing member an interruption.

5. Decide who can do what

The single most useful thing to know about this section is that group means two unrelated things, and the screens for them sit next to each other on the Users menu. Users explains the split; read that before touching either screen.

A hub group is a community with pages, a forum, a wiki and an address at /groups/<alias>. Members join it. See Groups.

An access group is a permission bucket with no pages and no address. Nobody joins one; you put accounts in it. See Access Groups.

Eight access groups ship, nested:

Group	Parent
Public	—
Manager	Public
Administrator	Manager
Registered	Public
Author	Registered
Editor	Author
Publisher	Editor
Super Users	Public

The names carry no meaning of their own; what each may do is decided by the permission rules set against it in Global Configuration's Permissions tab and on each component's Options. The exceptions are Super Users, which holds core.admin and is therefore allowed everything, and Manager, which is where core.login.admin — the permission that lets an account into the back end at all — is granted on a new hub.

Three viewing levels ship as well: Public, Registered and Special. They answer "who may see this", and every content item carries one. See Access Levels.

For the first week:

1. Know where your own account sits. The one the installer created is in Super Users.
2. Put the people who will run the hub with you in Manager or Administrator, not in Super Users. Both reach the back end, and neither holds core.admin, so neither can open Global Configuration and rewrite the permission rules.
3. Leave the eight shipped groups in place. Deleting Public or Registered breaks the default viewing levels and the registration options. Add your own groups alongside them.

6. Turn off what the hub does not need

Extensions > Extension Manager, Hubzero Core tab. See Extension Manager.

A hub ships with nearly every component enabled — around sixty of them, from Answers to Wishlist — because the platform cannot know which ones a given hub is for. Every enabled component adds an entry to the Components menu, and most of them add something a visitor can reach. A hub that will never run courses, sell anything, or publish a newsletter is easier to administer, and easier to explain to its members, with those switched off.

This step is housekeeping rather than configuration, and a hub survives skipping it. Do it anyway, because both halves get more expensive later. Every component left on is one whose options you are answerable for and whose screens your members can find and start using; and a component switched off after they have started takes their content out of reach with it. Decided now, while nothing has been created, it costs nothing.

To see the real state, filter the list by Type = Component and sort or filter on Status; do not go by what a fresh database happens to contain, since installing with the optional sample content switches several extensions off that a plain install leaves on.

1. Filter to Component.
2. Tick the ones this hub will not use.
3. Select Disable.

Disabling a component removes it from the administrator menu as well as from the site. Nothing is deleted, and Enable puts it back.

Then set the options of the ones you kept: Components explains the Options pop-up and its Permissions tab, and every parameter of every component is listed in the generated configuration reference. Some components do nothing useful until their options are filled in.

Check the default, do not trust it

A component's default comes from two places that do not always agree. The manifest — the component's own config/config.xml — declares a default for every field, and that is the value the generated configuration reference prints. The shipped install data, core/bootstrap/Install/sql/mysql/data.sql, separately seeds a row of stored parameters for each component. The stored row wins, both for what the hub does and for what the Options screen shows you: the form is bound to the stored parameters and falls back to the manifest only for keys the row does not mention.

Two of those disagreements change what a hub does on its first day.

That one has a second switch, which is easy to miss. Each publication type carries its own Auto Approve? under Components > Publications > Master Types, and either switch being on is enough to publish without review. If the example hub's data release is meant to pass a curator, both have to say no.

The other disagreement is Default Privacy, in step 4 above.

The habit worth taking from this is small. When a setting matters, open the screen and read the value rather than reading a default anywhere — including in this book. A reference tells you what a field means and what its values are; only the screen tells you what your hub has.

7. Give the site a front page and a menu

Two separate jobs, and the second one catches everybody.

The front page

The site's home page is whichever menu item is marked Home. On a plain install that is a single item in Main Menu, of type Featured Articles.

So the first-week job is to replace it:

1. Write the page you want as an article — Content > Article Manager, New. See Content.
2. Menus > Main Menu, then New.
3. Set Menu Item Type to Articles > Single Article and pick the article.
4. Save it, then tick it in the list and select Home.

There must always be exactly one item marked Home; giving the flag to the new item takes it from the old one.

The menu

A menu is not displayed anywhere until a Menu module is pointed at it and given a template position. Creating the menu and creating the module that shows it are two separate steps, and the shipped module is in the wrong place:

• The site templates in this tree render the main navigation from the user3 position.
• The Main Menu module a plain install creates is assigned to position-7, which no template here declares or renders.

The result is a hub with a menu that appears nowhere. Installing the optional sample content moves the module to user3; a plain install does not, so check it yourself:

1. Extensions > Module Manager, open Main Menu.
2. Set Position to user3.
3. Confirm Status is Published, and Save & Close.

Then build the menu out. Menus covers the Menu Manager, the item types, and how to group items into sections; Modules covers the module side. The positions the site template offers are footer, banner, welcome, left, right, helppane, user3, notices, search, breadcrumbs and endpage.

8. Schedule the recurring jobs

Several features do nothing at all until a job runs: digests, group announcements, membership expiry, search indexing, DOI registration, cache cleanup. Read Scheduled tasks first — it explains the tick, the muse cron:jobs command and the IP whitelist — and use Cron as the catalogue of what each job does.

Two things have to be true.

The tick has to be installed. Unix cron does not run the hub's jobs; it calls the hub once a minute and the hub runs whatever is due. Until that entry exists in the system crontab, every job in the list sits there with a next-run time in the past.

The jobs have to exist. A new hub has three, and only one of them runs:

Job	Event	State
Group Announcements	groups / sendGroupAnnouncements, every 5 minutes	Published
Process Newsletter Mailings	newsletter / processMailings	Unpublished
Process Newsletter Opens & Click IP Addresses	newsletter / processIps	Unpublished

Everything else you create yourself, at Components > Cron > New. The Event drop-down is built from the enabled cron plugins, so an event you expect and cannot find usually means its plugin is disabled under Extensions > Plug-in Manager. Add the jobs for the features you kept in step 6 — there is no point scheduling a publications job on a hub that does not publish.

9. Bring the site back online

Site > Global Configuration, Site tab, Offline Settings. Set Site Offline back to No.

Then sign out and look at the front page the way a visitor will: the home page you built in step 7, the menu in a position the template renders, and — if the hub takes registrations — a way to reach the registration form. Checking this signed out matters, because signed in as a Super User you see the site whether it is offline or not.

Where to go next

• Integrations — analytics, Google Drive, the rich text editor, and CAPTCHA.
• Configuring — the rest of the global configuration, and the per-extension options.
• Daily maintenance — the work the hub needs once people are using it.
• Spam — worth reading before the hub is public, not after.

How a hub fits together

The mental model the rest of this book assumes. Every other chapter tells you which screen to open and which field to set; none of them tells you what the hub is doing underneath, so the first time a change you made in one screen appears — or fails to appear — somewhere else entirely, there is nothing to reason from. This chapter supplies that. It is short, and it is worth reading once before the screen-by-screen chapters rather than after.

It is for the person who has just been given a hub to run and has no background in the software. If you write code for a hub, read Application structure instead; it covers the same ground with the detail a developer needs.

The two halves

A hub is one application with two faces.

The front end is the site people visit: the home page, the groups, the resources, the search box. The administrator interface, or back end, is at /administrator and is where you configure all of that.

They are not two programs. They are the same installation, running the same components against the same database, with one difference: the first path segment of the URL. /administrator/… selects the administrator client, /api/… selects the REST API, and anything else is the site. The choice is made by ClientDetector on every request, and it decides which set of controllers, views, template and configuration the request runs against — admin/ instead of site/ inside each component.

That is why a component you disable vanishes from both the Components menu and the public site at once, and why there is no separate back-end address, host or port to remember.

The administrator interface covers reaching it, who is allowed in, and what each of its menus holds. Read that chapter for the back end itself; this one is about what the back end is editing.

How a page gets built

This is the single most useful thing to understand, because almost every "why did that happen?" question on a hub is answered by it.

A page is assembled in four stages:

1. The request arrives. One file, index.php, handles every URL on the hub. Nothing else is ever reached directly.
2. The router picks a component. It looks at the URL and decides which component owns it, and it sets two things: option, the component's name, and Itemid, the id of the menu item that matched. Remember Itemid; it matters in a moment.
3. The component produces the main content. Exactly one component runs per page. It reads the database, applies its own permissions, and returns the block of HTML that is the actual subject of the page — the article, the group's forum, the list of resources.
4. The template wraps it, and the modules fill in around it. The template is a page skeleton with named holes in it. One hole takes the component's output. The rest are positions, and each position renders whichever modules are published there.

Here is the middle of the shipped site template, which is the whole idea in one screenful — an optional column of modules, the component, another optional column of modules:

					<?php if ($this->countModules('left')) : ?>
							<aside class="aside">
								<jdoc:include type="modules" name="left" />
							</aside><!-- / .aside -->
					<?php endif; ?>
					<?php if ($this->countModules('left or right')) : ?>
							<div class="subject">
					<?php endif; ?>

								<!-- start component output -->
								<jdoc:include type="component" />
								<!-- end component output -->

					<?php if ($this->countModules('left or right')) : ?>
							</div><!-- / .subject -->
					<?php endif; ?>
					<?php if ($this->countModules('right')) : ?>
							<aside class="aside">
								<jdoc:include type="modules" name="right" />
							</aside><!-- / .aside -->
					<?php endif; ?>

Two consequences follow from that order, and between them they explain most of the surprises.

The component does not know about the modules, and the modules do not know about the component. They are chosen independently: the component by the router, the modules by their position and their page assignment. A page can therefore have perfect content and no navigation, which is exactly the failure described in step 7 of The first week with a new hub — a menu that exists, in a position no template renders, on a site whose pages are otherwise fine.

Modules are assigned to pages by menu item id. A module is shown if it is published, if its position is in the template, if the viewer's access level allows it, and if its page assignment includes the current Itemid. Modules set to appear on all pages carry no id at all and always render. So:

• A page reached without a menu item — a component URL a visitor typed, a deep link into a group — has no Itemid, and shows only the all-pages modules.
• Deleting a menu item and creating a replacement gives you a new id. Modules assigned to the old one are now assigned to a page that does not exist, and quietly stop appearing. If a sidebar disappears after a menu tidy-up, this is why. Edit menu items rather than replacing them.

Menus covers the menu side and Modules the module side; the point here is only that they are two halves of one decision.

A worked page

Take the front page a new hub gets in step 7 of The first week with a new hub: an article, shown by a menu item of type Articles > Single Article, marked Home.

A visitor asks for https://example.com/. The path is empty, so the router takes the menu item marked Home, and from it sets option=com_content and the article's id, plus that item's Itemid. The Content component loads the article, checks its state and its access level, and renders it. The template then puts that HTML in the component hole, renders the Main Menu module into user3, the breadcrumb module into breadcrumbs, and whatever else is published into footer and the rest, and sends the finished page.

Change the article's text and only stage 3 changes. Change which menu item is Home and stage 2 changes, which changes the Itemid, which changes which modules stage 4 renders. That is the whole mechanism.

Where things live

Two trees on disk, and one database.

Tree	What is in it
core/	The platform: the framework, and every component, module, plugin and template the release ships. An upgrade replaces this tree wholesale.
app/	This one hub: its configuration, its uploads, its cache and logs, and any extension it adds or replaces.

app/ wins. When the hub looks for a component, a module, a plugin or a template, it checks app/ first and uses core/ only if it finds nothing — so a hub customises itself by adding files under app/, never by editing core/. A change made in core/ works until the next upgrade and then disappears.

The database holds everything the administrator interface edits as records: articles, menu items, modules and their positions, members, access groups and levels, categories, component options, cron jobs, forum posts, group memberships. Almost every screen in this book writes there.

Files on disk hold everything else: uploaded and generated content under app/site/ — group files, media, member files, publications — plus the configuration in app/config/, and the cache and logs. The Media Manager writes into app/site/media. Global Configuration writes plain PHP files into app/config/.

Which of the two your actions touch is not academic, because it decides what a backup has to include:

• The database alone is not a backup. Restore it without app/site/ and every record survives pointing at a file that is gone.
• app/ alone is not a backup either. It has the uploads and the configuration but none of the content.
• core/ need not be backed up at all. It is the release, and you can fetch it again. It should also not have been modified; if it has, that is the thing to find out about before an upgrade, not after.

So: back up the database and app/, together, at the same moment. Daily maintenance covers the rest of the running-hub routine.

The four kinds of extension

Everything the hub puts on a page comes from an extension, and there are four kinds. Extensions explains each one properly, including where they live and which screen manages them; one line each here so the words mean something in the meantime:

• A component is an application. It owns the main body of the page, and exactly one runs per request.
• A module is a small block placed around the component, in a named position the template offers.
• A plugin answers events — a login, a save, a page about to render — and also supplies the tabbed sections of groups, member profiles and projects.
• A template is the page skeleton: the layout, the stylesheets, and the list of positions modules can go in.

The table prefix

Sooner or later something technical — a migration, a support answer, a configuration field, this documentation — shows you a table name written like this:

#__resources

#__ is not part of the name. It is a placeholder that the database layer rewrites into the hub's real table prefix on the way to the server, every time a query runs. On this tree the default prefix is jos_, so #__users becomes jos_users.

The prefix exists so that several hubs can share one database server, or one database, without their tables colliding. Because it is chosen per installation, no code may assume it. Extensions that need a table name build it from the configured value rather than typing it — the My Points module does exactly that, joining Config::get('dbprefix') to users_points. Code that hardcodes a literal prefix works on the hub it was written for and breaks on every hub that chose a different one, which is why you will see #__ and never a real prefix in anything shipped.

There is a Database Tables Prefix field in Global Configuration, on the Server tab. It is not a rename tool.

What you can break, and what you cannot

Most of what a new manager is nervous about is reversible, and a few things that look harmless are not. Nothing in the administrator interface tells you which is which, so this is the list, and it is the most useful page in the book to have read before you start clicking.

Nearly everything here follows from three questions. Ask them at any screen, including screens this book does not cover.

1. Does it change a value, or remove a row? Changing a value — a state, a position, an option, an access level — writes over one field and leaves the record where it is. Removing a row takes the record and, often, the files and child records hanging off it. The first kind is undone by doing it again. The second is undone only from a backup.
2. Has anything left the building? A change to the hub stays on the hub until you undo it. Mail does not. Neither does anything a member has already seen, downloaded or cited. There is no unsend.
3. Can the same screen put it back? If the screen that made the change offers the opposite of it, the change is cheap. If undoing it means editing a file, restoring a table, or asking somebody to re-upload their work, slow down and take the backup first.

Hard to break

• Disabling and unpublishing. Disabling a component or unpublishing a module deletes nothing. Enable and Publish put it back exactly as it was, options and all.
• Uninstalling a shipped extension. You cannot. There is no Uninstall button in the Extension Manager — it is commented out of the view. See Extension Manager.
• Changing an item's state. Publishing, unpublishing and the rest write a number into a column; the row stays where it is. Read States, deleting and check-out before assuming which number a given label means, because the labels and the stored values do not line up as neatly as the screens suggest.
• A record that will not open because it is "checked out". Nothing is wrong with it. Site → Maintenance → Global Check-in releases every locked record on the hub.
• Moving modules between positions. Free, and the fastest way to learn what a template's positions actually are: put a module somewhere and look.
• Categories. Creating them costs nothing, and they are scoped per component, so a category made for articles cannot disturb the knowledge base. See Categories.
• Clearing the cache. Site → Maintenance → Clear Cache removes stored cache groups and Purge Expired Cache drops the expired ones. Both throw away derived data the hub regenerates on demand. Neither touches content, and the worst outcome is a slow first page.
• Global Configuration itself. It writes plain PHP files under app/config/, one per group of settings. Whatever you save there can be read and corrected in a text editor, so a bad save is never a locked door — you do not need the interface to get back into the interface.
• Deleting an access group you belong to. The screen refuses, skips that row and says so; it also refuses to let an account without core.admin delete a group that holds it. You cannot remove your own way in with that button.

Easy to break

• Editing anything under core/. It works until the next upgrade, then vanishes without warning. Put the change under app/ instead.
• Changing the table prefix, as above.
• Deleting the shipped access groups. Public and Registered are referenced by the default viewing levels and the registration options. Delete your own groups freely; leave the eight shipped ones in place. See Access groups.
• Deleting menu items. Cheap to do, and it silently strips the module assignments that pointed at them, as above.
• Leaving the hub with no item marked Home. There must be exactly one, because it is what the router falls back to for the bare address.
• Real deletions. Removing a member, a group or a file is not a state change. It is gone, and only the backup you took in the section above will bring it back.
• Deleting a hub group. The worst of those, because the button is on an ordinary list screen and gives no hint of its reach. Deleting a group fires groups.onGroupDelete at every group plugin, so the forum, the wiki, the blog, the collections, the resources and the wishlist each remove their own material before the group row goes. What is left afterwards is a log entry recording the members and the description. Unpublish the group instead if what you want is for it to stop being visible. See Groups.
• Saving a component's Options without changing anything. The save writes every field on the form, not only the ones you touched: values that were merely defaults become stored values, and any stored parameter the form does not declare is dropped. Usually harmless, occasionally not — Media's Path to Files Folder and Path to Images Folder default to images in the manifest while the code reads site/media, so opening that screen and saving it untouched points the Media Manager at a directory that does not exist. Recorded in docs/plan/review-findings.md.
• Mass Mail Users. Users > Mass Mail Users sends to every account in the access group you pick, and the hub reports how many it reached. Nothing reverses that. Send to a group of one first.

The honest summary: you can explore the administrator interface freely as long as you are toggling states and positions, and you should slow down at three kinds of button — one that deletes something, one that sends something, and one that changes where the hub looks for its data. Everything else on these screens is a stored value that the same screen will change back.

None of that is a reason to be timid with the rest. A manager who is afraid of the interface leaves the hub misconfigured, which is a slower and more certain kind of damage than any of the accidents above. Take the backup, then go and look.

Where to go next

• The administrator interface — the back end itself, menu by menu.
• The first week with a new hub — the ordered path through the decisions a new hub needs.
• Extensions — the four kinds, in full.
• Application structure — the same picture with the code paths, for readers who want the detail.

The administrator interface

The administrator interface, or back end, is where you set up, configure and maintain a hub. It runs on the same site as the public front end but under a separate URL, uses a different template, and is closed to anyone without an explicit permission to enter it.

Reaching it

Add /administrator to the hub's address. If the hub is at https://example.com, the back end is at:

https://example.com/administrator

That first path segment is what selects the administrator application; there is no separate hostname or port. Everything after it is an ordinary index.php?option=com_… request handled by the same components as the front end, only with their admin/ controllers and views instead of their site/ ones.

Logging in

Every administrator URL is rewritten to the login component until you are both logged in and authorised, so it does not matter which back-end page you ask for first — you always land on the login screen:

	if (\User::isGuest() || !\User::authorise('core.login.admin'))
	{
		$option = 'com_login';
	}

	if (empty($option))
	{
		if (strtoupper(\App::get('request')->method()) == 'POST')
		{
			$option = \App::get('request')->getCmd('option', '', 'post');
		}
	}

	if (empty($option))
	{
		$option = 'com_cpanel';
	}

The check is the core.login.admin permission, not simply "is logged in". A member who is signed in to the front end and browses to /administrator is still sent to the login screen if their access groups do not carry that permission. On a fresh install core.login.admin is granted to the Manager group and inherited by Administrator beneath it; Super Users hold core.admin, which grants everything. See Access groups for how to change that.

The login screen itself is com_login, rendered through the admin template's login.php layout with the Login Form module (mod_adminlogin) in it. What you see depends on which authentication plugins the hub has enabled with their Admin login option turned on:

• With no such plugin, you get a plain form: Username, Password, and a Log in button.
• With one or more, you get a Sign in with … button for each, plus a link back to the plain form for hub-local accounts.

A successful login lands you on the Control Panel.

The layout

Every back-end page is built from the same pieces, in this order down the page:

Region	What is in it
Header	The hub's name, linking to the front end, and the Log out link on the right
Main navigation	The top-level menus, rendered by the admin menu module in the menu position
Toolbar box	The page title on the left and its action buttons — New, Save, Save & Close, Close, Options, Help — on the right
Sub-navigation	The current component's own screens, when it registers any
Content	The component itself

The toolbar is where the verbs live. A list screen puts New, Edit, Delete and the status buttons there; an edit screen replaces them with Save, Save & Close and Close. A component's Options button opens its configuration in a modal, and the Permissions tab inside that modal is where you say which access groups may use it.

The Control Panel

The Control Panel is the component com_cpanel, and it is the default screen for any administrator URL that names no component. It has no content of its own: it renders every administrator module published in the cpanel position, one collapsible panel per module. What your dashboard shows therefore depends entirely on which modules the hub publishes there. Daily maintenance describes the panels a working hub usually adds.

The menus

The main navigation is assembled by the admin menu module. Most of it is hardcoded, and each entry is shown only if you hold the permission it needs, so a Manager sees fewer entries than a Super User.

Menu	Contains
Site	Control Panel, Global Configuration, a Maintenance submenu (Global Check-in, Clear Cache, Purge Expired Cache, LDAP, Geo DB, APC, Routes), System Information, and Logout
Users	Members, Groups, Access Groups, Access Levels, User Notes and their categories, and Mass Mail Users
Menus	Menu Manager, then one entry per menu defined on the hub
Content	Article Manager, Category Manager, and Media Manager
Components	One entry per installed, enabled component, with a submenu where the component defines one
Extensions	Extension Manager, Module Manager, Plug-in Manager, Template Manager, Language Manager
Help	Help Articles and links out to hubzero.org; the menu module's Help Menu option, on by default, hides it

The Components menu is the one that grows. Unlike the rest, it is built from the database — the administrator menu rows installed with each component — rather than from the module's own code, which is why installing a component adds it to that menu without any further step. Members, Groups and System are deliberately left out of it because they already appear under Site and Users.

Logging out

Click Log out in the top-right corner of the header, or use Site → Logout. Either returns you to the login screen.

While you have an item open for editing, the whole main navigation and the Log out link are disabled: the record is checked out to you, and the interface hides the links so you cannot navigate away and leave it locked. Finish with Save & Close or Close to release it, and the links come back.

Where to go next

• Advanced setup — the site template, menus and modules.
• Configuring — the global configuration and the per-extension options.
• Users — members, access groups, and access levels.
• Daily maintenance — the work a running hub needs every day.