One Paragraph of project description goes here
These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.
<data> | |
<datasource> | |
<section handle="test-section">Test Section</section> | |
<entry> | |
<page-path handle="about">/about</page-path> | |
<page-title handle="about">About</page-title> | |
<title handle="about-this-company">About This Company</title> | |
<template> | |
<item id="2" handle="content" section-handle="page-templates" section-name="Page Templates">Content</item> | |
</template> |
In this first iteration, unauthenticated users should be able to test xslt code, save snippets and eventually come back to edit them without signing up. xpathr will work without javascript enabled, so client side code shouldn't be taken in consideration for now.
UI:
Written based on hacking away at a custom event which aimed to take its data solely from entry data and $_SESSION values, and not posted values (which I understand may have been open to DOM hacking and required "ugly" frontend hidden fields).
I was traversing the XMLElement object generated by SymQL (or Entry object generated by EntryManager) with the object's methods and foreach
to get values, which seems to require a lot of effort and code:
php
I'm describing my workflow in these articles, before I start my next Symphony project. Mostly for myself, to iron out my recurring problems, it is based on solid git techniques, taking heed of advice learned from Symphony community members, many many tips on the web, and flicking through the pages of O'Reilly's Version Control with git.
The core aim of this article, is to get a good Symphony development and deployment environment using git as the basis for the organisation, and have it written down for reference.
This workflow can be applied to any project, in theory, that has a starting point being a private remote git repo.