Leaderboard

Just a few days before christmas we relaunched our own agency website at schwarzdesign.de using ProcessWire! The old Drupal-based site was getting a bit outdated, we wanted to rebuilt it with fewer, more focused content pages, clean & minimalistic design and better performance for mobile visitors. Note that the site copy is only available in German. After a couple of successful ProcessWire projects such as Engfer Consulting and Joachim Kobuss, we decided to use it for our own site as well, mostly for it's small footprint and developer-focused API. We also have a dedicated ProcessWire page on our new site, check it out here! Modules used ProFields Automatically Link Page Titles TinyPNG Image Compression Color Tracy Debugger Sitemap Duplicator ALIF - Admin Links In Frontend A focus on content We went for a minimalistic approach with a limited set of design elements to highlight our content, which is mostly copy about our services and approach to web design. The two-column layout is built with a single Repeater Matrix section with fields for left and right copy, left and right images and a couple of display options for column width and alignment. Other Repeater Matrix types include a full-width image with some additional links (used on the homepage), teaser sections for current news and projects as well as a list of services. We used dedicated page types (templates) for services, projects and news. This allowed us to use those as taxonomies for our reference projects, and create cross-references to those pages in one go. For this purpose, there's also a dedicated CMS template and pages for all Content-Management-Systems we use, allowing us to categorize our projects and news in regards to the CMS used and show appropriate pages in the recommended content sections. Performance Loading times become ever more important with the rising amount of mobile traffic, both for the bounce rate and for SEO purposes. For client-side performance, we got rid of all external libraries (CSS and JavaScript). All CSS is written in SASS; we use a very stripped down version of Bootstrap 4 that includes only the grid system, the utility classes and a select few of the components. We also avoided the components requiring jQuery, allowing us to get rid of jQuery entirely. The few interactive parts of the site (flyout menus, the theme switch, adding the blur filter for the background image on scroll) are written in simple vanilla JavaScript. Server-side, we use the ProcessWire page cache to minimize server response times, as well as Cache-Control headers and GZIP compression to make sure all assets are as lightweight as possible and cached client-side. One problem we had were the large header images requiring transparency. We ended up combining a couple of approaches to minimize image loading times: SVG assets where possible (for example, all the service pages (Kompetenzen) use SVG for the header images. Responsive images to serve the smallest possible image for each device. PNG compression using the TinyPNG service and the TinyPNG module. This had possibly the highest impact, sometimes reducing the image size by about 80%! Design highlights One of the adornments of the site are the large, variable sized header images. Position and size can be controlled through the backend: We built display settings for size in viewport width or height, vertical and horizontal alignment as well as optional offsets. The header images are fixed to the viewport, so they always stay in the background. The blurred background uses CSS filters, with a fallback to a simple opacity reduction for older browsers. As a gimmick, there is a light and a dark theme for the website, the latter being the default. You can switch between themes using the sun icon in the menu. On the technical sides, both themes have their own stylesheets, compiled using the same SASS source files with different variables. Only the active theme's CSS is directly loaded on the site, the other is included as a preloaded asset. The active theme is saved in the session, so it stays active for the duration of the browser session. For our reference projects (Referenzen), we replaced the background color with the primary color of the project (each project has a color field for that purpose). We determine the luminance of the primary color programmatically to find if the color has higher contrast to black or white, and use the light or dark theme accordingly. Screenshots

On some sites I actually have a "menus" tab on the homepage and in that tab there are two page reference fields: one for top menu and one for the footer menu. This way the site editors can easily adjust which pages appear where and none are shown anywhere by default.

Same here: I usually put those things in a tab on the root page: Rendering the menu is easy: <div> <?= $pages->get(1)->footermenu->implode(" | ", function($p) { return "<a href='{$p->url}'>{$p->title}</a>"; }); ?> </div> Config Settings is a repeater field that populates a custom API variable with site settings: $uk->config->company and branding:

Just guesses and thoughts but... Do you use one of the ProcessWire site profiles or did you build something on your own? Which modules do you use? Did you place custom files within the /wire folder or changed files in there? Did you change the original /index.php or /.htaccess files? Most of the time something like that happens to one of my sites I walk this way... 1. Turn on debug mode /site/config.php <?php //... $config->debug = true; Maybe this already helps or shows more details about that error. 2. Refresh modules & clear compiled module files http://yourdomain.tld/processwire/module/ a) top right corner b) bottom left corner on Site tab 3. Delete other caches ProCache, Template Cache, Markup Cache, whatever server/pw-side cache. 4. Looking into your page template Investigate your code that should have been displayed where the error message starts. Maybe... there is something.

First of all, I would recommend reconsidering your approach. ProcessWire's built-in admin is quite user-friendly, and building essentially the same thing on your own sounds like a lot of effort that you could use for something more beneficial. Not to mention that you'll have to be pretty careful to avoid any permission related issues etc. – all in all not something I would recommend unless you've got a really good reason for it. The answers to your questions, if you still choose to go this route, would depend on your needs: do you have multiple types of users with different fields, or are they all the same? What will these users edit – their own profile page, or something else? If it's their profile page, should it be publicly viewable? If not, how are you planning to control access – on a page by page basis, or based on groups, or something else entirely? ProcessWire supports multiple parents/templates for user pages, so that might be something you could look into: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users. Hope this helps a bit.

A very nicely composed showcase writeup.

Sometimes it's easier to just look at the core code examples. Admin Data Table is used, for instance, on the templates and fields listings. Other times, just look at the class itself, e.g. here for MarkupAdminDataTable Edit: oops, beaten to it by @gmclelland

I've created a set of modules for importing (manipulating and displaying) data from external resources. A key requirement was to handle large (100k+) number of pages easily. Main features import data from CSV and XML sources in the background (using Tasker) purge, update or overwrite existing pages using selectors user configurable input <-> field mappings on-the-fly data conversion and composition (e.g. joining CSV columns into a single field) download external resources (files, images) during import handle page references by any (even numeric) fields How it works You can upload CSV or XML files to DataSet pages and specify import rules in their description. The module imports the content of the file and creates/updates child pages automatically. How to use it Create a DataSet page that stores the source file. The file's description field specifies how the import should be done: After saving the DataSet page an import button should appear below the file description. When you start the import the DataSet module creates a task (executed by Tasker) that will import the data in the background. You can monitor its execution and check its logs for errors. See the module's wiki for more details. The module was already used in three projects to import and handle large XML and CSV datasets. It has some rough edges and I'm sure it needs improvement so comments are welcome.

Hello there, ProcessWire has been the perfect CMS for me so far but I always missed the Laravel way of doing things when working with PW. Therefore I've built a package that will integrate Laravel into ProcessWire. It's already working out really well and I can imagine a lot of stuff to come in future. Anyways I'm hoping for some peoples support / pull requests / ideas / opinions ... Here's the link: https://github.com/hettiger/larawire Enjoy!

I'm not sure about the cause of the problem but I know a good way to get closer to the solution: install Tracy Debugger and barDump the problem variables. bd($os->paymentAmount, '$os->paymentAmount'); My golden rule is: any time something isn't working the way you expect it to, or you don't understand how something is working, or you're just plain curious, then start dumping variables/properties/objects left, right and centre. Best way to advance your knowledge IMHO.

Perhaps it should be: $portfolio_pages = $pages->get('/portfolio/')->projects;

$pages->get->projects; That looks strange to me. Maybe you can look at the examples on https://processwire.com/api/variables/pages/ ? I'm not sure why it worked before?

I understand that you are exaggerating for effect, but your analogy is wrong in several ways. 1. Apart from in kidnapping scenarios, nobody is ever "put" into a helicopter. Rather a person chooses to get into a helicopter. And if an person chooses to get into the pilot's seat and start pushing buttons and pulling levers then it's their own responsibility to handle the consequences. 2. A company that manufactures helicopters usually does not teach people how to fly helicopters. Likewise a company that manufactures hammers usually does not include a brochure explaining how to build a house. It's not really the responsibility of the manufacturer to deliver comprehensive instruction to every person who might come in contact with their tool. Rather (as per point 1) the responsibility rests with the individual choosing to use the tool to pursue their own learning from any sources that might be available. 3. Despite there being no obligation on the manufacturer to produce it, the helicopter we're talking about does in fact come with loads of detailed mechanical documentation, written and video tutorials, demo helicopters that you can take apart to learn from, and a helpful community of pilots and engineers ready to answer questions. So it's not really true that there's only a small brochure that leaves most things undocumented - quite the contrary. It seems that your complaint is that you've found some small behind-the-scenes component (maybe a heated pilot seat that is more of an optional thing than a critical feature necessary for every flight) that is not explained in a way you can understand. 4. Now let's bring into the picture the fact that we're talking about a helicopter that is made available for free. The "company" that has produced this helicopter is actually just a small number of generous people who, after having finished their day jobs, put in unpaid hours to offer helicopters to the world at no cost simply because they want to share the miracle of flight. If after their day jobs and the unpaid time in the helicopter factory there aren't enough hours left in the day for those generous people to also open up a helicopter pilot training academy then I don't think we have much reason to complain about that. 5. The company that produces this helicopter operates on the collaborative open-source model. That means there's an open invitation for anyone who sees potential in the product to participate in adding further value to it. So if you, as an aspiring helicopter pilot, can see that it would be useful for other pilots to have some documentation on the heated pilot seat then you would be very welcome to write up a document and submit it to the CEO. I'm sure he'd be delighted to receive it.

I think you are wrong ? Bringing custom functionality into your PW backend is simpler than you might think: The benefit is that you have ALL the features of PW built in, as @teppo already mentioned. You can build things like this: You should also have a look at RockGrid, if you want to show tabular data: PW is great for building backend applications. The only part that is not so clean/easy is how you handle migrations/upgrades. But that would not be different if you chose to build a custom frontend GUI for your users rather than using PW's backend. I had the same desicion to take before I started with my CRM and I'm really, really happy that I chose to stay in the PW backend.

I would like to inform that my polish language pack was updated to version 1.0.6. This version should be fully compatiblie with the latest master version of ProcessWire - 3.0.123 Download driectly at github: https://github.com/sevenstudio/polish-wire/archive/1.0.6.zip or from the official modules directory: http://modules.processwire.com/modules/polski/

Just create an individual template for that kind of page without a PHP template file.

I was thinking about this too... There was a dev branch that dropped the [file + rules in description] scheme and introduced a fieldset of [rule + (optional) file]. It turned out to be too complicated and it did not work well so I dropped it. An easy solution is to allow source location override. So... see this commit and use the input:location configuration option. Not the best solution as it still requires a (dummy) file to be uploaded (to create the import rules in its description), but it works. You can even use this solution to refer to files uploaded to other pages using this URL scheme: wire://pageid/filename Hope it helps. That's different. It downloads data for a single field (e.g. a file to be stored in a filefield) not for an entire DataSet.

There are many other ways... just a few examples here. 1. Module Menu Builder by @kongondo Create a footer-menu in module add pages or custom links render on the frontend https://modules.processwire.com/modules/process-menu-builder/ 2. Custom page reference field Create a settings template create a footer-menu field (type: page reference) edit settings matching your needs (for example: only certain templates) add field to template add pages to field render on the frontend 3. Static links Just add plain / good old static links to the sites you want to appear there

@Michkael Flexbox (css), https://github.com/liabru/jquery-match-height (javascript).

Never mind - found good description and sample code here: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ Great: @bernhard! The ProcessWire docs definitely need some (a lot) more love regarding module development, samples and descriptions of core features...

See this post. It has some good code comments: and Also check the module's source code. That helped me. https://github.com/processwire/processwire/blob/dev/wire/modules/Markup/MarkupAdminDataTable/MarkupAdminDataTable.module Hope that helps you

Hello @gebeer! I made a convert to object literal on your supposal but it had issue when "JavaScript loading method" was set to:manual (where emo.js is loaded after the inline script block). So script init is now again attached to the window onload event and emo.js can be included at any part of page. Thanks for the report! I also dropped ProcessWire namespace for continued 2.x support, thanks for a remind @Robin S! That was maybe too hesitated and no requirements for it. Version bumped to 1.1.1 and it's available at GitHub: https://github.com/BlowbackDesign/EmailObfuscation/releases/tag/1.1.1 Besides bugfixes this version adds support to multilanguage nosript text and template cache.

@bedak Thanks for your suggestion – happy to implement, but am stuck for time… ? Will open an issue on the repo in the meantime. ? Edit: If you feel you can add this in from your side, feel free to submit a merge request to https://gitlab.com/rockettpw/seo/markup-sitemap

I've created a new documentation page with docsify. I was about to ship standalone markdown files with the module so they could be versioned and read through GitHub (or somehow else). Then I looked at @adrian's docs for Tracy and I liked it, especially the search feature, so I decided to go that route. The next release will contain a major rewrite for filters and macros. They contribute largely to the module's robustness (imo) and I wanted these functions to be available separately too. So there's a new "PWHelpers" class (name is not final) that contains methods that filters and macros are using. This means you can include this class in your non-latte PW projects too and use them if you wish. Another motivation was to make these functions testable which was not possible without this change. I wrote tests for almost every filter and macro. I spent significant time to it (testing is fun :)) and have fixed many bugs. Of course this doesn't mean they are bug-free but they are much safer to use and when a new feature is added I can easily check if everything works as expected (using ProcessNetteTester btw). I was thinking about making this class a separate module but I kept it inside TemplateLatteReplace for now, but I can change this later if there's a need.

