Snap! Websites
An Open Source CMS System in C++
It is expected that you use a firewall to prevent all connections to your webserver except those on port 80 and 443 and any other port that Apache would answer.
Any other port could cause issues and you are responsible for them.
The Snap Server, if given permission, will be capable to deal with iptables to block users that are detected as flooding the server and not slowing down when asked to.
At this point we intend to only support Apache as a webserver. One thing about this server, it is used by many and is known to be quite safe to use as a ...
The system process including all the steps I can think of at the moment.
Assuming you give the Snap! server permissions, it blocks IP addresses that misbehave with your firewall. Misbehavior is detected as spam posts, fast hits, or unwanted accesses.
Start the Apache server, check whether it is better (faster) to run Apache and have all special features (redirects and such) in the snap.cgi (i.e. dynamic) or in Apache (i.e. but that last option requires a reload of Apache every now and then!)
See whether we gain anything in having a static cache. The problem ...
We are finding more and more projects that help with HTML 5. Although we're not right now looking into supporting HTML 5 directly, we keep an eye open to new technology, especially if it can help us get a better feel for our sites.
Dynamic CSS (a form of scripting language for CSS content) -- http://sass-lang.com/
CSSTidy (CSS compression/beautifier) -- http://csstidy.sourceforge.net/
A Compass Extension -- http://susy.oddbird.net/
Responsive breakpoints (no idea what that really is though) -- https://github.com/Snugug/Aura
We were thinking of ...
We like to make our server very modular in order to simplify the testing.
Full coverage testing is what will give you more chances of finding most of the bugs before using the server. In other words, a good way to verify that the server works as expected.
The server is composed of a small core, libraries, and plugins.
By default, plugins should be compiled as such (i.e. a .so under Linux.) However, by simulating all the necessary core functionality in a test, it is possible to run the plugin tests on the command line and find problems early.
The main thing that we want to simulate to ...
In order to offer one server and many modules instead of one large server, one needs to redesign the signalling system to work dynamically.
Since we want to have two sides to our system: a CGI that directly communicates with Apache and the actual Snap! Server to which the CGI connects to to get the HTML or other result to be sent back to Apache.
This means the Snap! Server is started once and serves numerous times without having to rebuild all the event tables on each access (nor the connection to the Cassandra system. TBD... can we really just duplicate the Unix socket identifier?) ...
IMPORTANT NOTE
This feature was not implemented. We instead went with the fully dynamic signals using boost::signals2 which allows you to grow plugins without having to recompile everything (and thus offer users a way to install additional plugins by simply installing a package on your Linux system.)
As I have been researching for the fastest signal system, I came up with what follows.
There is one draw back: all the modules must all be statically compiled (i.e. no independent "plug-in" type of functionality. Under Linux, that means no .so and under Windows no .dll)
The C++ ...
For some rather non-obvious reason, spam bots are having fun posting totally random, most usually non readable messages (gibberish as in random letters and numbers) to public forms they find on the Internet.
Even for themselves, it seems to me that it would be a lot more effective to post useful messages and not blow away their chance from the start.
Yet, many of these bots are quite retarded and can be prevented to post uselessly using a few tricks as follow:
See also: Anti-Spam feature
You can include a form identifier in all your public forms. This may not sound like ...
Online forms are required for many different aspect of a website.
Forms are used to allow users to search, for log in screens, for entering a quantity, to ask for credit card information for a payment, to write a comment, etc.
The forms are created and POSTs are parsed using the CppCMS library which takes care of that aspect of things (TBD).
The ability to create a form is a simple concept, however, the ability to generate the correct HTML code to get the expected result is not. We hope that the CppCMS library will take care of that so we do not have to on our end. The only thing we want to ...
Here is a list of detailed requirements more or less on a per plug-in basis.
More of the features are viewed as third party plug-ins since the Core system is pretty small. The few items part of the core are marked with [Core] and made part of the Core Feature group.
This list gives information that should be accessible to everyone, not just technical people.
Soon I will start marking features that are implemented as we are getting more and more of thos done.
We now have started to really work hard on the development and offer a page with the current development status of Snap! C++.
The ...
At this time we're testing Cassandra to properly understand how it works and make sure we can use it the way we're thinking we want to use it. This works. See libQtCassandra
Next we want to implement a simple test to check cTemplate and see that we can (1) create a simple layout with variables and fill in the fields; (2) extract the fields to generate the dependencies. We changed our plans on this one we'll be using XML and XSLT to transform the XML to whatever output the user is interested in (HTML, PDF, Text, RDF, etc.)
As we're working with Cassandra, make sure we can get ...
Snap! Websites
An Open Source CMS System in C++
