Before any editing in the PCUG wordpress site,
please review the editing procedure:
Summary of Procedures for Actioning Website Updates
nb. these procedures apply to all except editorial changes to existing page content, which may be actioned immediately.
- To obtain approval, requests be emailed to the website list for discussion.
- The request then be approved by majority of the Subcommittee + Executive,
- The Website Admin Sub-committee + Executive decide on who will action the change.
- The change is first trialed on the test site – www.pcug.org.au/wptest/ to check for any issues, before being implemented on the main site.
These procedures and rationale are expanded on the website office index at
http://www.pcug.org.au/wp/administration/web-site-office
1.Existing pages
Please don’t delete (‘Trash’) or substantially rewrite existing pages without consulting with the previous editors/authors of those pages. However, please do correct spelling mistakes and other typos, fix grammar errors, and carry out minor editing to improve layout and readability.
To check on changes made : Under ‘Edit Page’, scroll to the ‘Revisions’ section at the bottom, and click on any linked revision. On the next page, select the revisions to compare, and click ‘Compare Revisions’ for a side-by-side, colour-coded ‘diff’. (JB)
2. Documents, Brochures and Forms
Where possible, documents, forms and brochures are uploaded by ftp to an area external to the wordpress website, and linked to the external link from within the site. This area is http://www.pcug.org.au/documents
These documents are given a generic name, so that if a document version is updated, all the links in wordpress will stay the same.
Note that all main templates of documents (including their editable version) are located in the Committee Secure Documents area viewable at
https://www.pcug.org.au/committee
(Information added by KA20130919)
3. Information on TIP
Don’t duplicate information that is already available on the TIP wiki, and thereby break an important information management principle. If the information is left as-is, then when (not if) for example, the TIP account types or plans are changed, these pages will need to be rewritten/updated. Please, let’s just point people to the TIP website/wiki, and if we do feel the need to have those pages, let’s make the content high-level and point the reader to the relevant TIP page for details (e.g. “The Internet Project (TIP) offers a variety of broadband and dialup accounts to meet members Internet needs. For details see [TIP URL] …”). (JB)
4. Contact Method
Contact method – email address vs contact form? We should limit the use of email addresses on the publicly accessible (vs member-only) pages to avoid harvesting by spammers. Instead we should use contact forms (e.g. as used on the ‘Contact Us’ page) configured to deliver email messages behind the scenes. Conversely, on member-only pages (which are only accessible via TIP username and password), we should have no qualms about using standard email addresses (as shown on the ‘Committee Details’ page). What we should avoid is the use of the largely ineffective (against spammers) and probably very annoying (for legitimate correspondents) format of ‘username[at]pcug[dot]org[dot]au’. (JB)
For now, change those email addresses eg. on the SIGs and Volunteers pages to use a mailto: URL, eg. “mailto:jsaxon@pcug.org.au” but we should revisit this before we go live with a new site. (JB)
5. Correct insertion of email addresses
With the editor in Visual mode enter (or select) the email address, eg : pcug@pcug.org.au. Highlight this address with your mouse, and click on the ‘Link’ (chain) icon on the top row of the editor – a window will pop up. In the ‘Link URL’ box, delete the ‘http://‘ prefix if it’s there, and type in ‘mailto:’ (without quotes) followed by the email address. Leave the Target/Title/Class as is, and click ‘Insert’. Click ‘Preview Changes’ and you’ll see it’s now rendered as a clickable email address on the web page. To see the underlying HTML that is used, click the ‘HTML’ tab in the editor. (JB)
6. Security
We need to keep things simple and use a common, consistent way of protecting web-pages. I’ve previously installed a Page Security plugin,
which controls access by administrator-defined groups. So for example access to the ‘Members-Only’ page (and sub-pages) is restricted to
registered users, and since the only people who can log in must provide a TIP username and password, this means that “registered users” is
synonymous with “PCUG members”. Secondly, I’ve defined a ‘Committee’ group, and set the ‘Committee-Only’ pages (and sub-pages) to be
accessible only to those in the ‘Committee’ group. If we need further groups, they can easily be added.
For reference, to protect a page so that it’s only accessible by members, I would recommend you make it a sub-page under the
‘Members-Only’ page, and to make a page accessible only by Committee members, make it a sub-page under the ‘Committee-only’ page. You can do
this by setting the relevant Parent page in the Page Attributes section under Edit Page, or you should be able to do it by dragging and dropping
the page using the ‘Pages Tree View’ sub-menu on the left hand side of Edit Page.
I would avoid the use of password-protecting individual pages – it’s cumbersome when you people have to start remembering different passwords
for different pages, and after a while there are invariably people who no longer require access or passwords become known to those who
shouldn’t have access, so you need to change the password and distribute the new one. IMHO, it’s easier to manage access by defining groups, and
the advantage is that our members will only need to remember one password – their main TIP/PCUG password.
There is one “gotcha” with all forms of WordPress page security that the Committee (and any other restricted-by-group pages) needs to be aware
of, and that is that all pages (and posts) are accessible by those with ‘Editor’ or ‘Administrator’ privileges. So for example the ‘Committee-only’ pages are accessible to both Paul and myself, even though we’re not part of the ‘Committee’ group. (JB)
Appointed honorary Committee members by Secretary on 20101227. (NB)
Notes on Certain Tasks
Moving Pages in the Menu Structure
I suggest you use the Atahualpa Pages Tree View structure that I think comes with Atahualpa itself. The pages tree view is available on the dashboard.
Select expanded view to show all pages, and you can add new pages (tap on a page in the structure to obtain a list of options), or tap and drag and drop pages Ad nauseam. Hide any pages you don’t want to be listed in the menu structure by checking the “don’t show this page in menu” box (or whatever it’s called) in editing view.
Pages normally inherit the security settings of a parent page so all pages under say “Committee only” – provided they are not explicitly made public or made to inherit from another area – will require the same login as for the parent page.
The Pages Tree View can also be accessed in the Dashboard under the Pages heading. I presume this refers to the same structure. If not, that would explain a lot.
There is another more cumbersome but arguably more robust way to set the structure but it is a bit hard to describe in words. (LB from NB email 7/12)