Site structure
The site is based on Wordpress CMS. The CMS has been chosen based on the complexity, provided features and support. All those are really important since the EESTEC ITT is constantly changing and the new members have to be able to "get in" easily. Due to it's wide use, Wordpress has a good support and extensive official documentation. It also provides a system of plugins, enabling us to use a lot of features implemented by others.
As far as the internal site structure goes, we are trying to build using the standard Wordpress objects (post types, taxonomies, users) as much as possible. That then enables us a good integration with other plugins and is more understandable for future developers.
The Wordpress "post_type" object by default includes a few things such as: Title, author, content, publish date, attachments, related taxonomies, etc. Of course that is not enough for more custom solutions and that is why the CMS also supports additional post metadata. That means we can stick any sort of additional data to our post object. As an example for the event post object, we are "sticking" on the data about: start date, end date, number of participants, organizer LC ID, fee, etc. The same approach applies to the user objects. Using this, we are able to extend and customize the functionality.
Apart from the objects, the CMS provides a nice way for adding additional functionality to the core. That is by utilizing hooks and filters. What this enables us, is to push/insert our code in to the core. For example we can put a hook on the edit post, ad write a function for it. Our function checks the users LC and if the post object is LC and equals to the users one (user is trying to edit his own LC) it does nothing. If the LC-s don't match, it prevents editing. This is the vay CMS is providing a gate to add new functionality. The good thing about it is, that the CMS is executing these functions everywhere. You don't have to worry about leaks. For example, querrying a list of edit links for LC-s will be automatically filtered because our function is called by the CMS on the low level in the query.
When using Wordpress CMS most users are familiar with customizing the Wordpress by the use of a web interface and installation of additional plugins. That enables quick and easy configuration and everything (except for plugin files) is stored in to the database. The configuration you can do using this approach is limited and does not allow major customization, but newer the less useful. Since everything is stored in the database, we have to be very careful when developing using this approach. More info in Database sharing.
Most of our visible Work is done by modifying our theme files. Here we are defining the displaying of before mentioned post meta data. Also the general look and front end of the site is defined here. By adding custom code to the functions.php file, it's possible to manage the core functionalities. This is where you can add the definitions of your post objects or hooks and filters.
The plugins enable us to use a separate modules providing functionality. Usually they are built for easily sharing the functionality to other sites. Beside that, we are also using the plugins framework to provide separate development sections for teams. So each team is implementing it's features by implementing their plugin. This way we can avoid everyone doing all their work by changing the functions.php file. Another thing is that in case of failure, a plugin can be easily disabled.
On the diagram the taxonomies are missing and so are the relations to attachments etc. The relations are represented by the foreign keys in metadata.
Do you like drawing diagrams? Send an email to [email protected] :)