You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having all the docs (both the manual and the site) in a repo would allow people to send in PRs and would make it possible to automate things.
If PEAR support is eventually dropped, http://phptal.org/latest.tar.gz would not longer have to be updated. For the time being, this would constitute a commit/PR for each new release. (If that becomes too cumbersome the process could be automated in a build step).
The text was updated successfully, but these errors were encountered:
Keep in mind that it requires xmlto, probably a bunch of symlinks to docs, and paths to be just like on my machine ;)
Also for syntax highlighting I've been using an experimental DOM-based branch of PHPTAL.
Final question before work on this can commence... We basically have 2 ways we could go about this...
Keep (as much as possible of) the original implementation
Convert to Jekyll/GH-Pages
The main advantages of converting would be that it's easier for people to contribute to the content (not sure how important this use-case is) and that there is a clearer separation between data and presentation. A lot (all?) of the build logic could also be dropped in favour of the build done by GH-Pages. The main disadvantage is that knowledge of Ruby/Jekyll/GH-Pages is needed when working on non-trivial functionality.
The advantage of keeping the implementation is that the problem domain stays within the realm of PHP (and make) so no extra knowledge is needed. The disadvantages that I see are that there is more logic to maintain and that an extra build/deploy step is needed to produce static HTML to host.
Do you have preference/opinions either way? Also @Ocramius, thoughts? (Abbreviated/ a few word is fine).