Leaderboard

I think a separate mobile website is an outdated approach and device sniffing will be both unreliable and require more maintenance. I would highly recommend a single responsive design, but if you're sure you want to pursue separate templates for mobile devices then you could select templates by domain as suggested here... ...or use the same approach but test for device using Mobile Detect.

ProcessWire Prism JS Syntax Highlighter A module to parse given HTML and syntax-highlight code elements using Prism JS Features Support for 120 languages Very lightweight, core weights 2KB minified gzipped. Customizable. Specify your own CSS, or use one of 8 default themes Hookable. Use hooks to specify your own custom CSS, and JS Plugin support. You can use all available plugins that come with Prism JS. Installation Add module to /site/modules/ and then install. Or go to Modules > Install > Add New and use any of the options provided to to install. Create a text/textarea field or use an existing one then pick Prism Code Highlighter from Details > Text Formatters. Protip: This module parses HTML markup, so it should come after HTML parsers such as Markdown textformatters. Add code elements within the field content with language-xxxx classes. Or pick a default language from configuration page if you are unable to specify the classes. Go to configuration page and select any plugins you want. To use some plugins, extra classes are required. See plugin documentation. Install these recommended modules for the best experience: Parsedown Extra module to render Markdown Extra into HTML. You can also set custom attributes for each element unlike vanilla Markdown. Customization Go to module configuration to specify: Auto inclusion of highlighters for parsed languages Default language for inline code elements or ones without language-xxxx classes. Ability to use minified/non-minified component and parser files Plugin options Theme options Custom JS and CSS for configuration / theming Ability to use hooks to specify custom CSS and JS Hooks Hook into TextformatterPrism::getCustomCss and TextformatterPrism::getCustomJs in your ready.php file and return an (array of) URLs as follows: // specify custom CSS wire()->addHookAfter('TextformatterPrism::getCustomCss', function (HookEvent $event) { $event->return = 'path/to/custom.css'; }); // Specify custom JS wire()->addHookAfter('TextformatterPrism::getCustomJs', function (HookEvent $event) { $event->return = ['path/to/custom.js', 'another/custom.js']; }); Screenshots Links https://github.com/abdusco/pw-prism-code-highlighter http://prismjs.com/ http://modules.processwire.com/modules/textformatter-prism/

mod_rewrite is a part of apache, so there's nothing to detect when this is using nginx. But you can still complete the installation with that error. Just make sure rewrites are correctly set up in nginx as well.

Here's a complete example from the module Blog.

Allow urlSegments for this template. Create a selector including this urlSegment (user name). Read more about selectors: https://processwire.com/api/selectors/ Read more about urlSegments: https://processwire.com/api/variables/input/

I'lll give it a go next time I need to start a new site. In fact, that might be soon as I want to test this https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/

Thanks for the help. I tried other CMSs and notice the same quality as ProcessWire. I also found out I can display the full image and resize the width by CSS.

I helped @raulyjo through MP, the problem did not come from the module. It was missing a page and the template code that were probably forgotten during the migration. All good now

Hi Adrian, Confirmed this version fixed the problem. Gideon

You could use masonry or make sure the titles don't take more than a row. You can do the later with css .title-container { text-overflow: ellipsis; overflow: hidden; white-space: nowrap; } As for google you can have longer titles, they will just not be displayed fully in search results. You can look at other sites and see how they handle it.

Does this work on PW 3.0 though? One part says: It should. See: https://github.com/processwire/processwire-issues/issues/75

Hello all ! Just because I'm proud to be featured by Snipcart (js ecommerce solution) about my integration on my Processwire based website ! This post talks about Processwire and how I've done it : https://snipcart.com/blog/case-study-ateliers-fromagers-processwire If you wanna take a look at my website : https://www.ateliersfromagers.com/ (french & english) Have a good day everyone ! S

@flod and @Gideon So - I just committed a new version which automatically adds the Repeaters parent to the list of branch exclusions. I would appreciate it if you could please check if this takes care of image uploads in repeaters without having to manually add it in the config settings. Thanks!

