The code does not use an SQL database (although it can I am not sure I want it to), so it is fairly heavy on the file system (as is an SQL database). Every post and comment is stored as a separate file, and some meta data too are stored in files, but every Operating System is optimized for reading and writing files.
Changes will occur in the data format so I am hesitant to document it. Taken as a whole the data is a combination hierarchical, relational, document-oriented database. But the API is designed for change. The goofy "Object Oriented like" library interface I described? I will just replace one library with a new one that adheres to it when making changes, or simply add another library to extend operation (although there are a limited amount of letters).
Currently, posts are stored in meta/psts/ as numbered files; other directories are for pages, post comments, and post meta data for categories and tags. FTP or cPanel can be used for basic site administration.
Record Format
Both posts and comments are stored in a standard format: newline delimited headers followed by a newline, followed by the data. Such a format has two very good features. Easy to parse, amenable to additions. (This is as near to non-encoded as data can be.) Example:
I have seen it written that templates cannot be implemented in Bash. Well, "The impossible takes a little longer," someone once said. But it actually did not take me all that long to create a true web template API of about 100 lines.
First, there exists global site data such as this:
bash code
sitebase=${SCRIPT_NAME%/*}
sitehost="http://$HTTP_HOST$REQUEST_URI"
sitedesc="Syntagmatic Personal Publishing Platform"
sitename="WordBash"
sitetitle="The first WordBash site"
A basic template, which comes from a file, is like this:
It is to display the HTML with the variable references replaced by the actual data during run-time. Doing so takes what is known as an "engine". Why? It generally takes a lot of code to do it. A lot of code.
This post addresses Bash performance by demonstrating code to accomplish three things:
stripping HTML
decoding POST data
simple post markup
I think you will find it enlightening (well, I did).
Stripping HTML Tags
Stripping tags is straight forward and uses a single state flag:
bash code
# strip tags
st(){
n=${#data}
t=0
r=
for((i=0; i<$n; i++ )); do
if[[${data:$i:1} == ">"]]; thent=0; continue; fi
if[[$t == 1]]; thencontinue; fi
if[[${data:$i:1} == "<"]]; thent=1; continue; fi
r+=${data:$i:1}
done
data=$r
}
That, though, only demonstrates that expanding a string one character at a time is slow. Sometimes case is used for parsing data, so let's give it a try:
WordBash development has been paused. I just wanted to demonstrate that a web application like a blog can be created as a shell script.
WordBash is not finished. At this stage, WordBash is what I call proven concept. Since you are seeing and interacting with software that is almost identical to WordPress, I consider this proof that WordBash is a working web application. However, not all WordPress features are implemented.
The current Object Oriented approach, as I have implemented it, is as valid as any "real" paradigm (and in fact shows that "real" classes and objects can just add bloat and why I am calling WordBash non-paradigm code), and that may not change much, but WordBash will end up with architectural changes if I continue development.
WordBash has had only about eight months of development—with several months of gaps—and there are bound to be one or two things wrong that could completely mess things up. I wrote this code to learn Bash.
Many of modern programming's fancy methodologies and paradigms can be implemented in shell script. So too can they be implemented in machine language, as that is in reality all that exists anyway (if you heard this from me first, you should not have heard this from me first).
Except that, as I am trying to demonstrate with WordBash, these methodologies and paradigms are not always necessary.
