Leaderboard

https://www.kaumberg.gv.at/ Hello everybody! Today I want to share a project that I've been working on for a year or so: The new website for municipal Kaumberg - a beautiful village near Vienna. To be honest, this project was way more work than I initially expected. The site has tons of content and the client came with lots of good ideas during the process of building this site. For example after we launched the site several organisations of the village realized that the system works great and is easy to use, so they wanted their own section with their own color scheme... Right now the system is maintained by several user accounts that populate content to the site. Some of them only in the news-section, others are allowed to publish to the sub-sites (eg for the fire department). Recently we won the 2nd price out of 190 cities in lower austria - where Kaumberg was by far the smallest one also having the smallest budget of the top rated cities! ### NOTE ### This system was built with scalability in mind. If you know any other municipals (preferable in a german speaking country) that could possibly need a new website using my setup write me a PM. If you are a marketing guru and know how we can sell this product to 100s of municipals, let me know. I know how to do that from the technical point of view ? ### HIGHLIGHTS ### CONTENT Custom multi-level menu for managing loads of content pages that also works well with keyboard navigation ? --- EVENT MANAGEMENT Events are managed via the PW backend and presented as calendar on the website plus can be downloaded as PDF calendar in A3 format for printing: --- CONTENT BLOCKS I've developed a new (private) module called RockMatrix for versatile, easy and fool-proof content creation for this project. This setup ensures that even non-tech-savvy users can create content that looks nice and works on all devices from desktop to mobile: --- SITE SEARCH Another new module that was developed for this project is RockSearch. I hate site searches that do work on the first sight but do not on the second. For example if they show older results on top of newer ones. Or if they do not index content that is not stored within a regular text field but for example as image description. On the other hand I did not want to use ElasticSearch because it seemed to be overhead to send data to another service that is already stored in the database of my PW installation... RockSearch shows results based on different weighing mechanisms, for exampe a search for the garbage collection schedule first shows results that are nearer to the current date than others (both future and past). That means that a date two days in the future will be shown above one that is 10 days in the past. Also results get different score based on where the term was found - matches in the site title get higher scores than matches in the body or in image descriptions or the like. Each content block is a RockMatrix block that has a render() method to define the output on the website and - for RockSearch - has a method called "searchIndex()" that defines the content that is written to the search index that is queried for every search request: This setup makes it super easy to add new content elements and to add them to the search index ? --- SUB-SITES The client can create sub-sites for different organisations of the village having custom color schemes and managing user access: News can be tagged to show up on different areas of the website: --- OTHER The site uses no cookies and can therefore be used without an annoying cookie banner. Page hit statistics are gathered by PageHitCounter and shown by RockHitCounter Some other little features are short-links for social media (eg https://www.kaumberg.gv.at/goto-1027 ) or the possibility for creating custom subdomains for sub-sites like http://araburg.kaumberg.at/ I'm quite sure I forgot lots of great stuff, but I hope you enjoyed reading this article nevertheless ? Looking forward to your feedback!

In site 1, I'd guess that there's a spot where you're missing quotes in $_SERVER['HTTP_HOST'] (i.e., $_SERVER[HTTP_HOST], which will with strict mode turned off interpret HTTP_HOST as the name of a constant in the current namespace). The error in site 2 points to a missing pdo_mysql extension, so make sure that it's activated and enabled in php.ini.

Just to add to the reports, I have coincidentally encountered this issue just minutes ago and thankfully remembered this thread. Bernhard’s/Robin S’s fix worked for my image. It was EXIF orientation 6 (confirmed this to be in line with the specs. 90° CW to make it upright), shot on some old-ish Samsung phone and uploaded without client side resizing. The original showed up fine, but the generated variations were upside-down. Thanks!

