Leaderboard

This week we've got a pretty major upgrade to our page finding selectors that we think you will find useful in a lot of cases! Now you can accomplish much more with less, and this really brings our selectors to the next level. https://processwire.com/blog/posts/pw-3.0.25/

Hello folks I made this simple tutorial of explaining my methodology when creating a PW system. https://medium.com/@clsource/understanding-processwire-templates-fields-and-pages-201aecd0a1a4#.osipvjevk

Right now I am not particular proud of myself, because I maybe had the first occurrence of an hacked ProcessWire installation known to mankind. But not because of ProcessWire itself, but of a stupid mistake I have made. Anyways I want to share my case here: Over one and a half year ago I developed a medium sized website with ProcessWire 2.6.1 for a small community. In the process of releasing the site I had troubles with getting the installation to run on the shared hosting webspace. Because the hoster hadn't configured their file permissions correct, I was forced to loosen up the file permissions inside the site/assets-folder. Because I was desperate and wanted the installation to work I ended up setting every file and folder permissions inside the folder assets to CHMOD 777. I wasn't very happy with this solution and now I know how stupid it was, but I didn't knew better and at least the installation was running. This week I wanted to make a small change to the site and noticed something strange: There was a file called sites.php inside the root folder. At this moment it was clear to me, that my installation was hacked. I immediately downloaded the whole infected installation and compared all files with my local clean installation using a diff tool (Kaleidoscope). After comparing I noticed that inside the index.php one line was inserted which included a functions.php inside the site-folder. Also I noticed that inside the site/assets/files-folder there were several php-files uploaded with the same naming convention like the generated images variants (f.e. filename-large.jpg). So what did those scripts do? Luckily not much, that is the reason I haven't noticed this hack for a long time. The database is as far as I can tell not corrupted and the site was still working properly. All those scripts were doing, was generating spam aliases and redirecting to a medical shop site using the http host of my site. Interestingly on my research I have found out, that most of those malicious scripts were intended to infect Drupal and WordPress installations. A few of those files inside site/assets/files are explicitly targeting WordPress specific functions. If you are interested I can share those scripts for further investigation. But I am not sure if uploading those scripts directly to this board is against the board rules, so if I should upload them to a external service, I am willing to do so. Meanwhile I am confident to have cleaned the site from almost all malicious scripts (I will investigate further) and I am still removing all spam search results from Google using the search console. Also I am in contact with the hoster and try to sort things out, even if it means switching the hoster (which I would prefer). Please don't be to harsh with me. I know I have made a stupid mistake and learned my lesson the hard way, but I wanted to share this story anyway to prevent others from making the same mistake. So always make sure to secure your file permissions! Regards, Andreas

And here is how you'd really make classes for pages which can hold custom methods: https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/

Launched phase 1 of a new site. Still working out a bunch of details, poco a poco. http://vacuumwholesalers.com Modules include MarkupSimpleNav Form Builder Lister Pro Pro Fields

A quick update folks. A member of the forums has reached out and offered their services so perhaps you'll see our return to ProcessWire after all. We shall see.

I thought I'd chime in and answer some questions first and foremost as I saw people chatting about this here. We initially moved because we wanted to add some functionality that would have cost too much to develop. My biggest issue myself is that I am not a developer (i'm a tinkerer) and I wanted more advanced product pages, etc. Yes, they could for sure have been built in processwire but I felt that for someone like myself who is not a code guy, I was too limited by the product as I simply don't have the time to learn enough PHP to code and hiring a developer to do work i could theoretically do myself with wordpress seemed like a waste of money. So those were the initial motivations for moving. Now that we've moved, however, the whole "grass is greener" effect has faded and I have some regrets, however, the extra functionality has allowed us to make more sales and bring on new customers that we didn't have before. So it's a catch 22 for me. I'll expand more on this further down. I don't think this is a fair statement, frankly. The initial point of our website was to view things from an end users point of view, not that of a seasoned developer. Our reviews don't go into how easy it is to code with something but rather how easy it is to use, how functional, etc. These are the things most of our readers want to know as we tend to get a lot of traffic from those who are looking for software but don't have a development background. Yes, this grade sucks. Part of the issue for me is again, I'm not a developer so we clearly need to work on things. This is good to know, please do tell me what specifically you feel is missing so we can fix it. ProcessWire is an awesome product and Ryan did a ton for us. Ideally, I would have loved to have simply paid him to make everything we have now work on PW. If that was a possibility and the cost wasn't too high, I would have gone that route. Sadly, it just isn't feasible sometimes and I often look for alternative ways to compensate those who work for us. Before our move to WP, the intent was to search out vendors who were willing to take on the task of building our site on their platform in exchange for an agreed upon advertising term. In other words, they build our site on their platform (which is a bonus as then their product gets noticed more, as was the case for processwire) and in exchange, we offer advertising for an agreed upon term as the form of payment. With the case of PW, however, this didn't work and we needed to pay for the development costs up front which, while worth it since Ryan is so awesome.. tend to get costly when every tweak needs a developer. If I'm able to find someone with a development house who wants on the advertising in exchange for work method, I may be able to pull off a move back to PW but until then, I may have to search out other alternatives. Fortunately, there are plenty of companies that are interested in doing this but I'm picky so moving is a decision that I need to consider deeply. Normally I wouldn't share these kinds of details to this extent but I feel I owe this community, which we've been part of for a long time, an explanation. So here's the pitch: If there's anyone out there who wants to take on the task of making what we need a reality and getting long term advertising for their business in exchange, drop me a line. Until then, the search for an alternative may continue as WP simply seems to be causing too many issues and bloat (I should have seen this coming granted but hey, nobody's perfect and a critic isn't always right). Thanks for reading Mike

