mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-06-26 06:29:24 +02:00
DOCS Make links relative so they work nicely on github and docs site.
This commit is contained in:
Cam Findlay
parent
453e12d1a7
commit
606d5667cf
|
|
@ -154,7 +154,7 @@ Two other important folders to set the permissions on are `assets` and `silverst
|
|||
|
||||
You will need to give **Modify** permission to **IUSR** user. To do it right click the folder and choose **Properties**. Then open the security tab, press **Edit** and add the **IUSR** user to the list by clicking the **Add** button. Afterwards tick **Modify** under **Allow** for that user. Repeat these steps for each folder.
|
||||
|
||||
|
||||
|
||||
|
||||
## Install SilverStripe
|
||||
|
||||
|
|
|
|||
|
|
@ -40,11 +40,11 @@ a beta version of the software)
|
|||
|
||||
## Screenshots
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Example Forum:
|
|||
| `forum/code` | PHP code for model and controller (subdirectories are optional) |
|
||||
| ... | ... |
|
||||
|
||||
|
||||
|
||||
|
||||
### Module documentation
|
||||
|
||||
|
|
|
|||
|
|
@ -46,13 +46,13 @@ When designing your site you should only need to modify the *mysite*, *themes* a
|
|||
|
||||
### User Interface Basics
|
||||
|
||||
|
||||
|
||||
|
||||
The CMS is the area in which you can manage your site content. You can access the cms at http://localhost/your_site_name/admin (or http://yourdomain.com/admin if you are using your own domain name). You
|
||||
will be presented with a login screen. Login using the details you provided at installation. After logging in you
|
||||
should see the CMS interface with a list of the pages currently on your website (the site tree). Here you can add, delete and reorganize pages. If you need to delete, publish, or unpublish a page, first check "multi-selection" at the top. You will then be able to perform actions on any checked files using the "Actions" dropdown. Clicking on a page will open it in the page editing interface pictured below (we've entered some test content).
|
||||
|
||||
|
||||
|
||||
|
||||
1. This menu allows you to move between different sections of the CMS. There are four core sections - "Pages", "Files", "Users" and "Settings". If you have modules installed, they may have their own sections here. In this tutorial we will be focusing on the "Pages" section.
|
||||
2. The breadcrumbs on the left will show you a direct path to the page you are currently looking at. You can use this path to navigate up through a page's hierarchy. On the left there are tabs you may use to flick between different aspects of a page. By default, you should be shown three tabs: "Content", "Settings", and "History".
|
||||
|
|
@ -60,11 +60,11 @@ should see the CMS interface with a list of the pages currently on your website
|
|||
* Settings - Here you set the type of page behavior, parent page, show in search, show in menu, and who can view or edit the page.
|
||||
* History - This allows you to view previous version of your page, compare, change, and revert to previous version if need be.
|
||||
3. Within the "Pages" section (provided you are in the "Content" or "Settings" tab) you can quickly move between pages in the CMS using the site tree. To collapse and expand this sidebar, click the arrow at the bottom. If you are in the history tab, you will notice the site tree has been replaced by a list of the alterations to the current page.
|
||||
|
||||
|
||||
4. This section allows you to edit the content for the currently selected page, as well as changing other properties of the page such as the page name and URL. The content editor has full [WYSIWYG](http://en.wikipedia.org/wiki/WYSIWYG) capabilities, allowing you to change formatting and insert links, images, and tables.
|
||||
5. These buttons allow you to save your changes to the draft copy, publish your draft copy, unpublish from the live website, or remove a page from the draft website. The SilverStripe CMS workflow stores two copies of a page, a draft and a published copy. By having separate draft and published copies, we can preview draft changes on the site before publishing them to the live website. You can quickly preview your draft pages without leaving the CMS by clicking the "Preview" button.
|
||||
|
||||
|
||||
|
||||
|
||||
### Try it
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ To create a new page, click the "Add New" button above the site tree.
|
|||
When you create a new page, you are given the option of setting the structure of the page ("Top level" or "Under another page") and the page type.
|
||||
The page type specifies the templates used to render the page, the fields that are able to be edited in the CMS, and page specific behavior. We will explain page types in more depth as we progress; for now, make all pages of the type "Page".
|
||||
|
||||
|
||||
|
||||
|
||||
**SilverStripe's friendly URLs**
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ page in the database.
|
|||
|
||||
Note that if you have sub-pages, changing the Top level URL field for a page will affect the URL for all sub-pages. For example, if we changed the URL field "/about-us/" to "/about-silverstripe/" then the sub-pages URLs would now be "/about-silverstripe/URL-of-subpage/" rather than "/about-us/URL-of-subpage/".
|
||||
|
||||
|
||||
|
||||
|
||||
When you create a new page, SilverStripe automatically creates an appropriate URL for it. For example, *About Us* will
|
||||
become *about-us*. You are able to change it yourself so that you can make long titles more usable or descriptive. For
|
||||
|
|
@ -182,7 +182,7 @@ Then, using a loop over the page control *Menu(1)*, we add a link to the list fo
|
|||
|
||||
This creates the navigation at the top of the page:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -219,7 +219,7 @@ You can also create the pages elsewhere on the site tree, and drag and drop the
|
|||
|
||||
Either way, your site tree should now look something like this:
|
||||
|
||||
|
||||
|
||||
|
||||
Great, we now have a hierarchical site structure! Let's look at how this is created and displayed in our template.
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ to get the top level page title. In this case, we merely use it to check the exi
|
|||
|
||||
Both the top menu, and the sidebar menu should be updating and highlighting as you move from page to page. They will also mirror changes done in the SilverStripe CMS, such as renaming pages or moving them around.
|
||||
|
||||
|
||||
|
||||
|
||||
Feel free to experiment with the if and loop statements. For example, you could create a drop down style menu from the top navigation using a combination of if statements, loops, and some CSS to style it.
|
||||
|
||||
|
|
@ -358,7 +358,7 @@ After building the database, we can change the page type of the homepage in the
|
|||
|
||||
In the CMS, navigate to the "Home" page and switch to the "Settings" tab. Change "Page type" to *Home Page*, and click "Save & Publish".
|
||||
|
||||
|
||||
|
||||
|
||||
Our homepage is now of the page type *HomePage*. Regardless, it is still
|
||||
rendered with the *Page* template. SilverStripe does this as our homepage inherits its type from *Page*,
|
||||
|
|
@ -390,14 +390,14 @@ We'll also replace the title text with an image. Find this line:
|
|||
Your Home page should now look like this:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
SilverStripe first searches for a template in the *themes/simple/templates* folder. Since there is no *HomePage.ss*,
|
||||
it will use the *Page.ss* for both *Page* and *HomePage* page types. When it comes across the *$Layout* tag, it will
|
||||
then descend into the *themes/simple/templates/Layout* folder, and will use *Page.ss* for the *Page* page type, and
|
||||
*HomePage.ss* for the *HomePage* page type. So while you could create a HomePage.ss in the *themes/simple/templates/* it is better to reuse the navigation and footer common to both our Home page and the rest of the pages on our website.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
|
|
|||
|
|
@ -14,12 +14,12 @@ We are going to work on adding two new sections to the site we built in the firs
|
|||
|
||||
The first of these new sections will be *News*, with a recent news listing on the homepage and an RSS feed:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The second will be a *Staff* section, to demonstrate more complex database structures (such as associating an image with each staff member):
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ Creating a new page type requires creating each of these three elements. We will
|
|||
A more in-depth introduction of Model-View-Controller can be found
|
||||
[here](http://www.slash7.com/articles/2005/02/22/mvc-the-most-vexing-conundrum).
|
||||
|
||||
|
||||
|
||||
|
||||
## Creating the news section page types
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ Finally, we return the fields to the CMS. If we flush the cache (by adding ?flus
|
|||
|
||||
Now that we have created our page types, let's add some content. Go into the CMS and create an *ArticleHolder* page named "News", then create a few *ArticlePage*'s within it.
|
||||
|
||||
|
||||
|
||||
|
||||
## Modifing the date field
|
||||
|
||||
|
|
@ -269,13 +269,13 @@ To access the new fields, we use *$Date* and *$Author*. In fact, all template va
|
|||
spread across several tables in the database matched by id - e.g. *Content* is in the *SiteTree* table, and *Date* and
|
||||
*Author* are in the *ArticlePage* table. SilverStripe matches this data, and collates it into a single data object.
|
||||
|
||||
|
||||
|
||||
|
||||
Rather than using *$Date* directly, we use *$Date.Nice*. If we look in the `[api:Date]` documentation, we can see
|
||||
that the *Nice* function returns the date in *dd/mm/yyyy* format, rather than the *yyyy-mm-dd* format stored in the
|
||||
database.
|
||||
|
||||
|
||||
|
||||
|
||||
###ArticleHolder Template
|
||||
We'll now create a template for the article holder. We want our news section to show a list of news items, each with a summary and a link to the main article (our Article Page).
|
||||
|
|
@ -303,12 +303,12 @@ We'll now create a template for the article holder. We want our news section to
|
|||
|
||||
Here we use the page control *Children*. As the name suggests, this control allows you to iterate over the children of a page. In this case, the children are our news articles. The *$Link* variable will give the address of the article which we can use to create a link, and the *FirstParagraph* function of the `[api:HTMLText]` field gives us a nice summary of the article. The function strips all tags from the paragraph extracted.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Using include files in templates
|
||||
|
||||
We can make our templates more modular and easier to maintain by separating commonly-used components in to *include files*. We are already familiar with the `<% include Sidebar %>` line from looking at the menu in the [first tutorial (Building a basic site)](/tutorials/building_a_basic_site).
|
||||
We can make our templates more modular and easier to maintain by separating commonly-used components in to *include files*. We are already familiar with the `<% include Sidebar %>` line from looking at the menu in the [first tutorial (Building a basic site)](../tutorials/building_a_basic_site).
|
||||
|
||||
We'll separate the display of linked articles as we want to reuse this code later on.
|
||||
|
||||
|
|
@ -351,7 +351,7 @@ And this one to the *HomePage* class:
|
|||
|
||||
This will change the icons for the pages in the CMS.
|
||||
|
||||
|
||||
|
||||
|
||||
<div class="hint" markdown="1">
|
||||
Note: The `news-file` icon may not exist in a default SilverStripe installation. Try adding your own image or choosing a different one from the `treeicons` collection.
|
||||
|
|
@ -388,7 +388,7 @@ When SilverStripe comes across a variable or page control it doesn't recognize,
|
|||
|
||||
The controller for a page is only created when page is actually visited, while the data object is available when the page is referenced in other pages, e.g. by page controls. A good rule of thumb is to put all functions specific to the page currently being viewed in the controller; only if a function needs to be used in another page should you put it in the data object.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -413,7 +413,7 @@ This function creates an RSS feed of all the news articles, and outputs it to th
|
|||
|
||||
Depending on your browser, you should see something like the picture below. If your browser doesn't support RSS, you will most likely see the XML output instead. For more on RSS, see `[api:RSSFeed]`
|
||||
|
||||
|
||||
|
||||
|
||||
Now all we need is to let the user know that our RSS feed exists. Add this function to *ArticleHolder_Controller*:
|
||||
|
||||
|
|
@ -480,12 +480,12 @@ We then add an `[api:UploadField]` in the *getCMSFields* function to the tab "Ro
|
|||
the *addFieldToTab* function will create it for us. The *UploadField* allows us to select an image or upload a new one in
|
||||
the CMS.
|
||||
|
||||
|
||||
|
||||
|
||||
Rebuild the database ([http://localhost/your_site_name/dev/build](http://localhost/your_site_name/dev/build)) and open the CMS. Create
|
||||
a new *StaffHolder* called "Staff", and create some *StaffPage*s in it.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Creating the staff section templates
|
||||
|
|
@ -518,7 +518,7 @@ This template is very similar to the *ArticleHolder* template. The *SetWidth* me
|
|||
will resize the image before sending it to the browser. The resized image is cached, so the server doesn't have to
|
||||
resize the image every time the page is viewed.
|
||||
|
||||
|
||||
|
||||
|
||||
The *StaffPage* template is also very straight forward.
|
||||
|
||||
|
|
@ -539,7 +539,7 @@ The *StaffPage* template is also very straight forward.
|
|||
Here we use the *SetWidth* method to get a different sized image from the same source image. You should now have
|
||||
a complete staff section.
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Instead of using a custom coded form, we could use the [userforms module](http:/
|
|||
|
||||
We will create a poll on the home page that asks the user their favourite web browser, and displays a bar graph of the results.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Creating the form
|
||||
|
|
@ -171,7 +171,7 @@ Add the following code to the existing `form.css` file:
|
|||
|
||||
All going according to plan, if you visit [http://localhost/your_site_name/home/?flush=1](http://localhost/your_site_name/home/?flush=1) it should look something like this:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Processing the form
|
||||
|
|
@ -232,7 +232,7 @@ Change the end of the 'BrowserPollForm' function so it looks like this:
|
|||
|
||||
If we then open the homepage and attempt to submit the form without filling in the required fields errors should appear.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Showing the poll results
|
||||
|
|
@ -356,7 +356,7 @@ and the poll results need to be displayed.
|
|||
|
||||
We use the normal tactic of putting the data into an unordered list and using CSS to style it, except here we use inline styles to display a bar that is sized proportionate to the number of votes the browser has received. You should now have a complete poll.
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ This is a short tutorial demonstrating how to add search functionality to a Silv
|
|||
|
||||
We are going to add a search box on the top of the page. When a user types something in the box, they are taken to a results page.
|
||||
|
||||
|
||||
|
||||
|
||||
## Creating the search form
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ To add the search form, we can add `$SearchForm` anywhere in our templates. In t
|
|||
|
||||
This displays as:
|
||||
|
||||
|
||||
|
||||
|
||||
## Showing the results
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ class.
|
|||
Then finally add ?flush=1 to the URL and you should see the new template.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -170,17 +170,17 @@ We call `setDisplayFields()` directly on the component responsible for their ren
|
|||
using the `[ModelAdmin](reference/modeladmin)` interface instead.
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
Select each `Project` page you have created before,
|
||||
go in the tab panel called "Students", and add all students as required,
|
||||
by clicking on the link **Add Student** of your *GridField* table.
|
||||
|
||||
|
||||
|
||||
|
||||
Once you have added all the students, and selected their projects, it should look a little like this:
|
||||
|
||||
|
||||
|
||||
|
||||
### Many-many relationships: Mentor
|
||||
|
||||
|
|
@ -250,13 +250,13 @@ In the CMS, open one of your `Project` pages and select the "Mentors" tab.
|
|||
Add all the mentors listed [above](#what-are-we-working-towards)
|
||||
by clicking on the **Add Mentor** button.
|
||||
|
||||
|
||||
|
||||
|
||||
To associate the mentor with a project, select one of the mentors, and click on the projects tab. Add all the projects a mentor is associated with (see the [list](/tutorials/dataobject_relationship_management#What_are_we_working_towards?)), by typing the name in "Find Projects by Page name" and clicking the "Link Existing" button.
|
||||
You will notice that you are able to select the same `Project` for multiple mentors.
|
||||
This is the definition of a **many-to-many** relation.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Website Display
|
||||
|
|
@ -276,7 +276,7 @@ accessing a "has-many" and "many-many" relationship
|
|||
in the template loops: to the template, it's just
|
||||
a named list of object.
|
||||
|
||||
|
||||
|
||||
|
||||
**themes/simple/templates/Layout/ProjectsHolder.ss**
|
||||
|
||||
|
|
@ -334,7 +334,7 @@ Creating the detail view for each `Project` page works in a very similar way.
|
|||
Given that we're in the context of a single project,
|
||||
we can access the "Students" and "Mentors" relationships directly in the template.
|
||||
|
||||
|
||||
|
||||
|
||||
**themes/simple/templates/Layout/Project.ss**
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ the Site Configuration panel (http://yoursite.com/admin/settings)
|
|||
A `theme` within SilverStripe is simply a collection of templates and other front end assets such as javascript and css.
|
||||
located within the `themes` directory.
|
||||
|
||||
|
||||
|
||||
|
||||
## Submitting your theme to SilverStripe
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ The reason it's standard practice to name the form function 'Form' is so that we
|
|||
|
||||
If you now create a ContactPage in the CMS (making sure you have rebuilt the database and flushed the templates /dev/build?flush=all) and visit the page, you will now see a contact form.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Now that we have a contact form, we need some way of collecting the data submitted. We do this by creating a function on the controller with the same name as the form action. In this case, we create the function 'submit' on the ContactPage_Controller class.
|
||||
|
|
|
|||
|
|
@ -21,19 +21,19 @@ All files, images and folders in the 'assets' directory are stored in the databa
|
|||
|
||||
If you have the CMS module installed, you can manage files, folders and images in the "Files" section of the CMS. Inside this section, you will see a list of files and folders like below:
|
||||
|
||||
|
||||
|
||||
|
||||
You can click on any file to edit it, or click on any folder to open it. To delete a file or a folder, simply click the red 'X' symbol next to it. If you click to open a folder, you can go back up one level by clicking the 'up' arrow above the folder name (highlighted below):
|
||||
|
||||
|
||||
|
||||
|
||||
Once you click to edit a file, you will see a form similar to the one below, in which you can edit the file's title, filename, owner, or even change which folder the file is located in:
|
||||
|
||||
|
||||
|
||||
|
||||
You may also notice the 'Sync files' button (highlighted below). This button allows CMS users to 'synchronise' the database (remember, all files/folders are stored as database records) with the filesystem. This is particularly useful if someone has uploaded or removed files/folders via FTP, for example.
|
||||
|
||||
|
||||
|
||||
|
||||
## Upload
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ example, the tab panels have be applied in the CMS form before the form itself i
|
|||
avoid incorrect dimensions.
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
## Layout API
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ code like this:
|
|||
...
|
||||
|
||||
By applying the proper style sheet, the snippet html above could produce the look of:
|
||||
|
||||
|
||||
|
||||
SiteTree is a `[api:DataObject]` which is versioned by `[api:Versioned]` extension.
|
||||
Each node can optionally have publication status flags, e.g. "Removed from draft".
|
||||
|
|
@ -76,6 +76,6 @@ __Example: using a subclass__
|
|||
|
||||
The above subclass of `[api:SiteTree]` will add a new flag for indicating its
|
||||
__'Scheduled To Publish'__ status. The look of the page node will be changed
|
||||
from  to . The getStatusFlags has an `updateStatusFlags()`
|
||||
from  to . The getStatusFlags has an `updateStatusFlags()`
|
||||
extension point, so the flags can be modified through `DataExtension` rather than
|
||||
inheritance as well. Deleting existing flags works by simply unsetting the array key.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ summary: Creating your own custom data or content reports.
|
|||
Reports are a useful feature in the CMS designed to provide a view of your data or content. You can access
|
||||
the site reports by clicking *Reports* in the left hand side bar and selecting the report you wish to view.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Default reports
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ Special attention will need to be given to custom sections on a case-by-case bas
|
|||
As we have changed the design of the CMS, the top bar for your custom sections is no longer needed. We've moved the
|
||||
buttons that it once held down to the bottom.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Classes added to 2.2 that may conflict
|
||||
|
|
|
|||
|
|
@ -403,8 +403,8 @@ We have also moved all fields from the "Metadata" tab into the "Main Content" ta
|
|||
$fields->addFieldToTab('Root.Main', $myField);
|
||||
$fields->addFieldToTab('Root.Main', $myOtherField);
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The old paths are rewritten automatically, but will be deprecated in the next point release.
|
||||
If you are working with tab objects directly in your `FieldSet`, you'll need to update
|
||||
|
|
@ -421,7 +421,7 @@ to reduce UI clutter. You still need to address it through the usual tabset meth
|
|||
as the underlying object structure doesn't change. Once you add more tabs,
|
||||
e.g. to the "Root.Main" tab in `SiteTree`, the tab bar automatically shows.
|
||||
|
||||
|
||||
|
||||
|
||||
### New `SiteTree::$description` field to describe purpose of a page type [sitetree-description]###
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user