mirror of
https://github.com/silverstripe/silverstripe-framework
synced 2024-06-15 17:21:50 +02:00
MINOR Fixing image links in docs/en/tutorials/
This commit is contained in:
Ingo Schommer
parent
b1c36ce0a4
commit
66bc92892e
|
|
@ -14,7 +14,7 @@ We are going to create a site in which all the content can be edited in the Silv
|
|||
navigation system, which will be generated on the fly to include all pages you add in the CMS. We will use two different
|
||||
templates - one for the home page, and one for the rest of the site.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Installation
|
||||
|
|
@ -50,7 +50,7 @@ The CMS is the area in which you can manage your site content. You can access th
|
|||
will be presented with a login screen. You can login with the details you provided at installation. After logging in you
|
||||
should be greeted with the CMS, pictured below (we've entered some test content).
|
||||
|
||||
|
||||
|
||||
|
||||
1. These buttons allow you to move between the different sections in the CMS. There are three core sections in the CMS - Site Content, Files & Images and Security. Modules may have their own sections here as well, if any are installed. In this tutorial we will be focusing on the Site Content section.
|
||||
2. All the pages in the site are laid out in the site tree. You can add, delete and reorganize the pages using the buttons at the top. Clicking on a page will open it in the editor on the right.
|
||||
|
|
@ -71,7 +71,7 @@ specifies the templates used to render the page, the fields that are able to be
|
|||
behavior. We will explain page types in more depth as we progress; for now, make all pages of the type "Page".
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**SilverStripe's virtual URLs**
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ While you are on the draft or live SilverStripe site, you may notice the URLs po
|
|||
http://localhost/contact. SilverStripe uses the URL field on the Meta-Data tab of the editor to look up the appropriate
|
||||
page in the database.
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
|
@ -111,7 +111,7 @@ your site's content in the CMS.
|
|||
*$SilverStripeNavigator* inserts the HTML for the navigator at the bottom of the page, which allows you to move
|
||||
quickly between the CMS and the draft and published version of your page.
|
||||
|
||||
|
||||
|
||||
|
||||
**Flushing the cache**
|
||||
|
||||
|
|
@ -159,7 +159,7 @@ Add *$MetaTags* to the head so that it looks like this:
|
|||
|
||||
Your page should now look something like this (with your own content of course):
|
||||
|
||||
|
||||
|
||||
|
||||
## Making a Navigation System
|
||||
|
||||
|
|
@ -182,7 +182,7 @@ Then, using a control block over the page control *Menu(1)*, we add a link to th
|
|||
|
||||
All going to plan, your page should look like this:
|
||||
|
||||
|
||||
|
||||
|
||||
The menu isn't really very useful until each button links to the relevant page. We can get the link for the menu item in
|
||||
question by using the *$Link* template variable.
|
||||
|
|
@ -216,7 +216,7 @@ Change the list item line in *Page.ss* so it looks like this:
|
|||
|
||||
You should now have a fully functional top menu
|
||||
|
||||
|
||||
|
||||
|
||||
## Adding a second level
|
||||
|
||||
|
|
@ -227,7 +227,7 @@ Select "About Us", and create two new pages "What we do" and "Our History" of th
|
|||
|
||||
Either way, your site tree should now look something like this:
|
||||
|
||||
|
||||
|
||||
|
||||
Great, we now have a hierarchical site structure, but we still have no way of getting to these second level pages.
|
||||
Adding a second level menu is very similar to adding the first level menu.
|
||||
|
|
@ -290,7 +290,7 @@ We now have a fully functioning two level navigation system. Both menus should b
|
|||
from page to page. They will also mirror changes done in the SilverStripe CMS, such as renaming pages or moving them
|
||||
around.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -344,7 +344,7 @@ After building the database, we can change the page type of the homepage in the
|
|||
|
||||
Under the "Behaviour" tab. Change it to *HomePage*, and click "Save Draft" and "Publish".
|
||||
|
||||
|
||||
|
||||
|
||||
Our homepage is now of the page type *HomePage*. However, even though it is of the *HomePage* page type, it is still
|
||||
rendered with the *Page* template. SilverStripe still renders the homepage using the *Page* template because when we
|
||||
|
|
@ -364,7 +364,7 @@ First, remove the breadcrumbs and the secondary menu; we don't need them for the
|
|||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Using a subtemplate
|
||||
|
||||
|
|
@ -457,7 +457,7 @@ it will use the *Page.ss* for both *Page* and *HomePage* page types. When it com
|
|||
then descend into the *themes/tutorial/templates/Layout* folder, and will use *Page.ss* for the *Page* page type, and
|
||||
*HomePage.ss* for the *HomePage* page type.
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
@ -477,4 +477,4 @@ things.
|
|||
* [Official book on SilverStripe in English](http://www.silverstripe.org/silverstripe-book).
|
||||
* [Official book on SilverStripe in German](http://www.silverstripe.org/das-silverstripe-buch).
|
||||
|
||||
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ Throughout this tutorial we are going to work on adding two new sections to the
|
|||
first is a news section, with a recent news listing on the homepage and an RSS feed. The second is a staff section,
|
||||
which demonstrates more complex database structures by associating an image with each staff member.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ the database, which fields can be edited in the CMS, and can use code to make ou
|
|||
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
|
||||
|
||||
|
|
@ -213,7 +213,7 @@ to edit the fields in the CMS.
|
|||
Now that we have created our page types, let's add some content. Go into the CMS and create an *ArticleHolder* page
|
||||
named "News", and create some *ArticlePage*s inside it.
|
||||
|
||||
|
||||
|
||||
|
||||
## Modifing the date field
|
||||
|
||||
|
|
@ -313,13 +313,13 @@ spread across several tables in the database matched by id - e.g. *Content* is i
|
|||
*Author* are in the *Article* table. SilverStripe matches these records by their ids and collates them into the 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.
|
||||
|
||||
|
||||
|
||||
|
||||
Now we'll create a template for the article holder: we want our news section to show a list of news items, each with a
|
||||
summary.
|
||||
|
|
@ -344,7 +344,7 @@ page, which in this case is our news articles. The *$Link* variable will give th
|
|||
use to create a link, and the *FirstParagraph* function of the `[api:HTMLText]` field gives us a nice summary of the
|
||||
article.
|
||||
|
||||
|
||||
|
||||
|
||||
Remember that the visual styles are not part of the CMS, they are defined in the tutorial CSS file.
|
||||
|
||||
|
|
@ -422,7 +422,7 @@ This will change the icons for the pages in the CMS.
|
|||
> Note: that the corresponding filename to the path given for $icon will end with **-file.gif**,
|
||||
> e.g. when you specify **news** above, the filename will be **news-file.gif**.
|
||||
|
||||
|
||||
|
||||
|
||||
### Allowing comments on news articles
|
||||
|
||||
|
|
@ -430,7 +430,7 @@ A handy feature built into SilverStripe is the ability for guests to your site t
|
|||
this on for an article simply by ticking the box in the behaviour tab of a page in the CMS. Enable this for all your
|
||||
*ArticlePage*s.
|
||||
|
||||
|
||||
|
||||
|
||||
We then need to include *$PageComments* in our template, which will insert the comment form as well as all comments left
|
||||
on the page.
|
||||
|
|
@ -448,7 +448,7 @@ on the page.
|
|||
|
||||
You should also prepare the *Page* template in the same manner, so comments can be enabled at a later point on any page.
|
||||
|
||||
|
||||
|
||||
|
||||
It would be nice to have comments on for all articles by default. We can do this with the *$defaults* array. Add this to
|
||||
the *ArticlePage* class:
|
||||
|
|
@ -507,7 +507,7 @@ page is referenced in other pages, e.g. by page controls. A good rule of thumb i
|
|||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -532,7 +532,7 @@ that name on the controller if it exists.
|
|||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
Now all we need is to let the user know that our RSS feed exists. The `[api:RSSFeed]` in your controller, it will be
|
||||
called when the page is requested. Add this function to *ArticleHolder_Controller*:
|
||||
|
|
@ -548,7 +548,7 @@ This automatically generates a link-tag in the header of our template. The *init
|
|||
class to ensure any initialization the parent would have done if we hadn't overridden the *init* function is still
|
||||
called. In Firefox you can see the RSS feed link in the address bar:
|
||||
|
||||
|
||||
|
||||
|
||||
## Adding a staff section
|
||||
|
||||
|
|
@ -614,12 +614,12 @@ We then add an *ImageField* in the *getCMSFields* function to the tab "Root.Cont
|
|||
the *addFieldToTab* function will create it for us. The *ImageField* allows us to select an image or upload a new one in
|
||||
the CMS.
|
||||
|
||||
|
||||
|
||||
|
||||
Rebuild the database ([http://localhost/dev/build?flush=1](http://localhost/dev/build?flush=1)) and open the CMS. Create
|
||||
a new *StaffHolder* called "Staff" in the "About Us" section, and create some *StaffPage*s in it.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -654,7 +654,7 @@ This template is very similar to the *ArticleHolder* template. The *FirstSentenc
|
|||
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.
|
||||
|
||||
|
|
@ -677,7 +677,7 @@ The *StaffPage* template is also very straight forward.
|
|||
Here we also use the *SetWidth* function to get a different sized image from the same source image. You should now have
|
||||
a complete staff section.
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ A UserDefinedForm is much quicker to implement, but lacks the flexibility of a c
|
|||
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
|
||||
|
|
@ -168,7 +168,7 @@ Add the following code to the form style sheet:
|
|||
This CSS code will ensure that the form is formatted and positioned correctly. All going according to plan, if you visit
|
||||
[http://localhost/home?flush=1](http://localhost/home?flush=1) it should look something like below.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Processing the form
|
||||
|
|
@ -249,7 +249,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 an error will be
|
||||
shown.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -406,7 +406,7 @@ We use the normal tactic of putting the data into an unordered list and using CS
|
|||
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
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ search-file.gif).
|
|||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ We then just need to add the search form to the template. Add *$SearchForm* to t
|
|||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Showing the results
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ class.
|
|||
Then finally add ?flush=1 to the URL and you should see the new template.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Summary
|
||||
|
|
|
|||
|
|
@ -163,7 +163,7 @@ Now that we have created our *Project* page type and *Student* data object, let
|
|||
Go into the CMS and create one *Project* page for each project listed [above](#what-are-we-working-towards) under a
|
||||
*ProjectsHolder* page named **GSOC Projects** for instance.
|
||||
|
||||
|
||||
|
||||
|
||||
As you can see in the tab panel *Student*, the adding functionality is titled *Add Student*. However, if you want to
|
||||
modify this title, you have to add this code in the *getCMSFields* method of the *Project* class :
|
||||
|
|
@ -176,7 +176,7 @@ Select now one of the *Project* page that you have created, go in the tab panel
|
|||
listed [above](#what-are-we-working-towards) by clicking on the link **Add A Student** of your
|
||||
*HasOneComplexTableField* table.
|
||||
|
||||
|
||||
|
||||
|
||||
After having added all the students, you will see that, in the tab panel *Student* of all the *Project* pages, the
|
||||
*HasOneComplexTableField* tables have the same content.
|
||||
|
|
@ -184,7 +184,7 @@ After having added all the students, you will see that, in the tab panel *Studen
|
|||
For each *Project* page, you can now affect **one and only one** student to it ( see the
|
||||
[list](#What_are_we_working_towards?) ).
|
||||
|
||||
|
||||
|
||||
|
||||
You will also notice, that you have the possibility to **unselect** a student which will make your *Project* page
|
||||
without any student affected to it.
|
||||
|
|
@ -321,12 +321,12 @@ Now that we have created our *Mentor* page type, go into the CMS and create one
|
|||
[above](#what-are-we-working-towards) under a simple *Page* named
|
||||
**Mentors** for instance.
|
||||
|
||||
|
||||
|
||||
|
||||
For each *Mentor* page, you can now affect **many** students created previously ( see the
|
||||
[list](#What_are_we_working_towards?) ) by going in the tab panel *Students*.
|
||||
|
||||
|
||||
|
||||
|
||||
You will also notice, that by checking a student in a *Mentor* page, you will be unable to select him again in any other
|
||||
*Mentor* page which is the definition of a **1-to-many** relation.
|
||||
|
|
@ -432,13 +432,13 @@ Select now one of the *Project* page, go in the tab panel *Modules* and add all
|
|||
[above](#what-are-we-working-towards) by clicking on the link **Add A
|
||||
Module** of your *ManyManyComplexTableField* table.
|
||||
|
||||
|
||||
|
||||
|
||||
For each *Project* page, you can now affect **many** modules created previously ( see the
|
||||
[list](#What_are_we_working_towards?) ) by going in the tab panel
|
||||
*Modules*.
|
||||
|
||||
|
||||
|
||||
|
||||
You will also notice, that you are able to select several times a *Module* on different *Project* pages which is the
|
||||
definition of a **many-to-many** relation.
|
||||
|
|
@ -464,7 +464,7 @@ For every kind of *Page* or *DataObject*, you can access to their relations than
|
|||
Let's start with the *ProjectsHolder* page created before. For this template, we are will display the same table than
|
||||
[above](#what-are-we-working-towards).
|
||||
|
||||
|
||||
|
||||
|
||||
*tutorial/templates/Layout/ProjectsHolder.ss*
|
||||
|
||||
|
|
@ -562,7 +562,7 @@ We know now how to easily access and show [relations](../topics/datamodel#relati
|
|||
|
||||
We can now do the same for every *Project* page by creating its own template.
|
||||
|
||||
|
||||
|
||||
|
||||
*tutorial/templates/Layout/Project.ss*
|
||||
|
||||
|
|
@ -699,7 +699,7 @@ In this template, we are gonna try to access the *Project* details from a *Stude
|
|||
What we want to do is to access to the *Project* page in the same way than we have done for the other relations
|
||||
**without modifying the relations between *Page* and *DataObject* and the database structure**.
|
||||
|
||||
|
||||
|
||||
|
||||
To do so, we have to create a function in the *Student* class which will return the *Project* linked with it. Let's call
|
||||
it *MyProject* for instance.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user