@cmscritic Hey Mike, The fact that you can drop in and share with us so much about your reasons for the move says a lot about you. I like that; I respect that. As others have said, we've also gained a lot as a community from your collaboration with Ryan: Hanna Code, the awesome CMS Critic development write-up, and who knows how many people have found ProcessWire because of your site . So, thanks for the ride... Best wishes for the future.

Thank you, I haven't used CSRF protection until now but will try to implement it into the login form. As for the SSL certificate I am almost sure that this hoster doesn't support ssl certificates. Let's Encrypt is awesome though, I already tried it myself in private. There are maybe some more potential risks other than the file permissions I have to investigate. Maybe I will ask @ryan if he could take a quick look, but as this goes too much into details, I hope you can understand that I can't share more at the moment. If I find out what caused the attack, I will keep you updated.

It's a real shame that your site got hacked, but this is definitely something we can learn from, so thanks for sharing it. Shared hosting and lax file permissions are an easy way to get into trouble, but I'm still quite curious about how exactly the site was hacked. From what you've mentioned here (uploaded files, etc.) it kind of sounds like the login credentials might've been compromised, or did you perhaps have something on the front-end that could've caused that? Of course if it really was an "inside job", i.e. if the site was attacked by another user on the same shared server, the files inside /site/assets/ could've been planted there manually. Did you have anything else installed on the same hosting account, another site or web application or anything? If you do find out anything else, please let us know, but just in case: if it turns out that this was actually a result of a flaw in the system itself or perhaps a third party module, please let Ryan know of it before posting to the public forums. I'm extremely confident in the security of the core and have a lot of trust in most of our third party modules, but there's no guarantee that nothing will ever go wrong.

Hello, A solution should be to bootstrap ProcessWire, coding a function which list the all the files in the current directory and subdirectories. Also, writing a custom function give you full control over the listed files, by example, filtering the files by a given allowed extension. You can test the following: In your /test directory, create a file called index.php. In the index.php write the following the code : <?php include("../index.php"); // bootstrap ProcessWire function scanDirectories($dir, $allowext, $recurse = false) { $retval = array(); // add trailing slash if missing if(substr($dir, -1) != "/") $dir .= "/"; // open pointer to directory and read list of files $d = @dir($dir) or die("Error: Failed opening directory $dir for reading."); while(false !== ($entry = $d->read())) { // skip hidden files if($entry[0] == ".") continue; if(is_dir("$dir$entry")) { if($recurse && is_readable("$dir$entry/")) { $retval = array_merge($retval, scanDirectories("$dir$entry/", $allowext, true)); } } elseif(is_readable("$dir$entry")) { $ext = substr($entry, strrpos($entry, '.') + 1); if(in_array($ext, $allowext)) { $retval[] = array( "name" => "$dir$entry", "type" => mime_content_type("$dir$entry"), "size" => filesize("$dir$entry"), "lastmod" => filemtime("$dir$entry") ); } } } $d->close(); return $retval; } ?> <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>Files list</title> <style type="text/css"> body { padding: 5%; max-width: 1260px; margin: 0 auto; } table { width: 100%; border-top: 1px solid #000000; padding: 0; margin: 0; vertical-align: middle; } th, td { text-align: center; border-bottom: 1px solid #000000; border-left: 1px solid #000000; padding: 0; margin: 0; } th:nth-last-child(1), td:nth-last-child(1) { border-right: 1px solid #000000; } </style> </head> <body> <h1>Files list</h1> <?php $rootdir = './'; // root directory $ext = ['jpg', 'png', 'pdf']; // allowed extensions $dirlist = scanDirectories("./", $ext, true); // output file list as HTML table echo "<table cellpadding='0' cellspacing='0'>\n" . "<thead>\n" . "<tr><th></th><th>Name</th><th>Type</th><th>Size</th><th>Last Modified</th></tr>\n" . "</thead>\n" . "<tbody>\n"; foreach($dirlist as $file) { echo "<tr>\n" . "<td><img src='{$file['name']}' width='32'></td>\n" . "<td><a href='{$file['name']}'>". basename($file['name'])."</a></td>\n" . "<td>{$file['type']}</td>\n" . "<td>{$file['size']}</td>\n" . "<td>".date('r', $file['lastmod'])."</td>\n" . "</tr>\n"; } echo "</tbody>\n"; echo "</table>\n\n"; ?> </body> </html> Copy/Upload now some images or files in /test and visit your site at http://mysite/test/ to see the result. @Karl_T code updated.

