The process can be hard to follow because many signals get called.

The following is an attempt in helping you (developers) find your way better in the Snap! environment.

1. snap.cgi gets called by Apache
2. snap.cgi connects to snapserver
3. snap.cgi sends the Apache parameters to snapserver
4. snapserver creates a snap_child object
5. snap_child verifies the data sent by snap.cgi
6. snap_child loads the plugins
7. snap_child calls the execute() signal
8. path plugin responds by checking that the path is valid:
   1. Page is in Cassandra: get the path::primary_owner as the plugin to handle the page
   2. Page is NOT in Cassandra: send the can_handle_dynamic_path() signal to see whether a module can handle that page (i.e. see char_chart for a simple example of dynamic paths.)
   3. If the page is not owned by a plugin, generate a 404 immediately
   4. Page is own, verify that the current user has permission with the snap_child::verify_permissions() function and the validate_action() signal
   5. Permission plugin receives the validate_action() signal
   6. Permission plugin sends the access_allowed() signal (through the server) to signal all the plugins and let them decide whether the page is accessible
   7. Permission plugin implements the signal as void permissions::on_access_allowed() and that implementation checks the default permissions; other plugins are expected to forbid access to a page based on other criteria; for example the login page is not accessible to a user until the user logs out
9. path plugin calls on_path_execute() on the plugin that owns that page
10. (by default, assuming that page is owned by "content") content::on_path_execute() is called and produces the HTML output by calling the layout apply_layout() function
11. layout generates an internal (all in memory) XML document that will include all the data used to generate the page
12. the layout then give all plugins a chance to tweak the XML header metadata with the generate_header_content() signal
13. at this point the owner plugin calls on_generate_main_content()
14. (plugin dependent) the plugin generates the body of the page (and eventually changes other parameters such as the title if it is expected to generate a dynamic title); this is done in the XML document
15. (not yet available, working on it as I write this!) the layout generates the XML code for all the boxes (rectangles of data generally at the top, sides, and bottom of the page)
16. on return, the layout process calls generate_page_content() which allows other plugins to tweak the content that the plugin just generated and add yet other parameters to the XML document
17. at this point, the layout checks for filters to be applied on the page (not fully implemented yet) and run those filters against the XML data
18. Now we run the XSLT of the current theme against that data; the output is still XML only the body is now fully formed
19. To finish up the page, the layout calls the apply_theme() function which generates the HTML (at this time we are limited to HTML, later we'll also support Text and PDF and probaly other formats. This will be defined by the XSLT document.)
20. At that point we return all the way up to the snap_child that checks the output buffer, if the buffer is empty, it considered that the page was not found and it generates a 404
21. If the snap_child buffer is not empty, it generates a 200 and outputs the HTML back to the snap.cgi which in turn sends it to Apache which in turn sends it to the client