Leaderboard

This week's version of ProcessWire on the dev branch includes some useful updates to the included AdminThemeUikit module. It also adds a new config setting for disabling HTTPS requirements in dev/staging environments, as well as some other updates: https://processwire.com/blog/posts/pw-3.0.99/

server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name example.com; root /home/forge/example.com/public; index index.html index.htm index.php; charset utf-8; # ----------------------------------------------------------------------------------------------- # Access Restrictions: Protect ProcessWire system files # ----------------------------------------------------------------------------------------------- # Block access to ProcessWire system files location ~ \.(inc|info|module|sh|sql)$ { deny all; } # Block access to any file or directory that begins with a period location ~ /\. { deny all; } # Block access to protected assets directories location ~ ^/(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) { deny all; } # Block acceess to the /site/install/ directory location ~ ^/(site|site-[^/]+)/install($|/.*$) { deny all; } # Block dirs in /site/assets/ dirs that start with a hyphen location ~ ^/(site|site-[^/]+)/assets.*/-.+/.* { deny all; } # Block access to /wire/config.php, /site/config.php, /site/config-dev.php, and /wire/index.config.php location ~ ^/(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ { deny all; } # Block access to any PHP-based files in /templates-admin/ location ~ ^/(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP or markup files in /site/templates/ location ~ ^/(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP files in /site/assets/ location ~ ^/(site|site-[^/]+)/assets($|/|/.*\.php)$ { deny all; } # Block access to any PHP files in core or core module directories location ~ ^/wire/(core|modules)/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any PHP files in /site/modules/ location ~ ^/(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any software identifying txt files location ~ ^/(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ { deny all; } # Block all http access to the default/uninstalled site-default directory location ~ ^/site-default/ { deny all; } #Amplify dashboard location /nginx_status { stub_status on; allow 127.0.0.1; deny all; } # ----------------------------------------------------------------------------------------------- # If the request is for a static file, then set expires header and disable logging. # Give control to ProcessWire if the requested file or directory is non-existing. # ----------------------------------------------------------------------------------------------- location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ { expires 15d; log_not_found off; access_log off; try_files $uri $uri/ /index.php?it=$uri&$query_string; } # ----------------------------------------------------------------------------------------------- # ProCache Rules # ----------------------------------------------------------------------------------------------- set $cache_uri $request_uri; if ($request_method = POST) { set $cache_uri 'nocache'; } if ($http_cookie ~* "wires_challenge") { set $cache_uri 'nocache'; } if ($http_cookie ~* "persist") { set $cache_uri 'nocache'; } # ----------------------------------------------------------------------------------------------- # This location processes all other requests. If the request is for a file or directory that # physically exists on the server, then load the file. Else give control to ProcessWire. # ----------------------------------------------------------------------------------------------- location / { expires -1; try_files /site/assets/ProCache-b3d534d...d/$cache_uri/index.html $uri $uri/ /index.php?it=$uri&$args; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } access_log off; error_log /var/log/nginx/example.com-error.log error; error_page 404 /index.php; location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; fastcgi_index index.php; include fastcgi_params; } location ~ /\.ht { deny all; } }

Afaik CSS has precedence over HTML width. So either define width:100% for all your images or insert a special class for this (e.g. "img_responsive"). .img_responsive { width: 100%; } To make it selectable from the CKE toolbar, do sth. like CKEDITOR.stylesSet.add('mystyles', [ { name: 'Fullwidth', element: 'img', attributes: { 'class': 'img_responsive' } } ]);

I'm with @Macrura as i'm using wireRenderFile() extensively with a dedicated /views/ folder where I can organise my output in components / atoms / whatever you want to call it, using templates (and sometimes /fields/field.php) more or less as controllers. @bernhard brings up some good points I haven't thought of though, especially the JS part - I awkwardly tucked that into wire('config')->scripts, which isn't as elegant / nice. Anway, it's great having the flexibility and options to use PW as you see fit Quite liberating.

Hi, just wanted to share something I came across while working on an import module for XML data from a web service. The XML I got was not huge, but still, loading around 3.5 MB of XML with 250+ large child nodes into memory at once with simplexml_load_file() and then looping over it had significant impact on performance. I searched for a solution and found this great article about how to parse large XML files. It basically explains how to utilize the native XMLReader class together with SimpleXMLElement to handle such situations in a memory efficient way. After implementing it I got a significant improval on perceived performance. No comparison in numbers to share here as I'm a bit short on time.