Aligator (wip) Processwire Module to render a nested tree starting from a single root or an array of pages. Aligator is similar to MarkupSimpleNavigation but has a different approach of how to define the markup for your menu. It doesn't assume any markup or classes. It's up to you to define them where needed. It's less plug and play and requires some more advanced knowledge of ProcessWire, as some additional setup and coding is needed. But allows for powerful and easier customization without using hooks. Aligator uses callback functions to achieve this. Additionally a selector can be used to filter the children for your navigation. Note: This module is a fun project trying to find simple configurable method to render navigations. It's a work in progress and there might be major changes to how the module works. See further infos and examples on the repository: https://github.com/somatonic/Aligator

This could mean that *all* users on the system have read and execute permissions on your webroot, which would be very bad indeed. Though this doesn't allow everyone to write new files in your webroot itself, as long as you have a writable directory inside executable one, those users *will* be able to write and execute files there. This, in turn, would give them just about everything they need to compromise your site. Of course this still depends on them having similar access to the directory your webroot is in, and the host not having implemented proper chroot / jail method. I can recall some vulnerabilities that have allowed users to break out of a chroot jail, so it's not exactly 100% reliable method either, but as long as the server is kept up to date it should prevent most issues like these.

There are two potential issues here: your form doesn't seem to have CSRF protection in place and the lack of HTTPS connection would make it possible for someone to grab the credentials from a request, but other than that this looks fine to me. My usual advice would be not to do this (use built-in login form instead), but of course there are cases where you don't want to do that. For those cases check this post out for the CSRF protection and enable HTTPS. If the price of the SSL certificate is an issue, check out Let's Encrypt; their free certificates are pretty awesome. If your host doesn't allow you to use these, that in itself could be a good reason to switch hosts.

The file permissions for the webroot are 775 which is almost as bad.

You should validate the user input using $sanitizer and use CSRF in the form.

Excellent update! Thanks Ryan!

I think you need explicitly set: Options Indexes to allow it, and not to disable it. But it also can be that on this (shared?) host, you have no rights to change this. Just try if it work or contact the hosting support if they can enable it.

A personal thank you for these tutorials making how to structure in processwire easier understandable.

hi adrian, new website, first module installed: tracy it's really a great tool, thanks again! today i had the problem of several errors when using the todo-panel, because there where some invalid characters in some of my template sources. it is a folder of my designer using uikit and some other resources... i fixed it by adding the template folder on this line: https://github.com/adrianbj/TracyDebugger/blob/master/TodoPanel.inc#L148 i think it would be a good option to have a textarea to EXCLUDE (or maybe also include?) some folders from being processed. i have lots of todos/hacks/bugs in my template that are not my concern - so this option would be great in two ways: prevent errors like the one i had today and prevent showing todos that do not belong to my work.

It's the Options -Indexes In the .htaccess that prevents directory listing.

Perfect! Now it works as expected. Thank you

Hi, That's a good read. Thanks for this.

Thanks, that helped. Download again and it should be fixed.

Hello tpr, I use the latest Version (3.24) and I found out that this only happens if you have a special image grid setting. It is the last one which shows the inputfield for the title. If you switch to the grid views without the input field it works correctly. Maybe this could help you to reproduce the behaviour. If not please let me know.

