@@ -64,13 +64,13 @@ And for the "Goodbye" page::
6464 $response->send();
6565
6666We have indeed moved most of the shared code into a central place, but it does
67- not feel like a good abstraction, doesn't it? First, we still have the
68- `` send() `` method in all pages, then our pages do not look like templates, and
69- we are still not able to test this code properly.
67+ not feel like a good abstraction, does it? We still have the `` send() `` method
68+ for all pages, our pages do not look like templates, and we are still not able
69+ to test this code properly.
7070
7171Moreover, adding a new page means that we need to create a new PHP script,
7272which name is exposed to the end user via the URL
73- (``http://example.com /bye.php ``): there is a direct mapping between the PHP
73+ (``http://127.0.0.1:4321 /bye.php ``): there is a direct mapping between the PHP
7474script name and the client URL. This is because the dispatching of the request
7575is done by the web server directly. It might be a good idea to move this
7676dispatching to our code for better flexibility. This can be easily achieved by
@@ -127,18 +127,17 @@ we return a custom 404 page; you are now in control of your website.
127127
128128To access a page, you must now use the ``front.php `` script:
129129
130- * ``http://example.com /front.php/hello?name=Fabien ``
130+ * ``http://127.0.0.1:4321 /front.php/hello?name=Fabien ``
131131
132- * ``http://example.com /front.php/bye ``
132+ * ``http://127.0.0.1:4321 /front.php/bye ``
133133
134134``/hello `` and ``/bye `` are the page *path*s.
135135
136136.. tip ::
137137
138- Most web servers like Apache or nginx are able to rewrite the incoming
139- URLs and remove the front controller script so that your users will be
140- able to type ``http://example.com/hello?name=Fabien ``, which looks much
141- better.
138+ Most web servers like Apache or nginx are able to rewrite the incoming URLs
139+ and remove the front controller script so that your users will be able to
140+ type ``http://127.0.0.1:4321/hello?name=Fabien ``, which looks much better.
142141
143142The trick is the usage of the ``Request::getPathInfo() `` method which returns
144143the path of the Request by removing the front controller script name including
@@ -152,8 +151,8 @@ its sub-directories (only if needed -- see above tip).
152151 argument is the URL path you want to simulate.
153152
154153Now that the web server always access the same script (``front.php ``) for all
155- our pages, we can secure our code further by moving all other PHP files
156- outside the web root directory:
154+ pages, we can secure the code further by moving all other PHP files outside the
155+ web root directory:
157156
158157.. code-block :: text
159158
@@ -170,14 +169,21 @@ outside the web root directory:
170169 Now, configure your web server root directory to point to ``web/ `` and all
171170other files won't be accessible from the client anymore.
172171
172+ To test your changes in a browser (``http://localhost:4321/?name=Fabien ``), run
173+ the PHP built-in server:
174+
175+ .. code-block :: sh
176+
177+ $ php -S 127.0.0.1:4321 -t web/ web/front.php
178+
173179 .. note ::
174180
175181 For this new structure to work, you will have to adjust some paths in
176182 various PHP files; the changes are left as an exercise for the reader.
177183
178184The last thing that is repeated in each page is the call to ``setContent() ``.
179- We can convert all pages to "templates" by just echoing the content and
180- calling the ``setContent() `` directly from the front controller script::
185+ We can convert all pages to "templates" by just echoing the content and calling
186+ the ``setContent() `` directly from the front controller script::
181187
182188 <?php
183189
0 commit comments