Default session lifetime is 86400 seconds. You can change this to any value you want. // config.php $config->sessionExpireSeconds = 86400; Allow/ disallow sessions (and the wire cookie) under conditions. Remind that you need this to have access to the backend admin. // config.php $config->sessionAllow = true; If you want to disable cookies only for the frontend /** * config.php * if we would use cookies only for the admin area * */ $config->sessionAllow = function($session) { // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // otherwise disallow session return false; }; If you want to use cookies respecting EU Cookie law I recommend Cans Module MarkupCookieConsent in combination with this settings. /** * config.php * if we would use cookies only for the admin area * */ $config->sessionAllow = function($session) { // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // user accepted cookies due to EU law (Module MarkupCookieConsent) if(!empty($_COOKIE['eu-cookie'])) return true; // otherwise disallow session return false; }; Use the core module SessionHandlerDB to store session vars in the database. Learn more about session setting options and sessions by reading the comments in the files /wire/config.php or /wire/core/Session.php of your processwire installation.

This is just an idea... You could consider making the creation and maintenance of these articles easier for site editors by having a simpler structure in the page tree (just the categories as parent pages), entering the article date with a datetime field, and then creating the desired URL for the frontend using URL segments (enable this on the category template). So your category template would look for the following URL segments: segment 1: year - sanitize to integer, throw 404 if out of range segment 2: month - sanitize to integer, throw 404 if out of range segment 3: day - sanitize to integer, throw 404 if out of range segment 4: article page name - throw 404 if no match for article page name In terms of finding articles that match a given year, month or day you could convert to a timestamp range as Ryan shows here, but to make it easier (and considering you'll need the integers for building the article URLs) I would instead add 3 integer fields to your article template, set the field visibility to "Hidden (not shown in editor)" and then populate them with a saveReady hook. // in /site/ready.php $this->pages->addHookAfter('saveReady', function($event) { $page = $event->arguments('page'); if($page->template->name === 'article' && $page->article_date) { $page->day = date('d', $page->article_date); $page->month = date('m', $page->article_date); $page->year = date('Y', $page->article_date); } }); Now it's really easy to find articles, e.g. $matches = $pages->find("template=article, year=2016, month=11, sort=sort"); For the question in your original post you'd do something like this: $latest_article = $pages->get("template=article, parent=/politics/, sort=-article_date"); $recent_articles = $pages->find("template=article, parent=/politics/, article_date={$latest_article->article_date}, sort=sort, limit=5"); $day_link = "/politics/{$latest_article->year}/{$latest_article->month}/{$latest_article->day}"; // use this as the first link to the 'parent' page When you need to output the URL of an article you would build it like this: $url = "{$article->parent->url}{$article->year}/{$article->month}/{$article->day}/{$article->name}/"; For convenience you'd probably make a simple function that returns this URL string. In the backend, rather than browse through the page tree, if you want to list articles by day/month/year you can use the "Find" lister. Or better yet a dedicated Lister Pro instance for articles.

So many ways now to structure templates. Sounds definitely interesting, for the reasons @Robin S listed.

This is freaking awesome - I love it! I've always disliked working with HTML markup inside PHP variables - the sacrificed readability of the HTML that comes with multiple variable concatenations, the single quotes/double quotes/escaped quotes hassle. I try to avoid it as much as possible using output buffering but this new feature suits me down to the ground and will definitely be my preferred way of managing markup in templates going forward. Simple and brilliant, like the rest of PW. Thanks!

Yes. It is called Croppable Image 3! Instead of defining the imagecrops in a function.php file, you define it per imagefield. With this, you may need only one imagefield per site, as you can define as many settings you like. Also you can stick settings to specific templates, or you apply them to all.

Hi UIkit 3 users In v2 there used to be a file called uikit-variables (actually two files, a less and a sass version). I liked it this way, because I could simply use my text editor's find all feature to look for what I was interested in. In v3 all the variables are declared in separate files found in the components directory. So I hacked together a simple bash script to collect all the variables in a single file, just for reference purposes, so that I can still do my search in one file only. Should anyone want to do the same, please feel free to use it: #!/bin/bash # Author: Szabesz, release date: 2017-01-12 # Use at your own risk! # Purpose: This script collects all the variables used by UIKit 3 # Configuration: adjust the variables called SOURCE_DIR, TARGET_DIR and FILE_NAME # Usage: run the script and find the result in the generated output file: $TARGET_DIR/$FILE_NAME # How it works: it finds all the 'less' files we need in the folder called 'components' (specified by $SOURCE_DIR) # then grep filters all the lines beginning with @ # in each line, the first occurrence of ':' is replaced with ': ' by sed, so that we have some extra space # finally lines are outputted into a file # Known issues: tested only on macOS 10.11 and Bash 4.x # @media queries are also included, but I consider this to be an added bonus :P # Credits: https://getuikit.com/ set -e; printf "Collecting all variables used by UIKit 3...\n" SOURCE_DIR="/path/to/uikit/src/less/components" TARGET_DIR="/path/to/target/folder" FILE_NAME=_UIkitVars_$(date "+%Y-%m-%d_all.txt") cd $SOURCE_DIR if [ -f $TARGET_DIR/$FILE_NAME ]; then rm $TARGET_DIR/$FILE_NAME fi find . -type f \( -iname "*.less" ! -iname "_import*" \) | xargs grep -E "^@" | sed 's/:/: /' >> $TARGET_DIR/$FILE_NAME printf "End of script has been reached :)\n" exit 0

Actually, no. I ended up doing that, since it was the least cumbersome way of doing it. Other methods requires going through hoops to modify core behaviour, which I wanted to avoid doing too much in the first place. I created created another field "devTags" and renamed the original to "blogTags" and created a new template for posts under /dev named "work" /blog (template: listing) /tags (template: tags) tag1 (template: tag) tag2 post1 (template: post, field: blogTags) post2 post3 /dev (template: listing) /tags (template: tags) tag1 (template: tag) tag2 work1 (template: work, field: devTags) work2 then without changing the templates, I created a new property hook that redirects $page->tags to correct tags field (blogTags or devTags) depending on the name of the rootParent of the post/work. // return pages referenced with tags field depending on the rootParent wire()->addHookProperty('Page::tags', function (HookEvent $event) { $page = $event->object; $fieldName = $page->rootParent->name . 'Tags'; // check if field actually exists if (!$page->fields->get($fieldName) instanceof Field) { throw new WireException("{$page->template->name} template does not have $fieldName field."); } $event->return = page("$fieldName"); }); I also created another hook that lets me get the pages tagged with a specific tag, for when listing posts/works under the url /blog/tags/tagName // return posts tagged with the current tag page wire()->addHookProperty('Page::tagged', function (HookEvent $event) { $page = $event->object; $fieldName = $page->rootParent->name . 'Tags'; if ($page->template->name === 'tag') { $event->return = pages("$fieldName=$page"); } else throw new WireException('Only pages with tag templates can use tagged property'); }); # EXTRA: A bit of overengineering: change field name when rootParent's name changes // rename tags field depending on its rootParents name wire()->addHookBefore('Pages::renamed', function (HookEvent $event) { $page = $event->arguments(0); // check if page cant have tags template under it if ($page->template->name !== 'listing') return; // check if actually has tags template under it // if(! $page->hasChildren('template=tags')->count) return; $oldFieldName = $page->namePrevious . 'Tags'; $tagsField = fields()->get($oldFieldName); if (!$tagsField instanceof Field) return; /* @var $tagsField Field */ $newFieldName = $page->name . 'Tags'; $tagsField->setName($newFieldName); $tagsField->save(); wire()->message("Renamed $oldFieldName field to $newFieldName", true); }); Thanks a lot for the insight!

Hi @Sebastian. Welcome to the forums. The real answer is that these forms were never intended for use in the frontend. Their purpose and design was for backend use only where trade-offs have had to be made between complying with standards versus delivering a usable and highly efficient UI, taking into account the underlying complexities that constitute the PW Admin. Using them in the frontend is just a bonus, but it comes at a 'cost'. You are probably better off using your own forms, or investing in Form Builder or similar.