Michael van Laar

Sérgio, this is a side effect of the lazysizes script. The fallback image, which has a different aspect ratio, is loaded first. Then the apppropriate image for the screensize is loaded and displayed.

I just changed the behavior by not using the lazysizes script for this particular image. Now it takes a bit longer until anything is displayed on this place. So the perceived loading speed is a bit slower. But it’s definitely better because there is no change in aspect ratio of the image without the browser window being resized.

I don’t use a framework. Instead I use my own collection of boilerplates, polyfills and tools I (re-)use in most of my sites: https://github.com/MichaelvanLaar/Website-Template-Starting-Point

This starting point is still far away from being perfect. In fact, there are always things I want to change – right now it’s more BEM-ish CSS. But it serves its purpose.

A friend of mine asked me to build a website for the dog training business she just started. She already had a graphic designer create a logo and a small print brochure and wanted a clean, simple website.

www.hundeschule-grosse-freiheit.de is the result.

The website is neither big nor fancy. But it has some nice details:

• Responsive, lazy loading images
  Almost all images (except the SVGs and the badge image in the footer) are maintained via the ProcessWire backend. Each image is rendered in eight different sizes – using respimage and lazysizes for frontend display.
  All images are created using the great ImageFocusArea module – something I wanted to be able to use in ProcessWire since I first worked with Drupal’s “ImageField Focus” module. Of course all images are minified using minimize.pw.
   
• Central asset management for images
  Because most of the decorative images are used on more than one page, it made sense to build a central image management – using a specific “settings” part of the page tree with one page per image.
  Images in sidebars or on the gallery page are chosen using page fields in combination with the Page List Image Label module:
  
  So an editor’s experience regarding the visual representation of the “linked” images is not so much different from working with default image fields.
   
• Consequent usage of a cookieless subdomain for static content.
  The cookieless subdomain specified in the AIOM+ module’s setting is also used to deliver images.
   
• Multi-language content.
  Nothing big, but my first ProcessWire site with more than one language. Of course it uses the Autodetect Language module for the homepage – as well as “hreflang” links in each page’s head to give Google as much language information as possible.
   
• Feedback and ratings
  The feedback page, which features quotes and pictures of happy clients, is populated semi-automatically. Feedback is collected using a Form Builder form on a secret page. After a training has ended the site owner sends an email to clients, thanking them for taking part and asking them for their feedback with a link to the secret form page. Clients can enter a quote, a 5-star rating and optionally an image – as well as their permission to use the quote and the image (necessary to avoid legal problems). This information is saved as a new unpublished page. After a new feedback entry page is published by the site owner, the new entry is displayed on the main feedback page. The pages used to save feedback entries feature multi-language fields. So it’s possible to present all testimonial quotes in both languages.
  The footer of each page features an aggregated 5-star rating, calculated from all single ratings displayed on the feedback page.
  Each individual feedback entry on the feedback page as well as the aggregated rating are formated using Schema.org markup. So it can be read and understood by Google and thus has the potential to be displayed as rich snippet on Google result pages.

Oh by the way: The decision to use email links rather than a contact form was made by the site owner.

I opened an issue on Github mentioning the above findings: https://github.com/ryancramerdesign/ProcessWire/issues/919

Having the same problem here, I investigated a little and found a bug and a workaround.

First, there is a bug in LanguageTabs.module, lines 83 and 84. This prevents the JS and CSS file from being found.

Wrong:

$this->config->scripts->add($this->config->urls->LanguageTabs . "LanguageTabs.js");
$this->config->styles->add($this->config->urls->LanguageTabs . "LanguageTabs.css");

$this->config->scripts->add($this->config->urls->LanguageSupport . "LanguageTabs.js");
$this->config->styles->add($this->config->urls->LanguageSupport . "LanguageTabs.css");

Since I can’t help so much with developing ProcessWire or PW modules (because I’m not a PHP expert yet), I’d be happy to help extending the documentation. So please tell me if I can help.

The reason is that find() loads all those pages, whereas count() just counts them

Great. I didn’t know that I can put a selector into “->count()”. Did I miss this in the API cheatsheet?

caching the results will give you first boost.

That’s what I did in my current project. I have a “more topics in this blog“ box on every tag page. The box features a list of links to all tags – except the current tag page. So every tag page has a different "more topics" list, wich is cached for 24 hours. Probably a far longer cache period would be reasonable, since I’m not going to add new tags every day.