I see but can't reproduce. Could you send a screenshot of your module settings and share your PW version and browser info? There's a slight chance that I modified the CSS in the meantime and that's why it's not happening here. A new version is uploaded (v029), which contains a tweak to make the module list page more compact by removing section titles and keeping only the first table header.

Great, glad you got it figured out! You must have literally fixed it between the time I reloaded the page, and clicked "view source", since one tab had the issue and the other didn't.

No, ProCache only saves the cache after all the code in your template has been executed, and right before ProcessWire shuts down. Perhaps the old cache files are still present and the cache just needs to be cleared? Or perhaps the issue isn't the caching at all, and we were just seeing a side effect in the cache (this is what I think is most likely the case). Also your, $config->maxUrlSegments setting really does not matter too much, so long as validation of the $input->urlSegmentStr is working property. It sounds like the bogus URL pages are throwing 404s, so that's good. So now what you need to look for is what's generating the bogus URLs in the first place. They are appearing in the code, so they are coming from somewhere. It looks like they aren't originating from URL segments at all–that's just the result, but apparently not the source. So we need to look deeper. Here's something interesting. If I view the page at: http://ukmoths.org.uk/thumbnails/gracillariidae/ and hover a pagination link at the bottom, like "4", I can see the bogus URL. Yet if I view (not inspect) the source code, the links are clean. What that points to is that something from the Javascript side is manipulating the links. However, I can't confirm it because all the links are now clean, can't get any more bogus links, almost like you found and fixed something while I was viewing it. But if you are still seeing the issue, try viewing the same page with javascript disabled. If you can confirm it, start zooming in on the different JS parts, like perhaps the email obfuscation JS is still getting called somehow or another?

Hi, a while ago, we redesigned the corporate identity for the event- and catering agency p.events Event & Catering oHG based in Germany. Along with the new corporate design we also developed a new website based on ProcessWire 2.7: http://www.p-events.de The website's current focus is the presentation of p.event's services and therefore makes use of many images. It is planned to extend the website with a blog and a more sophisticated inquiry form in the future. The website is fully responsive (including images with srcset), uses free-flow image sliders and some CSS3 features like animations. We're looking forward to your feedback Cheers Alex

Thanks, I haven't noticed that (I'm using the "Compact header"). This should be fixed in v028 that is just uploaded + some small other fixes.

So, it's a PW 3.xx issue. Once we have an official stable release of PW 3.xx I'll test all my modules to ensure they are version 3.xx-compatible.

thank you horst for the detailed insights! how to you do all the scss compilation? any code snippets for that part?

Whew! I got help from Caddy developer abiosoft and now I have a working ProcessWire config! It is included below. Note certain things: - the "php" in the fastcgi line defines a preset, so we don't need to use any "ext" stuff. - the new style rewrite which does not use {uri}: to {path} {path}/ /index.php?it={path}&{query} Abiosoft is also looking into a webtrees instance I have. So far the routing is solved by a workaround of adding a /slash to a certain line the webtrees index.php. Once the issue is solved properly, I can publish the Caddy config on the webtrees forum I urge everyone using Caddy with PW to donate bitcoins to abiosoft! https://mysite.com, https://www.mysite.com { root /wherever/your/files/are fastcgi / unix:/var/run/php-fpm/php-fpm.sock php internal /forbidden rewrite { r /\. to /forbidden } rewrite { r /(COPYRIGHT|LICENSE|README|htaccess)\.txt to /forbidden } rewrite { r ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) to /forbidden } rewrite { r ^/site(-[^/]+)?/install to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php to /forbidden } rewrite { r ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) to /forbidden } rewrite { r ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) to /forbidden } # GLOBAL rewrite { to {path} {path}/ /index.php?it={path}&{query} } log /var/log/www/access.log { rotate { size 50 age 7 keep 5 } } errors { log /var/log/www/error.log { size 50 age 7 keep 5 } } }

Just my opinion, but this type of functionality should be included in the core image functions as each image is uploaded and saved. We as developers nust account for the greater diversity in user devices in the future. Having images processed on the backend (vs frontend page render) based on styles specific to a project (config options) would be tremendously helpful. Set it and forget it, type of thing.

Did you add "TextColor, BGColor" to the CKEditor Toolbar? My first line looks like this: Format, -, Bold, Italic, Underline, -, TextColor, BGColor, -, RemoveFormat You can further customize what colors will be allowed, under Custom Config Options: colorButton_enableMore: false colorButton_colors: F00,FFC609,FFF

$image = $page->images->get("name=picture.jpg");