This doesn't indicate a properly working Apache for all scenarios at all. It's just the most basic startup screen you could imagine for LAMP setup. So... you installed everything in just one folder (/var/www/html/PROGRAMMSUBFOLDER)? No... set up VirtualHosts. That's a one-time-investment in a solid dev environment. From there... you could go in any direction. With ProcessWire, WP, Drupal, Typo3... whatever. That's the default behaviour when installing ProcessWire into a subfolder. While it works... I wouldn't recommend it. Only when you really know what you are doing, testing for example, or when you already installed Processwire 100 times. ProcessWire was ready to go. Your setup wasn't. Sorry when this sounds a bit rude but using a non-working or better to say not fully configured environment as a base for whatever kind of (web-) development and then blaming the software because it doesn't like it that much... is unfair. I can't and won't blame you but I want to move your focus to the reason for your experience here. It wasn't ProcessWire. Sure installation is sometimes a bit more than just clicking but in this case there were way more steps than really necessary. In case you want to experience a super solid installation that's a breeze... use something like Laragon on Windows, MAMP on Mac or ... let's skip the Linux part here. One last word here: Even though my response here could be read a bit harsh... I really appreciate that you stayed the whole way, worked through everything from start to finish. And I wish and hope you start to love ProcessWire like each and everyone here in this thread and community.

PageMjmlToHtml Github: https://github.com/eprcstudio/PageMjmlToHtml Modules directory: https://processwire.com/modules/page-mjml-to-html/ A module allowing you to write your Processwire template using MJML and get a converted HTML output using MJML API. About Created by Mailjet, MJML is a markup language making it a breeze to create newsletters displayed consistently across all email clients. Write your template using MJML combined with Processwire’s API and this module will automatically convert your code into a working newsletter thanks to their free-to-use Rest API. Prerequisite For this module to work you will need to get an API key and paste it in the module’s configuration. Usage Once your credentials are validated, select the template(s) in which you’re using the MJML syntax, save and go visualize your page(s) to see if everything’s good. You will either get error/warning messages or your email properly formatted and ready-to-go. From there you can copy/paste the raw generated code in an external mailing service or distribute your newsletter using ProMailer. Features The MJML output is cached to avoid repetitive API calls Not cached if there are errors/warnings Cleared if the page is saved Cleared if the template file has been modified A simple (dumb?) code viewer highlights lines with errors/warnings A button is added to quickly copy the raw code of the generated newsletter Not added if the page is rendered outside of a PageView Only visible to users with the page’s edit permission A shortcut is also added under “View” in the edit page to open the raw code in a new tab Multi-languages support Notes The code viewer is only shown to superusers. If there’s an error the page will display: Only its title for guests Its title and a message inviting to contact the administrator for editors If you are using the markup regions output strategy, it might be best to not append files to preserve your MJML markup before calling the MJML API. This option is available in the module’s settings. If your layout looks weird somehow, try disabling the minification in the options.

Thx @Stefanowitsch It's a module based on the core repeater fieldtype that manages the necessary templates and fields for content blocks via RockMigrations. Every block is a custom ProcessWire page having a custom template. The matrix field: Each block itself looks something like this: ...which makes it extremely easy to work with on the backend and to organize code well. That means each content block has its own file that defines all the necessary pieces, eg which icon and description to show for the button, which label to use on the sortable matrix field and which code to use for output rendering: Only drawback is that it does not support nesting yet - but I'm not sure if that is really a drawback because I don't think the average user would understand how to use such a feature...

I've had to deal with this issue today and I tried my fix from last year and unfortunately got wrong results as well ? I'll send you the image via PM @horst

The features are awesome. That's a really inspiring project! How did you approach your custom "Repeater Matrix" solution? I made a custom form builder solution by myself to easily create any kind of formular with the help of Processwires "classic" repeater fields. Instead of those fancy repeater matrix buttons (they look really good) you can select your form element via a dropdown. When you have a content-heavy site I think such a repeater matrix like yours is the best solution.

That's it! Thanks. I owe you a beer ?