@tiefenbacher_bluetomato You can us the following hook to extend the smarty object: wire()->addHookAfter('TemplateEngineSmarty::initSmarty', function (HookEvent $event) { $smarty = $event->arguments('smarty'); // Register your function here });

You can use: $input->post('reset-button') or $input->post->{'reset-button'} This is not a PW issue, but rather a PHP one - you just can't use hyphens like that. That is why PW field names use underscores and not hyphens.

Hello Everyone! I'm new here, just signed up. I've discovered PW few days ago (what a shame...) and I'm angry for myself that I lost several years of my life... I'm a homegrown webdeveloper since 2005, started from pure HTML, then e107, Textpattern and from 2008 I work(ed) only with WordPress. I've made over a hundred of sites. Most of them are simple blogs but my main site is quite large (with over a 10k entries and over 100k of media). It's outdated a little bit so I was planning to modify and refresh it lately but then... Gutenberg happened. Gutenberg as an editor is unintuitive, buggy, produces massive problems and it's incompatibile with most of the things I'm using (it seems to be the same story for hundreds of websites built on WP). And though the whole WP community is frustrated and angry, it's been forced with WP 5.0 as the beginning of rebuilding WP as a platform into... hmm... next Wix? I was trying to discuss - my comments were deleted and my account has been blocked (as many others). After 8 years of developing WP... Well... I've frozen the site for updates and started looking elswhere. I have few advanced demands so tried Drupal, then played a little with Craft, Codeigniter and Laravel (I'm not a programmer per se). And after few recommendations I've finally found You. Guys... I'm so thrilled and emotional. I can't stop reading and following tutorials on localhost. PW is THE TOOL I was searching my whole life! I'm going to study everything very carefully and next year I'm going to rebuild slowly (there's no rush) my main site with PW. Back to Gutenberg: I understand where it aims to be and what it tries to accomplish BUT this is wrong on so many levels. As far as I can see, a barebone PW installation is far more flexible and useful then WP with 30 plugins. And obviously you know it perfectly. So I'm begging you: no Gutenberg here... ? Cheers to Ryan and Everyone! Greetings from Poland!

That's likely not going to be trivial. Adding check_access=0 in a selector to display the link is quite another thing as serving the secure file to a guest user. When you have pageFileSecure enabled, the following happens: PW prefixes the file directory site/assets/files/[PAGEID] with $config->pagefileSecurePathPrefix ("-" by default so it will be site/assets/files/-[PAGEID]) When the browsers tries to show the image (i.e. open the URL /path/to/pw/site/assets/files/1258/image.jpg in a separate request), the file isn't found by .htaccess .htaccess hands off the request to index.php index.php calls PageRender::execute with the request URL PageRender::execute checks if the request is to a file, then checks if the page it belongs to is published and viewable by the current user Since $user->hasPermission('page-view', $page) returns false (the guest user doesn't have view permissions) that fails (otherwise, PW would prefix the path now and output the file) PW outputs the 404 page Since the method where the check is are done is not hookable (and some necessary properties and methods are protected, i.e. not reachable from a hook) you'd probably have to hook before ProcessPageView::execute and duplicate a lot of code from ProcessPageView or hook after User::hasPagePermission and at least duplicate ProcessPageView::checkRequestFile in both cases, match the file URL to $page->image to prevent handing out a access to other file/image fields on the page Another approach (if the images aren't too big and the protected pages aren't too many) would be to include the real image data as data URIs: <?php foreach($protected_pages as $protected_page) { echo $protected_page->title . "<br>"; $fn = $protected_page->image->filename; $imgdata = "data:" . mime_content_type($fn) . ";base64," . base64_encode(file_get_contents($fn)); echo "<img src='$imgdata' alt='{$protected_page->image->description}' />"; } If the images are small enough but you have many pages, using PW's pagination might be an option too.