Spiria chooses ProcessWire

[Guy Verville]

https://www.spiria.com

After several sites made with ProcessWire, Spiria decided it was time to get rid of its cumbersome Drupal site. To be honest, ProcessWire is still difficult to sell to customers, because this CMS/CMF is not as well known as the most popular ones.

The migration to ProcessWire therefore served several purposes:

1. Eliminate the frustrations experienced with Drupal (especially with image management and some structural problems).
2. Allow integrators to learn the CMS during quiet periods, when they are not needed on other projects.
3. Promote the CMS by adopting it.

The challenges were many, but by no means insolvent, thanks to the great versatility of this programming framework. Indeed, if ProcessWire can be considered as a CMS in its own right, it also offers all the advantages of a CMF (Content Management Framework). Unlike other solutions, the programmer is not forced to follow the proposed model and can integrate his ways of doing things.

The blog

The site includes a very active blog where visuals abound. It was essential to cache the various dynamic components. For example, in all sections of the blog, there is a list of recent articles, a list of "short technical news", another list from the same author, a classification by category. In short, these lists evolve independently. ProcessWire's cache system, including its ability to classify by namespace, has significantly improved loading speed. Cache file management has been placed in a "saved" hook in the useful "ready.php" file.

Data migration

Importing the blog data was complex because at the time the site was designed in Drupal, programmers had not been used the easily translatable "entities", so each article resided in two different "nodes" (pages). We would have liked to use the core ProcessWire import module, but it does not yet take into account multilingual fields. However, we have used this code as a basis for building our own import module. This is one of ProcessWire's great qualities, as a CMF, it is easy to use existing code to design your own solutions.

Reproduce the layout

The current layout of the site has been reproduced exactly as it serves the company's needs very well. ProcessWire has simplified the work in many ways. Apart from the blog, which is very structured, the other sections of the site are more free, especially the case study section ("Our Work"). The use of page reference fields has particularly helped developers. As everything is a page in ProcessWire, you can create a pseudo relational database within the site itself. The administrator user becomes more aware of the data hierarchy and has better control over the data.

Programming architecture

The separation between controllers and Twig visualization files facilitates the management of the multiple components of the site. We haven't really explored the "regions" of ProcessWire, because we prefer not to mix these aspects of programming. This greatly facilitates the timely arrival of programmers in our department, used to an MVC structure, because they have a better understanding of what does what.

The Search

