docrootCMS is a django application for developers who build, manage and maintain websites. This app takes the simplicity of working with a PHP docroot, the fun of working with Python and fully leverages the power of Django for adding website application functionality.
I have evaluated and worked with many CMS's during my lifetime. Vignette, Documentum, Wordpress, Sitecore, Apostrophy, DjangoCMS etc. I always wondered why there were so many. The short answer is that there is no one solution that fits every case. Even with all the solutions I have worked with, none of them were designed to help developers; every one was designed to eliminate the developer and allow non-technical people to maintain and develop website pages. There is nothing wrong with this if you need it, however, there are significant trade-offs. Responsive design, SEO, speed, efficiency, complexity and flexibility. I wanted a CMS that helps me do my job more efficiently and easily.
First, and foremost docrootCMS is a Django application and can use any django features. Django is an outstanding framework for writing web applications. I wanted to leverage it as much as possible. However, anyone who has used django to develop and maintain a website knows that a couple of the frameworks features do not extend well to websites. Lets review the basic Django framework and discuss how docrootCMS differs. The basic Django framework to render a web page is to define application urls in urls.py and map each url to a view. The view performs logic and, in most cases, renders a template using data placed in a context. Templates are identified by defining the template directories in settings.py and separating them from static files, also defined in the application settings file.
docrootCMS uses the more traditional webserver rules much like PHP for defining urls and delivering pages
-- urls.py not required
The Django framework works great for an application and allows developers to know where to start in order to trace down a problem, however, creating urls and views for every page on your website quickly grows out of control and becomes extremely difficult to maintain.
From the very beginning, webservers have used directories and files to accomplish this same task. A specific directory (known as the docroot or document root) is defined and is accessed by the root slash. Every other directory becomes a path and all files are sent to the browser as pages. docrootCMS allows developers to place files and directories inside of the document root (docroot/files/) instead of having to define them in urls.py.
docrootCMS combines static files and dynamic templates much like PHP
-- combined static files
Many times, Developing a website requires explicit control on where static files are placed relative to the pages. For example, if you buy a theme from themes.getbootstrap.com you have to place css files in /css not /static/css/ or things will not work without you having to do a lot of modifications to the authors code; this is a maintenance nightmare.
While you can still use the static template tag and include static files you can also use static files placed in the docroot without any additional template tags. The developer has a choice. However, much like PHP, since templates and static files are mixed you must use an extension to identify templates. docrootCMS uses .dt to identify a file as a Django template.
docrootCMS dynamically injects context from a data.py file if found
-- views.py not required
Regardless if you use function based views or class based views having a view definition for each page becomes very difficult to follow and maintain.
By following a simple rule you can inject a data context into a template. If you create a page like index.dt and then create an index.data.py file, the data from the data file will be injected into the template for you. This is much simpler to maintain since the data file always lives in the same location as the template with the same name.
docrootCMS is designed for helping developers and being very efficient.
- docroot can support static files as well as dynamic files using runserver
- .dt pages are Django templates and support inheritance
- .data.py data files are injected into the context for the .dt template before rendering
- .data.py can be used for simple ajax REST web service calls
- content people can use Markdown Posts for dynamic blog content
- in-page editing by non-technical people
- REST Web Services management and reporting
uArchive is a simple command line archival bash shell script. It can be run in one of 2 modes. By default, if no environment variable is set, files are archived with a time date stamp in the current folder. You can only archive files. If an environment variable UARCHIVE_HOME is set, however, additional features are available which can be very useful.
I commonly administrate linux and osx machines. I created this simple archive script to help me backup and restore changes. The overall vision is to have the ability to archive files to a common location and back those up in a private repository. If used properly, restoring a server can be to clone the private repo for the server and then issue a command to restore all files on a blank system.
-- without UARCHIVE_HOME environment variable set
- able to backup a file to the local directory with a timestamp extension
cp foo.txt.20200321 foo.txt
-- with UARCHIVE_HOME environment variable set
- able to back up any file or directory of files to a centralized folder
- able to archive a "current" copy of the file/directory you would like to restore later easily
- able to restore a "current" copy of a file; archives the current one and replaces
- able to restore all current files back to server in one command
NOTE: install instructions can be found on code page
Database Web Services Application - Expose database results as REST web services without any coding
-- Why another project?
What this product is not; nor probably ever will be
What this product is
This application is a way for a presentation developer to quickly configure JSON return data without any back-end coding effort. In a production environment, it supports packaging data for migration between environments. Lastly, this product is designed with performance in mind. Every effort was made to eliminate any additional object creation or destruction. It simply takes simple SQL queries and directly converts the results to simple JSON strings. The goal is to get the results as close as possible to a direct database call. My long term vision is that this product would meet the need of developers, small and even some medium size sites for REST access to database data.
- define MySQL and PostgreSQL connections in django via normal DATABASES settings
- define endpoint urls and SQL to execute based on method in Django admin
- override method via parameter
- supports path parameters in endpoint url
- all sql is executed as prepared statements for security
- supports callable statement return arguments and results for mysqlclient driver only
- supports an optional trailing sql based on parameter
NOTE: install instructions can be found on code page