An Images field allows you to: Rename images by clicking the filename in the edit panel or in list view. Replace images, keeping metadata and filename (when possible) by dropping a new image on the thumbnail in the edit panel. Introduced here. But neither of these things is possible in File fields, which prompted this module. The way that files are renamed or replaced in this module is not as slick as in the Images field but it gets the job done. The most time-consuming part was dealing with the UI differences of the core admin themes. @tpr, gives me even more respect for the work that must go into AdminOnSteroids. Most of the code to support the rename/replace features is already present in InputfieldFile - there is just no UI for it currently. So hopefully that means these features will be offered in the core soon and this module can become obsolete. Files Rename Replace Allows files to be renamed or replaced in Page Edit. Usage Install the Files Rename Replace module. If you want to limit the module to certain roles only, select the roles in the module config. If no roles are selected then any role may rename/replace files. In Page Edit, click "Rename/Replace" for a file... Rename Use the text input to edit the existing name (excluding file extension). Replace Use the "Replace with" select to choose a replacement file from the same field. On page save the file will be replaced with the file you selected. Metadata (description, tags) will be retained, and the filename also if the file extensions are the same. Tip: newly uploaded files will appear in the "Replace with" select after the page has been saved. https://github.com/Toutouwai/FilesRenameReplace http://modules.processwire.com/modules/files-rename-replace/

As threatened in the Pub sub forum in the "What are you currently building?" thread, I've toyed around with Collabora CODE and built file editing capabilities for office documents (Libre-/OpenOffice formats and MS Office as well as a few really old file types) into a PW module. If you are running OwnCloud or NextCloud, you'll perhaps be familiar with the Collabora app for this purpose. LoolEditor Edit office files directly in ProcessWire Edit your docx, odt, pptx, xlsx or whatever office files you have stored in your file fields directly from ProcessWire's page editor. Upload, click the edit icon, make your changes and save. Can be enabled per field, even in template context. Currently supports opening and saving of office documents. Locking functionality is in development. See the README on GitHub for installation instructions. You should be reasonably experienced with configuring HTTPS and running docker images to get things set up quickly. Pull requests are welcome! Here is a short demonstration:

This might be a quick fix, but for me this rather looks like a FieldtypeUnit, which fully deals with the fact that you're storing an amount of a unit. With the unit being available alongside the integer at runtime would give you the additional ability to handle the value to it's full extend like being able to converting weeks to days or grams to kilograms. A integer is just a single number but e.g. 60 seconds are just a different representation of the same value of 1 minute.

Don't delcare $today. To get today and future events you have to remove the $ from today on the selector: template=detail, detail_date>=today

Hey guys. Fresh off the oven. We're still polishing a bit, but went live anyway: https://inovtex.com/ Sorry this one is in Portuguese only, so you'll probably need the old google translate for it.