I guess because you are in a module you have output formatting OFF which means that $page->image is an array of images and not a single PageImage object. Using $page->image->first()->size should work. PS: To make everything clear and reduce chances for errors you can be more verbose and use $page->getUnformatted('image')->first()... PPS: Better check if an image was uploaded before using ->size(...) $img = $page->getUnformatted('image'); if($img AND $img->count()) { $img = $img->first(); $img->size(...)->... }

Thanks muchly @BitPoet! The first was rather obvious - should have spotted that! The second was more subtle. Inspecting the php.ini from the laragon panel, it looked ok. Opened it directly in an editor and the extensions clearly weren't enabled. Odd, but all working now, thanks.

Umm yeah I mean did you run that code? From the looks of it I would say it should rain errors, but if it works for you, that’s great! Allow me to step through and critique it anyway: $this->addHookAfter("ProcessPageAdd::buildForm", function(HookEvent $event) { //get the result of the hooked method, which is a form (class InputfieldForm). //it’s also the only form we care about here, so calling it $form is fine. $form = $event->return; //this gets the parent page, so we can stop doing anything unless we are //at the correct position in the page tree. good. //note the indent I added, though ;) $parentField = $form->getChildByName('parent_id'); $parent = pages()->get($parentField->value); if (!$parent->matches('template=dashboard_customer')) return; /*this is going to error, because $page does not exist here. you CAN *call the current page by writing any of this instead of $page (you *don’t WANT to do that here, though. read on before you change this): * - page() (if you have functions API enabled in config.php) * - wire('page') * - $wire->page * - $this->page * - $this->wire('page') *see https://processwire.com/docs/start/api-access/ *since this is confusing and for all other reasons stated in that link *i would recommend simply always using page() etc. */ $pageid = $page->id; /*this is just weird and unnecessary unless your template labels contain *slashes and end in .php, which in itself seems weird and unnecessary? *if you want a template’s name (usually the same as the template file *without the extension), just use $template->name. * ===> importantly, none of this makes sense because when this code runs, you <=== * ===> cannot know the page’s id nor its template!!! <=== * ===> you want to give the page ITS OWN id for a name. this is impossible to <=== * ===> know at this time, as the page has not been created yet. the template, <=== * ===> likewise, has not been chosen by the user. this code BUILDS the drop <=== * ===> down field that lets the user choose a template! <=== */ $template = basename($page->template->label,'.php'); //this was my suggestion to get the page name field from the form, however, //as we see below, you have discovered a better way, which is great! $nameField = $form->getChildByName('_pw_page_name'); //this was my suggestion to make the field invisible. as you’ve discovered, //you could also use $nameField->collapsed = Inputfield::collapsedHidden. //there is a difference, though! AFAIK, Inputfield::collapsedHidden will //completely REMOVE the field from the form output, so you can’t change it //with javascript. that was my main reason to use the class instead, //because you may actually want to do that. $nameField->wrapClass = 'InputfieldHidden'; //this shouldn’t work because of the $page business above. I guess it will //result in "() " because neither $pageid nor $template can have any //reasonable values. //moreover, you can’t use parentheses or spaces in page names, so they will //get stripped or converted to - anyway. remember this is the page name, not //the title. $nameField->value = "($pageid) $template"; //this is unnecessary because we have already put $event->return into the //variable $form. $titleField = $event->return; //this is great, but you should remove the above line and use $form instead. if(!$titleField->has('title')) return; //this is a great way to get the title field from the form! also a great way //to get rid of it. it will still allow you to put a value inside at this point. $titleField->title->collapsed = Inputfield::collapsedHidden; }); Now to do what you really want, you need to hide the fields you want to hide in this ProcessPageAdd::buildForm hook and use an additional hook to set the values. That second hook will have to run at some point when all the things you need to generate those values are known. Since you want to use the page id (there is no real reason to have the page id in the name that I can think of!), that point has to be AFTER the page has been saved. That’s fine, but if you contented yourself with just the template name + a number generated by PW, you could use the Javascript option I suggested above and obviate the second hook. It’s no biggie either way, so whatever. You could hook Pages::added, making your entire code look like this: $this->addHookAfter("ProcessPageAdd::buildForm", function(HookEvent $event) { $form = $event->return; $parentField = $form->getChildByName('parent_id'); $parent = pages()->get($parentField->value); if (!$parent->matches('template=idee')) return; //using the neater way to edit the field! $form->_pw_page_name->collapsed = Inputfield::collapsedHidden; $form->_pw_page_name->value = 'this is a temporary name nobody should ever see, just leave it'; $form->title->collapsed = Inputfield::collapsedHidden; //no default value for the title }); $this->addHookAfter('Pages::added', function(HookEvent $event) { //this time, we can get the page that has just been created! $page = $event->arguments(0); //same as above: only run under certain parents if (!$page->matches('parent.template=idee')) return; $page->setAndSave('name', "{$page->id}_{$page->template->name}"); });

Wow! Well, that was a can of worms I opened! ? OK, let me come clean and say that I have actually tried - many times! - to load PW on various platforms before. Always Linux based - and let me also say that I have never succeeded. I'm not really interested in a Laragon - Windows approach. I really wanted to get it to run correctly on a Linux based platform. I've tried nginx as well as Apache as the server platform, and neither have set up correctly despite following all the comments and suggestions (except, as I've said before, the 'unzip software' which is, I believe classed as a 'nice to have but not essential'. This time, after yet another frustrating and initially unsuccessful attempt, I thought 'b***r it - I'm going to see what the community can make of this!' Now, despite comments about everything in the one folder, that is NOT how I have things set up. I have an 'index' file in the /var/www/html directory that links to a number of useful applications - node-red; php-lite-admin; webmin etc and these are, of course, in their own sub-folders. And work!! The obvious, and apparently sensible approach, with PW was to put this in a sub-folder, too. No-one ever suggested that wasn't the correct approach! My comments are, then, based on an actively and apparently correctly working web-server and a - supposedly - fool-proof and 'simple to install' CMS and, I'd still argue it wasn't. OK, I accept that my server knowledge isn't that of a professional web designer - but I was 'encouraged' that that wasn't apparently necessary with PW. And, yes, a knowledge of virtual hosting is something I could obviously improve on. But - and I reiterate - that isn't what PW advises me. It tells me 'you are ready to go!' and yet only the front page shows. Now, OK, thanks to the patience of many people here, I ultimately get it working - and I understand the comment 'it wasn't PW - it was your server set-up' because clearly PW was ready to go....but only after making Apache changes. And I'd argue that PW could have better informed me that would be necessary. I really like Jan Romero's remarks, and agree that PW, whilst good, could be made better for less experienced users with an unblinkered look at the install process. And - if that takes place (and it would have to be by persons far more experienced than me!), then.....well, I may have achieved one of my unstated objectives! Thanks again for all the patience, comments and advice - Mike

I agree wit wbmnfktr, however, I also tend to agree with OP that the installer could be made more fool-proof. We’ve had a lot of threads over the years with people getting 500s trying to access the Admin (or anything other than the front page) right after installing PW. OP’s case may be especially niche, but .htaccess adjustments to get PW running aren’t really. It might be a good idea for the installer to ping the chosen admin URL and display a warning with some instructions if it doesn’t get a 200. Also, from a UI perspective, looking at this screenshot I just see a bunch of tick marks. We all know users don’t read anything you put in front of them, and this only encourages us to believe no further action is needed. IMHO, the “Complete & Secure Your Installation” section shouldn’t have check marks. Maybe it should even be a different color to emphasise its to-do-list nature and differentiate it from the mere success messages. “Get Started” is mostly to-do as well, albeit more optional.

I can confirm this! Tested on 3.0.189-dev and 3.0.190-dev so far.

Fixed! And published! Keep the edge cases coming ?

That looks way better and works almost as expected... at least in the frontend. Trying the EDIT page option results in an error. Full error:

I just published the new release! In the end I added a condition checking ProcessWire's version and calling the `getPage()` replacement, which uses a new `$pages->request()` method. Let me know if you notice anything else!

The first part with the errors on initial save has been solved but I still need to find an alternative for the second part. In more recent dev versions Ryan removed a function I was relying on in my code (namely ProcessPageView::getPage) and I need to look for an alternative. I'll publish an update once it's all good.

ProcessWire 3.0.190 has 15 commits relative to 3.0.189 and contains a mixture of issue resolutions and feature additions. We’ll review these below, in addition to updates for the PageAutosave and ProFields Table modules— https://processwire.com/blog/posts/pw-3.0.190/

If you want to have a bit of fun, I recommend the EXIF specs: 2.3 (2010) 2.3 (2012 revision, including fixes in the orientation part) 2.31 (2019) All of them say of orientation 8 “The 0th row is the visual left-hand side of the image, and the 0th column is the visual bottom,” so 90° CCW seems correct. Further down you can find such gems as “Orientation = 8 is equivalent to an arrangement that is turned Orientation = 3 90 degrees clockwise”. Skip to Orientation 3: “Orientation = 3 is equivalent to an arrangement that is turned Orientation = 6 90 degrees clockwise” … “Orientation = 6 is equivalent to an arrangement that is turned Orientation = 1 90 degrees clockwise”. Right. Thankfully, Orientation 1 is self-sufficient: “Orientation = 1 is created when 0th row of the coded image data stored in the Exif image file and the visual top of the display screen, and 0th column and visual left, will each be matched for display”. Hooray. I feel like I’m in an escape room.

Hey @horst — sorry for pinging, but I'm pretty sure you're most likely to know what's going on here ? So, I've been having similar issues with one site, where there are a lot of profile pics etc. Quite often uploaded images are not correctly rotated by ProcessWire. It's not super common issue, but common enough to cause major problems for admins. Now, one pic which I'm currently testing (I can share a link if it's important) reports EXIF orientation as 8: Based on our built-in corrections array, orientation 8 should be rotate 90 degrees (clockwise, I presume). Based on some other sources, such as https://www.impulseadventure.com/photo/exif-orientation.html, orientation 8 actually requires 90 degrees CCW (or 270 degrees CW). Am I reading that source wrong, or is there a mistake? The array provided by @bernhard fixes the issue for me, and seems to be in line with at least that single source. I am not well versed in this topic, so be kind; I may be entirely missing the point here ?

Well Rick and Chris - some amazingly good news at last!! Rick - Apache worked perfectly. Default page etc. after installation. I've loaded some programs with an associated 'index' file and these all worked perfectly, too. And I did load PW as suggested fixing every problem (bar the lack of zip) as it occurred. This was my frustration - PW indicated that it was 'up and good to go'. Except it clearly wasn't!! Then as suggested I 'fixed' the 000-default.conf file and this led to the error I indicated (and which Chris has kindly commented on). There was another issue with this - I was no longer able to call up the index file that showed my applications. So, I changed the config file setting to read DocumentRoot /var/www/html (removed the pwire directory) and same for <Directory /var/www/html/........ I also commented out the entire rewrite options in.htaccess And as if by magic, it all works!!! Using the 'vanilla' IP address of the server shows me my index file and associated applications. Adding /pwire to the URL takes me to the PW home page - and all the links work! Login to admin; site map; about - whoopee!! ? Now, as fantastic as this is it would have been nice if PW on installation, had 'warned' me that I might need to fix an Apache config file and not left me wondering why this "easy to use" CMS wasn't...... But there we are. Thanks a million to all the patient and very helpful contributors. Very much appreciated!

This is potentially progress, as it suggests ProcessWire is at least being given control. ProcessWire throws an internal server error instead of displaying a message if something went wrong. Maybe check site/logs/errors.txt or exceptions.txt also, if you haven't already, in site/config.php add $config->debug = true; as that should display errors.

Your default apache config file (000-default.conf) should look similar to this... <VirtualHost *:80> #ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www <Directory /var/www/> Options -Indexes +FollowSymLinks -MultiViews AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> The file you posted is missing elements and has elements assigned incorrectly. The DocumentRoot value should be the location where PW was installed (/var/www/html/pwire). Note there is no slash at the end. Your file is missing the <Directory> element. This value should be the location where PW was installed -- Including the trailing slash. Read through this... apache docs

OK, and thanks to everyone for taking the time to assist me. It is really appreciated! A couple of things. BillH - thanks for the explanation of putting random text in the .htaccess file. That makes sense when explained. So I tried random text in the .htaccess file that is in the /var/www/html/pwire/ directory. Restarted Apache; cleared the cache and tried loading. Nope - loaded the page a treat! So then I tried the other .htaccess file that is in /var/www/html/pwire/site/ directory (and recall that pwire is the directory I set up for PW). Same thing. So does this indicate that neither are being 'read'? And if so - why? And which is the 'important' one? Or are they both important? Next, I took note of Jan Romero's comment and commented out the first and third RewriteBase lines. Doesn't make a scrap of difference!! But thanks for the comment, Jan. And now, wbmnfktr who kindly requested I post my host/vhost configuration file. Well, I'd absolutely love to - but I haven't got one!! I'm guessing it would be somewhere in the /etc/apache2/ directory? I've got 6 sub directories - conf-enabled and -available; mods-enabled and -available and sites-enabled and -available - and three files: apache2.conf, envvars and magic. And try as I may, I cannot find a hosts or vhosts configuration files. Should there be - and if the answer is yes, then shouldn't PW have set them up them during installation? There were no 'errors' thrown during installation that they were missing or that the directory couldn't be written or something like that? Is this a failure on the part of the installation process? Ahhh! I've just found something!! In sites-enabled, there is a configuration file 000-default.conf and it contains the following: <VirtualHost *:80> # The ServerName directive sets the request scheme, hostname and port that # the server uses to identify itself. This is used when creating # redirection URLs. In the context of virtual hosts, the ServerName # specifies what hostname must appear in the request's Host: header to # match this virtual host. For the default virtual host (this file) this # value is not decisive as it is used as a last resort host regardless. # However, you must set it for any further virtual host explicitly. #ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/html # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, # error, crit, alert, emerg. # It is also possible to configure the loglevel for particular # modules, e.g. #LogLevel info ssl:warn ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been globally disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf </VirtualHost> Could this be what we are looking for? Then why the name 000-default.conf? I suppose I could say that the plot thickens!! ? Thanks again for all the help!

Can you please post your Apache2 host/vhost configuration file. Especially the <Directory ...> part could be interesting - as this is crucial in most cases. My configuration looks like this: <VirtualHost *:80> ServerName pw.test ServerAlias www.pw.test pw.test DocumentRoot /home/YOURUSERNAME/www/pw.test <Directory /home/YOURUSERNAME/www/pw.test> AllowOverride all allow from all Options None Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/pw.test-error.log CustomLog ${APACHE_LOG_DIR}/pw.test-access.log combined </VirtualHost>

You ask about the method of writing gibberish into .htaccess that @elabx mentioned. The technique is to write a few random characters into the top of .htaccess, and then see if you get a 500 error. If you don't, .htaccess is not being read.

Looks like you uncommented all RewriteBase lines. AFAIK you can only have one. Probably only the last one will have any effect, but you need the one in the middle. Try putting the #s back in the first and third RewriteBase. If it still doesn’t work, maybe paste your entire .htaccess here?

This does seem like an issue with htaccess not kicking in or mod_rewrite, does writing gibberish on the access throw an error? Cheap trick to see if it works ha! ?

Does your Apache install have mod_rewrite enabled? If the home page is loading, but no other URLs are working, it sounds as though URLs are not being parsed. Also check permissions and ownership on directories and files. Directories should be 755, files 644.