Once again, we were able to simplify what had been done in Drupal. There are two types of searches on the site, the blog search and the more general search on page 404 ( https://www.spiria.com/potato). The Drupal site search was driven by an Apache Solr server in Drupal. We decided to rely on the ease of ProcessWire and the Typeahead library (for the blog), because we didn't need the power of Solr (or Elasticsearch) anyway. Work to improve performance still needs to be done in this area. We would have liked to have seen the excellent search tool offered on the administrative side available on the frontend. We have not yet had time to explore the possibility of harnessing this code from the core of ProcessWire. Our wish here is that the CMS designer, Ryan Cramer, sees this as an opportunity to offer an exciting new feature to his CMS!

Powerful modules

We have the excellent modules ProCache (static caching), ProFields (fields that greatly improve the functionality of existing fields) and ListerPro (data search and processing tool). As the site is installed on a nginx server, we have ruled out ProCache for the moment and we are satisfied with the use of the cache() function alone. The ProFields fields are a blessing just like ListerPro. This last module is very useful to correct, for example, import errors (we had more than 800 blog articles, some of which date back to 2013).

We used a functional field to gather translations of terms that would normally have remained hard coded and difficult to access in the translation interface (an aspect to be improved in ProcessWire, in our opinion). By grouping translations in a single page, site administrators can easily change or correct terms.

Language management

What remains a very small irritant for us is the management of languages, which is fantastic in many ways. The fact that there is a default language is both a blessing and a problem. For example, in 2013, blog articles were not systematically translated. We experienced the same situation with a customer's site. If the article is only in English, no problem, we only have to not check French as an active language. However, if the article is only in French, we are still required to create the page in English and make tricks in the code, thanks in particular to a checkbox such as "Not present in English" to reproduce the behaviour naturally present for English (or any language deemed by default). Perhaps there is a more elegant solution here that we have not yet discovered. It's not much, but some clients don't see why there are two ways to do it here.

In conclusion

In any case, ProcessWire's great qualities continue to appeal to programmers, integrators, graphic designers, users and even our UI/UX expert. The solidity of the CMS/CMF, its functionalities all translated into objects/variables ($pages, $page, $config, $sanitizer, $input... the list is long) allows us to systematize our workflow, easily recover code and reduce production costs.

Although it is dangerous to offer only a CMS solution to our customers (hammer syndrome that only sees nails), it is tempting to consider ProcessWire as the Swiss Army knife par excellence of Web programming. As mentioned above, the CMF is suitable for all situations, has very good security tools and its designer has successfully improved PHP methods to make programming very pleasant and intuitive.

For us, migrating the company's website to this platform was the best tribute we could pay to its designer, @ryan.

Edited November 26, 2018 by Guy Verville
Adding images

[adrian]

Hey @Guy Verville - great writeup and a great looking site! 

This is a question for both you and @teppo - I am wondering what is unusual about your site that is causing isit.pw to not be able to detect it as a PW site? Or maybe isit.pw is caching an old lookup for your site?

[Guy Verville]

What is required to be identified as such? 

[adrian]

5 minutes ago, Guy Verville said:

What is required to be identified as such? 

I am not certainly exactly what isis.pw uses, but I think it looks for things like a response from ?it and /assets/files paths to images. Maybe also ProcessWire in the header. Hopefully teppo will chime in.

 

[Guy Verville]

That's weird because we launched two other sites recently and they are recognized... 

https://www.meubleduquebec.com

https://www.fieldapex.com

https://www.centura.ca

The only thing I see for the moment is that we removed on spiria.com all the *.md and *.txt files from the root (for security reasons). The three above had still those files when inspected by the isit.pw site. Perhaps it stores the result after that...

[Noel Boss]

Thank you very much for this great Article and Congrats to the new/old site ? looks fantastic!

One question, what do you mean by that; are you talking about a custom checkbox you added on all relevant templates?

On 11/26/2018 at 4:48 PM, Guy Verville said:

in particular to a checkbox such as "Not present in English"

[Sergio]

On 11/26/2018 at 1:48 PM, Guy Verville said:

As the site is installed on a nginx server, we have ruled out ProCache for the moment and we are satisfied with the use of the cache() function alone

Hey @Guy Verville, excellent write-up!! Thank you for that!

I've been using ProCache for about 3 years now in Nginx without any issues. So, go ahead! ?

PS: I'd like to suggest you post in on Medium, etc. as well to increase reach. If you decide so, I also suggest to add to Ryans role: creator and maintainer of Processwire... instead of just designer, as people may only read "graphic/web designer" when they see that. 

[Nicolas]

Great write up Guy, thanks for the post

You've mentionned Twig. How did you implement that ? Is there any chance to have more details about the programming architecture?

[Guy Verville]

On 11/30/2018 at 6:35 AM, Noel Boss said:

Thank you very much for this great Article and Congrats to the new/old site ? looks fantastic!

One question, what do you mean by that; are you talking about a custom checkbox you added on all relevant templates?

Hi @Noel Boss,

We simply add an extra selector in our query like this:

    $visitedLanguage = getVisitedLanguage();
	if($visitedLanguage == "en") {
		$queryExtra = "non_existent_english!=1";
	} else {
		$queryExtra = "";
	}

 

[Guy Verville]

22 hours ago, Sergio said:

Hey @Guy Verville, excellent write-up!! Thank you for that!

I've been using ProCache for about 3 years now in Nginx without any issues. So, go ahead! ?

PS: I'd like to suggest you post in on Medium, etc. as well to increase reach. If you decide so, I also suggest to add to Ryans role: creator and maintainer of Processwire... instead of just designer, as people may only read "graphic/web designer" when they see that. 

Olá @Sergio,

It would be great to let us know how you implemented ProCache in nginx. Out IT implemented the fastcgi cache present in nginx. Have you implemented both ProCache and that? Thanks for the suggestion, I will look into it.

Please note that we published a revised version on our own website: https://www.spiria.com/en/blog/website-creation/choosing-processwire-for-spiria-com/

[Guy Verville]

20 hours ago, Nicolas said:

Great write up Guy, thanks for the post

You've mentionned Twig. How did you implement that ? Is there any chance to have more details about the programming architecture?

Bonjour @Nicolas,

We started a long time ago to use https://modules.processwire.com/modules/template-engine-twig/. That code inspired one of our programmers to create his own module to take advantage of Twig 2.0 since the module Template Engine Twig still rely on Twig 1.35.

[Sergio]

On 12/1/2018 at 12:51 PM, Guy Verville said:

Olá @Sergio,

It would be great to let us know how you implemented ProCache in nginx. Out IT implemented the fastcgi cache present in nginx. Have you implemented both ProCache and that? Thanks for the suggestion, I will look into it.

Please note that we published a revised version on our own website: https://www.spiria.com/en/blog/website-creation/choosing-processwire-for-spiria-com/

Olá, Guy! ?

I'm hosting the app on Laravel Forge with FastCGI enabled. I've based my config on this @u-nikos post:

Here's my version:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;
    root /home/forge/example.com/public;

    
    index index.html index.htm index.php;

    charset utf-8;

    
    # -----------------------------------------------------------------------------------------------
	# Access Restrictions: Protect ProcessWire system files
	# -----------------------------------------------------------------------------------------------

	# Block access to ProcessWire system files
	location ~ \.(inc|info|module|sh|sql)$ {
		deny all;
	}

	# Block access to any file or directory that begins with a period
	location ~ /\. {
		deny all;
	}

	# Block access to protected assets directories
	location ~ ^/(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) {
		deny all;
	}

	# Block acceess to the /site/install/ directory
	location ~ ^/(site|site-[^/]+)/install($|/.*$) {
		deny all;
	}

	# Block dirs in /site/assets/ dirs that start with a hyphen
	location ~ ^/(site|site-[^/]+)/assets.*/-.+/.* {
		deny all;
	}

	# Block access to /wire/config.php, /site/config.php, /site/config-dev.php, and /wire/index.config.php
	location ~ ^/(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ {
		deny all;
	}

	# Block access to any PHP-based files in /templates-admin/
	location ~ ^/(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ {
		deny all;
	}

	# Block access to any PHP or markup files in /site/templates/
	location ~ ^/(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ {
		deny all;
	}

	# Block access to any PHP files in /site/assets/
	location ~ ^/(site|site-[^/]+)/assets($|/|/.*\.php)$ {
		deny all;
	}

	# Block access to any PHP files in core or core module directories
	location ~ ^/wire/(core|modules)/.*\.(php|inc|tpl|module)$ {
		deny all;
	}

	# Block access to any PHP files in /site/modules/
	location ~ ^/(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ {
		deny all;
	}

	# Block access to any software identifying txt files
	location ~ ^/(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ {
		deny all;
	}

	# Block all http access to the default/uninstalled site-default directory
	location ~ ^/site-default/ {
		deny all;
	}
	#Amplify dashboard
	location /nginx_status {
        stub_status on;
        allow 127.0.0.1;
        deny all;
    }

	# -----------------------------------------------------------------------------------------------
	# If the request is for a static file, then set expires header and disable logging.
	# Give control to ProcessWire if the requested file or directory is non-existing.
	# -----------------------------------------------------------------------------------------------

	location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ {
		expires 15d;
		log_not_found off;
		access_log off;
		try_files $uri $uri/ /index.php?it=$uri&$query_string;
	}
	
	# -----------------------------------------------------------------------------------------------
	# ProCache Rules
	# -----------------------------------------------------------------------------------------------

	set $cache_uri $request_uri;

	if ($request_method = POST) {
		set $cache_uri 'nocache';
	}

	if ($http_cookie ~* "wires_challenge") {
		set $cache_uri 'nocache';
	}
	
	if ($http_cookie ~* "persist") {
		set $cache_uri 'nocache';
	}


	# -----------------------------------------------------------------------------------------------
	# This location processes all other requests. If the request is for a file or directory that
	# physically exists on the server, then load the file. Else give control to ProcessWire.
	# -----------------------------------------------------------------------------------------------

	location / {
		expires -1;
		try_files /site/assets/ProCache-b3d534d...d/$cache_uri/index.html $uri $uri/ /index.php?it=$uri&$args;
	}
    

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/example.com-error.log error;

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }
}

 

 

[Sergio]

On 12/1/2018 at 12:51 PM, Guy Verville said:

Please note that we published a revised version on our own website: https://www.spiria.com/en/blog/website-creation/choosing-processwire-for-spiria-com/

 

I'm getting a 404 on your website due to Chrome's blocking scripts on http as insecure. See screenshot. Version 70.0.3538.110 (Official Build) (64-bit) on Windows 10

 

[Guy Verville]

12 minutes ago, Sergio said:

I'm getting a 404 on your website due to Chrome's blocking scripts on http as insecure. See screenshot. Version 70.0.3538.110 (Official Build) (64-bit) on Windows 10

 

Some people have this strange problem. We did migrate from a Pantheon site (it was on Drupal, remember), and it's as if the SSL certificate is still stuck in Pantheon, which is not. My IT teams is on the case. Not all people has this problem.

[Guy Verville]

26 minutes ago, Sergio said:

Olá, Guy! ?

I'm hosting the app on Laravel Forge with FastCGI enabled. I've based my config on this @u-nikos post:

Here's my version:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;
    root /home/forge/example.com/public;

    
    index index.html index.htm index.php;

    charset utf-8;

    
    # -----------------------------------------------------------------------------------------------
	# Access Restrictions: Protect ProcessWire system files
	# -----------------------------------------------------------------------------------------------

	# Block access to ProcessWire system files
	location ~ \.(inc|info|module|sh|sql)$ {
		deny all;
	}

	# Block access to any file or directory that begins with a period
	location ~ /\. {
		deny all;
	}

	# Block access to protected assets directories
	location ~ ^/(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) {
		deny all;
	}

	# Block acceess to the /site/install/ directory
	location ~ ^/(site|site-[^/]+)/install($|/.*$) {
		deny all;
	}

	# Block dirs in /site/assets/ dirs that start with a hyphen
	location ~ ^/(site|site-[^/]+)/assets.*/-.+/.* {
		deny all;
	}

	# Block access to /wire/config.php, /site/config.php, /site/config-dev.php, and /wire/index.config.php
	location ~ ^/(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ {
		deny all;
	}

	# Block access to any PHP-based files in /templates-admin/
	location ~ ^/(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ {
		deny all;
	}

	# Block access to any PHP or markup files in /site/templates/
	location ~ ^/(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ {
		deny all;
	}

	# Block access to any PHP files in /site/assets/
	location ~ ^/(site|site-[^/]+)/assets($|/|/.*\.php)$ {
		deny all;
	}

	# Block access to any PHP files in core or core module directories
	location ~ ^/wire/(core|modules)/.*\.(php|inc|tpl|module)$ {
		deny all;
	}

	# Block access to any PHP files in /site/modules/
	location ~ ^/(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ {
		deny all;
	}

	# Block access to any software identifying txt files
	location ~ ^/(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ {
		deny all;
	}

	# Block all http access to the default/uninstalled site-default directory
	location ~ ^/site-default/ {
		deny all;
	}
	#Amplify dashboard
	location /nginx_status {
        stub_status on;
        allow 127.0.0.1;
        deny all;
    }

	# -----------------------------------------------------------------------------------------------
	# If the request is for a static file, then set expires header and disable logging.
	# Give control to ProcessWire if the requested file or directory is non-existing.
	# -----------------------------------------------------------------------------------------------

	location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ {
		expires 15d;
		log_not_found off;
		access_log off;
		try_files $uri $uri/ /index.php?it=$uri&$query_string;
	}
	
	# -----------------------------------------------------------------------------------------------
	# ProCache Rules
	# -----------------------------------------------------------------------------------------------

	set $cache_uri $request_uri;

	if ($request_method = POST) {
		set $cache_uri 'nocache';
	}

	if ($http_cookie ~* "wires_challenge") {
		set $cache_uri 'nocache';
	}
	
	if ($http_cookie ~* "persist") {
		set $cache_uri 'nocache';
	}


	# -----------------------------------------------------------------------------------------------
	# This location processes all other requests. If the request is for a file or directory that
	# physically exists on the server, then load the file. Else give control to ProcessWire.
	# -----------------------------------------------------------------------------------------------

	location / {
		expires -1;
		try_files /site/assets/ProCache-b3d534d...d/$cache_uri/index.html $uri $uri/ /index.php?it=$uri&$args;
	}
    

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log  /var/log/nginx/example.com-error.log error;

    error_page 404 /index.php;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    location ~ /\.ht {
        deny all;
    }
}

 

 

Muito obrigado!

[Guy Verville]

21 hours ago, Guy Verville said:

Some people have this strange problem. We did migrate from a Pantheon site (it was on Drupal, remember), and it's as if the SSL certificate is still stuck in Pantheon, which is not. My IT teams is on the case. Not all people has this problem.

We finally discovered the culprit. An IPV6 entry that was still pointing to Pantheon. Everything should be ok by now.

[Sergio]

21 hours ago, Guy Verville said:

We finally discovered the culprit. An IPV6 entry that was still pointing to Pantheon. Everything should be ok by now.

It is! Thanks!

[Macrura]

On 11/26/2018 at 10:48 AM, Guy Verville said:

We decided to rely on the ease of ProcessWire and the Typeahead library (for the blog), because we didn't need the power of Solr (or Elasticsearch) anyway. Work to improve performance still needs to be done in this area. We would have liked to have seen the excellent search tool offered on the administrative side available on the frontend. We have not yet had time to explore the possibility of harnessing this code from the core of ProcessWire. Our wish here is that the CMS designer, Ryan Cramer, sees this as an opportunity to offer an exciting new feature to his CMS!

The admin search is JqueryUI Autocomplete.

http://api.jqueryui.com/autocomplete/

there are some Extension Points such as _renderMenu and _renderItem that are using some custom logic to return the required markup. (look at the AdminThemeUikit/scripts/main.js, as well as the _search-form.php.

It does work well and looks nice, but can achieve the same basic look and functionality for a front end site with possibly less work using typeahead.js and with the Bloodhound using local storage, it could mean for faster lookups.