@adrian, looking at the commit that introduced the issue, it looks like removing the autocomplete attribute is an attempt to defeat this piece of InputfieldPassword.js. That piece of JS is a fairly old (and hacky) response to a browser-specific (Firefox) issue that probably no longer applies. The recent autofill fixes in InputfieldPassword and updates/bug-fixes to Firefox should have solved it without the need for that JS workaround (I tested quickly in the latest Firefox and couldn't see any issue with the JS removed). So you could raise a GitHub issue/request to see if Ryan will remove that JS. In the custom module I made for a project recently I took a different approach to auto-generated passwords. Rather than populate the core password field I manipulated the ProcessUser form to... 1. Hide the password field with CSS 2. Add a markup field to show the user the auto-generated password 3. Add a hidden field containing the auto-generated password Then in a before hook to InputfieldPassword::processInput I copy the password value from the hidden field to the password field in $input. That may not be an approach you'd want to take with your module, but just to show there might be other ways to tackle things if Ryan doesn't want to remove that problematic JS.

The import/export of fields and templates has been around since PW v2.5 (2014), so I think you could consider the feature as stable as anything else in the stable branch. For reference, the blog posts that introduced the features... https://processwire.com/blog/posts/august-2014-core-updates-1/ https://processwire.com/blog/posts/august-2014-core-updates-3/ I think it would be wise to be extra vigilant when exporting/importing non-core fieldtypes, and complex fieldtypes that need to account for templates/fieldgroups such as Repeater, Repeater Matrix, and maybe PageTable. Support was added for import/export of Repeater fields in late 2017 but Ryan said at the time "Seems to be working well here, but definitely needs more testing."

Hey @kongondo - seems like it's all because of the ___wakeupValue and ___sleepValue methods. Is there any reason they can't just return true, rather than returning $this->renderMarkup($page, $field); ? Thanks!

According to the image above. // loop over repeater items // repeater is the name of my repeater field foreach ($page->repeater as $r) { // person is the name of my page ref field for selecting persons // can hold a single page (can be set in field's settings, details tab) echo $r->person->title, " "; // skills is the name of my page ref field for selecting skills // can hold multiple pages so we have to loop (can be set in field's settings, details tab) foreach ($r->skills as $s) { echo $s->title, " "; } // or use eq echo $r->skills->eq(0)->title, " "; echo $r->skills->eq(1)->title, " "; } // outputs // Jim Programmer Designer Programmer Designer

One way to do something like that is with the repeater field. You have a repeater field and the repeater has two page ref fields (people, roles). And you repeat the fields for every person. The way i described in my first comment the roles field would go to the people template, so on the video page you would only have the people field. You add a person and then click on it, a modal opens to edit the persons page where you can set the role.

I've been searching for a CSS-only solution for a while to reveal a scroll-to-top link only after scrolling down the page, but no luck. Today I figured out that it's possible with position: sticky. The beauty of this is that you don't need to check the scroll position in a scroll event (+ in document ready, window resize), which makes it really lightweight. Update: added "html { scroll-behavior: smooth; }" and now there's animated scroll (Firefox 58+, Chrome 63+). It seems that Js is not required anymore to this feature. CodePen demo

you can just put a get variable ?register=1 on the request and it will show the registration form..

The module looks for a GET parameter register. When this is set to 1, it renders the login form. So what you could do is in the temnplate where you render the login form // set GET parameter register to 1 $input->get->register = 1; // render the form $content = $modules->get('LoginRegister')->execute(); I just tried it and it seems to work.

Yes, add fields for all the settings you need (e.g. with @Soma's ColorPicker module). Then add the styles inside style.php like you quoted above. body { background:<?=$page->bgcolor-field ?> url(<?=$page->bgimage-field ?>) no-repeat; } /* ...any other styles, with or without PHP code */ Then, in your regular template file, include the CSS settings page. <link rel="stylesheet" href="<?= $pages->get('/your/css/page/')->url ?>"> Basically, you've now created a separate PHP file for all the CSS so you don't have parts in a regular stylesheet and others in your template file. Once everything works, you can go into the style template's settings and switch on caching. Enter a cache time (like 86400 to regenerate the CSS only once a day) and you have performance close to a flat file stylesheet.

@szabesz - I had a play around to see how you could use custom PHP replacements in the description field. My first thought was create a module where you define tag/code pairs in the module config, then look for and replace those in descriptions. This works, but requires the use of eval() and conventional wisdom is that eval() is evil. So my next thought was Hanna Code, and this seems to work great. In ready.php (or create an autoload module): $this->addHookBefore('Inputfield::render', function($event) { if(!$this->wire('modules')->isInstalled('TextformatterHannaCode')) return; if(!($this->wire('process') && $this->wire('process')->className() == 'ProcessPageEdit')) return; $inputfield = $event->object; $description = $inputfield->description; if($description == '') return; $this->wire('modules')->TextformatterHannaCode->formatValue(new Page(), new Field(), $description); $inputfield->description = $description; }); Then set up the Hanna codes you want to use in description fields. If you want to get the page object for the page being edited then add this at the top of your Hanna code... if($process && $process->className() == 'ProcessPageEdit') { $p = $process->getPage(); } else { return "[Hanna code '$hanna->name' is not valid for this field]"; } return $p->url; // an example to return the URL to the page without scheme and hostname ...then access the page object as $p