SiSustainable

Spip Tech Discussion

En cours de traduction - merci de votre patience

Without getting too technical, templating in Spip goes like this :

<<< design, design, design ... >>>
Then, a request for Content:
< Request Article 5>
<*> Display Title <*>
<*> Display Text <*>
<*> Display Comments <*>
<<< design, design, design ... >>>

Above we had a hard written request for Article 5, which would allow us to display the content of article 5 on any page, such as the home page, the page of a section, or any other page. The *’s can be replaced with more design if need be : the different content be placed anywhere on the page in any style.

There can be as many content requests as desired on each template. Content requests can be hard, like "article 5" above, or relative. A relative request would be in the genre "Request all the articles of this section ;display their titles in a list in this design", or "Request the five last articles of the entire the site, or just the English site, etc.".

There are two basic templates necessary, one for the home page and one default for articles. A simple site will only require these two templates.

A more complicated site will require a default template for sections (usually an intro text with the articles and sub-section within it), and other templates for special sections and articles. For even more complicated websites a complex hierarchy of templates can also be implemented.

However, the power of Spip is that if only the minimum is required, only the minimum needs to be written. For everything more, each new object and new template can be added one by one based on a real need for these new elements.

Basically, Spip provides quick tools to make any request for content you’re likely to want to do in a website. For instance, you can easily make lists and order by date or title, invert the lists, take only a part, or remove specific individuals. It can also be set so the user can force an order of a list, and if not then default to some chosen order. And so on for essentially everything people normally want to do in a template.

What Spip doesn’t do

Spip can’t automatically do something that’s unpredictable by by the webmaster. For instance, if you want a list of links to appear in an order that you’ll want to decide later that could link to anything on your site or the web, the webmaster cannot tell Spip to take care of this automatically.

The problem many webmasters encounter in Spip and other CMS’s is trying to automate something that can’t fundamentally be automated, or trying to automate something that’s easier just to do. The more complex the criteria for a list become the more likely it’s less work to do it by hand or give control to the user (make the list content the user can control) ; this balance is the key to efficient design with a CMS.

For instance, if you want such a "anything list" to appear somewhere on your website, on every page or certain pages, then we simply make a space in the content which will appear where you want (and explain how to make links, in Spip it is easy).

Rare requests

Things may of course be desired at some point that Spip doesn’t easily do.

For instance, there’s no easy shorthand in Spip to easily make a list based on how many vowels are in the title or text, or mix two articles together in some intricate way (not just one after the other). The makers of Spip have assumed these aren’t tasks most of their users will want to do.

However, these types of problems are not unsolvable. The solution is to write the request in php (the computer code Spip is written in), which may simply take a bit more time.

However, there’s no CMS which will give an easy way to do "everything possible". The only way a CMS could do this would be by being as complicated as the code it’s written in ; but if this is the case then why not just learn the underlying code, which is the best solution. An uncommon request simply required some php or Java to be written. If it’s an extremely complex problem then an extremely specialized expert can be consulted, but only on a problem by problem basis. An extremely complex CMS on the other hand requires an equally specialized person simply to implement basic things, guaranteeing high costs forever.

But for sure a complex CMS is better ... right ?

A "more complex CMS" will still be infinitely far away from being infinitely complex and solving all problems, and will simply produce new problems due to it’s complexity, even if it happens to solve a single problem quickly.

Since future needed development could be anything, a complex CMS is no more likely to happen to solve the future problems easily than any other CMS, and so will just as likely require php or other code writing. The difference is the code will have to be written for an environment that’s already very complex, and so will be more difficult to write.

Though it’s more costly, there should not be any fundamental fear of writing code such as php. It is harder to learn how a complex php CMS works than the php code it’s written. This is because, as with any computer code, php is a simple set of rules used to construct more complex sets of rules. So, for writing new php code it’s best to be as close to a blank php environment as possible, (not have to deal with an already massively complex php system).

When content is organized in a very simple way, such as in folders and sub-folders, writing special code is far simpler. Most code is written with files, folders, and sub-folders, in mind and this is how Spip organizes information (articles, sections, and sub-sections) ; coders are also very familiar with this kind of organization and don’t really need to know much about Spip to accomplish the desired task. Making more complex organization systems with all sorts of kinds of objects simply makes the desired information harder to find and display in the desired way, for humans as well as computers.

And, if ever something of another Open Source CMS was absolutely needed, it’s Open Source so the desired code can simply be taken and put into Spip as a plugin. If cost is a factor, or a closed source CMS was needed for something (very unlikely), this other CMS can be installed beside Spip for that specific purpose, in a subfolder or sub-domain. The main site would remain as easy to use and as fast, and the special purpose CMS would be consulted less often (so not slowing down the whole server) and would remain simple to use as it only does a limited thing. For instance this may make sense for a forum in the site "basement", or to develop some special web application.

For instance, [http://typo3.com/Highlights.1629.0.html] advertises "really complex software" on it’s highlight page, a long time to learn their system and making you aware you may need a whole team of specialists. The cost of this complexity is not only the cost of developing a website but also the speed of the website. Complex software always goes slower than simpler software.

On a personal computer complex software may be "fast enough" because faster won’t be noticeable to the eye, but for servers "fast enough" doesn’t exist.

The reason is any number of people could visit the server and each new person will require resources from the server, mostly processor and ram (the time to find information on the hard-drive would also be significant on an extremely large site). On a personal computer there is a limit to how much you will want to accomplish in any given second, simply because a single person can only work so fast, but on a server there’s no limit to the people who could be using it. So, the more complex the CMS, the slower it will be, and it will become slower and slower the more people visit, and with enough people the server will simply crash, which may cause further problems. The relationship may not be linear. The more complex software is the more likely some exponential problem will arise where one more request from one more person crashes the server. Complex software is by nature less secure, and because it’s slower requires less effort for denial of service attacks.

The basics of Spip can be learned in less than a week, and the Php Spip is written in has far more experts than there are experts in Typo3, or any other CMS. So, Spip has several advantages over more complex CMS’s :
- It’s easier to use
- It’s faster
- It’s easier to design a website with
- After creation it can be easily maintained and even improved by an amateur if need be
- To take Spip to the limits only requires knowledge of Php, which is fairly widespread.

Complicated CMS’s not only require a far rarer expert (or group of experts), but have the same fundamental limits as any CMS, and just like Spip would require writing in Php, or some other code, to solve uncommon problems.