<?php
$tags = $pages->find("template=tag, sort=title");
$cache_topic_name = 'more_tags_list_for_' . $page->name;
$cache = $modules->get("MarkupCache");
if(!$more_tags_list = $cache->get($cache_topic_name, 86400)) {
 $more_tags_list = '<ul>';
 foreach ($tags as $tag) {
   if ($pages->find("template=blog-article, tags=$tag")->count() > 0) {
     $more_tags_list .= '<li><a href="' . $tag->url . '">' . $tag->title . '</a></li>';
   }
 }
 $more_tags_list .= '</ul>';
 $cache->save($more_tags_list);
}
echo $more_tags_list;
?>

Thanks Ryan! I’ll definitely try this once I have my e-mail newsletter up and running.

Does this answer you question?

OK, RTFM My fault.

A stupid question, but I want to get it right: The module chooses the name, with which the cached markup result snippet can be identified later on, automatically by looking at the if-statement?

Great! Exactly what I was looking for to display related content based on common tags.

If I find the time – and if my limited PHP knowledge will be sufficient – I’m going to extend this to be able to find related content based on more than one field. This would also be a great addition to display search results based on their relevance. If there is not yet a solution which does so …

One additional question: Are there any performance drawbacks?

Generating a list of ten or twenty category links must be quite CPU-intensive if Processwire has to iterate over hundreds of blog articles every time just to check if a category is used at least once.

By the way, being able to extend the comment form would be nice anyway. A typical use case would be an additional checkbox which a commenter can check to subscribe for a newsletter. You would then “only” have to hook into comment processing to pass this information (in combination with his e-mail address) through to an e-mail marketing service provider’s API.

But this is just an idea.

Great! Then I will wait fro v2.3, since this is not a key feature for my blog ;-)

I’d like to have an input field for the commenter’s web address in my comment forms. Is there a way to extend the form and the comments output without hacking the module?

I looked at the Google Doc too and ran it through Google Translate

I see, I should have written the doc in English. Sorry for that.

Wow! Looks good.

Here is my first (and surely incomplete) list with things that have to be changed, if the shop module should be ready for the german market:

https://docs.google.com/document/d/1xsvQQboXQwnrvJ-fnkln--yZ255e5Y3PAIM4onMk6GU/edit

Please feel free to add topics I forgot.

I start today with a very basic template for the shop.

Wow, you’re really fast. I hope I can keep up with you ;-)

Sorry guys, absolutely no time for a chat today. But how about setting up a Google Document or so, which we can fill with ideas, requirements etc?

I already had a look at the shopping module in a local test installation some weeks ago.

A roadmap like Luis already said would be the best way to start.

How about a skype call or conference call tomorrow (October 24^th), let’s say 4 p.m. German time?

OK, meanwhile I had a deeper look at Ryan’s blog profile.

And of course using pages as tags is great, because you can add a description field (like you do with categories), which makes tag pages performing way better regarding SEO. I used pages as categories in my old MODX based blog. But adding new categories/tags was not as easy as it is here.

I know that I could solve this with a page type field. But for my taste this is still not as easy to use as a “real” tag field.

I doubt that my developer skills are sufficient. But I will at least try to build a tag fieldtype.

Theoretically it should not be that difficult. One “only” has to preprocess all the content which is stored site wide in this field and create a clickable listing under the text field. A little jQuery onclick action and that’s it – at least in theory And using Nico’s TextboxList module I think it could look really good.

By the way, this is my first ProcessWire logo usage: http://www.spreadshirt.de/t-shirt-selbst-gestalten-C59/product/106913128/view/1/sb/f

A shirt which I’ll wear on the 1st CMS Night Nürnberg event, where I’ll tell people a little bit about how wonderful developing with ProcessWire is.

OK, the client I was talking about can not (yet) afford a shop :-(

Anyway, I want to start working on a small shop based on ProcessWire. Perhaps we should just make list what has to be done resp. changed or extended, so that the shop module meets German requirements.

For my clients I compiled a little summary with all the regulatory requirements a German online shop has to meet. If you want, I’ll send you the PDF. I would also have my lawyer check the outcome of our work, so that we can be sure that at least the development aspect of the module is OK. Content like general business terms, cancellation policy etc. have to be written or at least checked by a lawyer for each individual shop anyway.