Manual.pod 3.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778
  1. =head1 tCMS Manual
  2. =head2 First time setup
  3. Run these makefile targets:
  4. make depend
  5. make install
  6. From there, running tCMS is pretty simple:
  7. starman --enable-ssl --ssl-key $MY_KEY_PATH --ssl-cert $MY_CERT_PATH www/server.psgi
  8. The application expects to run from the repository root.
  9. The first time you open the application, you will be presented with a first-time page that tells you to load /login.
  10. You will note that the submission button says 'Register' rather than 'Login'.
  11. The first user which logs in will be set up as the administrator, and all further users must be made by them via the /post/about route.
  12. You will want to do the following to make your user public:
  13. =over 4
  14. =item Create a user via the /post/about route using the name you just registered as. This will require you to re-set your password.
  15. =item Ensure the 'public' visibility is chosen when submitting the form.
  16. =back
  17. =head2 Application Structure
  18. server.psgi is a very straightforward application router which serves requests based on routing modules.
  19. There are 3 routing modules you will need to know about:
  20. =over 4
  21. =item L<Trog::Routes::HTML> - Render various pages which (mostly) output text/html
  22. =item L<Trog::Routes::JSON> - Implement various application/json output routes
  23. =item Themed B<Routes> - Inside of any given theme in themes/ there will be a Routes.pm module defining custom routes for your theme.
  24. =back
  25. From there the routes are generally going to call out to the data model, which is configured via the /config route.
  26. The configuration module is L<Trog::Config>.
  27. The Data model modules are all subclasses of L<Trog::Data>.
  28. We include a bogus data model for testing called 'DUMMY' which should not be used for production purposes.
  29. It is useful as an example for developers: L<Trog::Data::DUMMY>
  30. Authentication is accomplished via a cookie (tcmslogin) which we check against an sqlite database, config/auth.db
  31. Passwords are hashed and salted, and the only other thing stored there is what ACLs users have.
  32. The module controlling this is L<Trog::Auth>.
  33. =head2 Theming
  34. Themes are subdirectories of /themes, which mirror the structure of www/ internally.
  35. Stylesheets are included after the mainline ones, so that your styles will override the default.
  36. =head3 Theme Icons
  37. You will want your theme icon to be in the img/icon directory, make sure it's an SVG named 'favicon.svg'.
  38. From there, run bin/favicon_mongler.pl $PATH_TO_YOUR_FAVICON_SVG
  39. =head2 Renderers
  40. Each routing module calls out to the appropriate rendering modules (based on content-type) to build output based on the templates either in www/templates or in your theme's templates/ dir.
  41. This templates dir is further subdivided by content-type.
  42. =head3 Components, Forms, Footers and Headers
  43. Within that we have a components subdirectory for UI components intended to be included within other templates.
  44. The idea is that these are not dynamic, but can be statically compiled to strings for faster template builds.
  45. Things like emoji pickers, modals and other stuff you might populate later with an XHR are good candidates for being a component.
  46. Each component will have it's own module encapsulating it in the Trog::Component namespace.
  47. They must have a render() method which returns a string processed by Trog::Renderer->render().