Leaderboard

Relative to the last dev branch version (3.0.127) version 3.0.128 contains 40 commits, mostly specific to resolving older GitHub issue reports. If you are interested, here is the commit log: https://github.com/processwire/processwire/commits/dev — version 3.0.128 covers commits between March 2nd and today. We're down to about 77 remaining issue reports, mostly older stuff that didn't get covered in the past for one reason or another, but we're making good progress. Similar updates will be continuing next week, and I've also got several ProMailer updates coming out next week too. Hope you all have a great weekend!

Access By Query String Grant/deny access to pages according to query string. Allows visitors to view protected pages by accessing the page via a special URL containing an "access" GET variable. This allows you to provide a link to selected individuals while keeping the page(s) non-viewable to the public and search engines. The recipients of the link do not need to log in so it's very convenient for them. The view protection does not provide a high level of security so should only be used for non-critical scenarios. The purpose of the module was to prevent new websites being publicly accessible before they are officially launched, hence the default message in the module config. But it could be used for selected pages on existing websites also. Once a visitor has successfully accessed a protected page via the GET variable then they can view any other page protected by the same access rule without needing the GET variable for that browsing session. Superusers are not affected by the module. Usage Install the Access By Query String module. Define access rules in the format [GET variable]??[selector], one per line. As an example the rule... rumpelstiltskin??template=skills, title~=gold ...means that any pages using the "skills" template with the word "gold" in the title will not be viewable unless it is accessed with ?access=rumpelstiltskin in the URL. So you could provide a view link like https://domain.com/skills/spin-straw-into-gold/?access=rumpelstiltskin to selected individuals. Or you could limit view access to the whole frontend with a rule like... 4fU4ns7ZWXar??template!=admin You can choose what happens when a protected page is visited without the required GET variable: Replace the rendered markup Throw a 404 exception If replacing the rendered markup you can define a meta title and message to be shown. Or if you want to use more advanced markup you can hook AccessByQueryString::replacementMarkup(). $wire->addHookAfter('AccessByQueryString::replacementMarkup', function(HookEvent $event) { // Some info in hook arguments if needed... // The page that the visitor is trying to access $page = $event->arguments(0); // An array of access keys that apply to the page $access_keys = $event->arguments(1); // The title $title = $event->arguments(2); // The message $message = $event->arguments(3); // Return some markup $event->return = 'Your markup'; }); Screenshot https://github.com/Toutouwai/AccessByQueryString https://modules.processwire.com/modules/access-by-query-string/

Maybe I don't understand your problem correctly, but if you don't want to use a package manager, can't you just inject the css file for the theme directly as well? There's a CDN link on the themes page: https://unpkg.com/tippy.js@4/themes/light-border.css If you want to bundle all those files into a single dependency, I recommend Parcel, it's much simpler than webpack and you basically need no configuration for a basic compilation of JS/CSS dependencies into bundle files. I have just tried it out for a project I'm working on; this NPM script is all the config I needed: parcel build js/main.js --target browser --out-dir public/site/js --out-file bundle This will parse all code/imports in the main.js file and bundle them into a bundle.js file. It will also create a bundle.css file if you import any css.

Well, it needs to be <?php namespace ProcessWire; not <?php namespace Processwire; ?

Another way via a hook in /site/ready.php: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { // Only for main "Find" lister if($event->wire('page')->name !== 'lister') return; $lister = $event->object; $lister->allowSystem = true; }); This (and @adrian's suggestion) will only work for superusers because non-superusers are not allowed to view user pages.

I think you could achieve this using PHP logic without any special file system needed. I haven't used WordPress but from the docs you linked to it sounds like any existing child template replaces the parent template of the same. This would be easy to achieve in PW. The following examples assume a Markup Regions approach to templating. Your parent template files go in /site/templates/: _main.php basic-page.php home.php Your child template files go in /site/templates/child-templates/. You only create files for templates that you want to be different from the parent templates. Likewise for _main.php if you want to change that in your child theme. child-templates/_main.php child-templates/basic-page.php In /site/ready.php: $wire->addHookBefore('Page::render', function(HookEvent $event) { $page = $event->object; $templates_path = $event->wire('config')->paths->templates; // See if a replacement template file exists in child-templates $alt_template_path = "{$templates_path}child-templates/{$page->template->name}.php"; if(is_file($alt_template_path)) { // If so, use it as the template file $page->template->filename = $alt_template_path; } // See if a replacement _main.php file exists in child-templates if(is_file("{$templates_path}child-templates/_main.php")) { // If so, disable the default _main.php and use the replacement $page->template->noAppendTemplateFile = true; $page->template->appendFile = 'child-templates/_main.php'; } }); So that would cover template replacement as per WordPress (if I understand it right). But with Markup Regions it would be nice to have the option to sort of "extend" an existing template file rather than replace it. You could do this by putting files in /site/templates/child-templates/ with an "_append" suffix. The contents of these files gets included after the markup of the parent template of the same name, so you could use Markup Regions features like pw-append, pw-before, etc, to add to the markup of the parent template. child-templates/home_append.php And at the top of your _main.php file before the DOCTYPE (and same with child-templates/_main.php if you are using that): <?php // See if an append template file exists in child-templates $append_template_path = "{$config->paths->templates}child-templates/{$page->template->name}_append.php"; // If so, include it if(is_file($append_template_path)) include $append_template_path; ?>

@Robin S has already provided us with hundrends of goodies, one of them this deals with it: https://github.com/processwire/processwire-issues/issues/70#issuecomment-258023285 same in the forum: https://processwire.com/talk/topic/1674-sorting-repeater/?do=findComment&comment=131713

Great idea, Robin! I was thinking about creating something similar for my current project, this is perfect for its use case. Thank you!

probably not, since any file placed into your webspace will be served directly, they do not need to follow any particular nomenclature - that's just files. Happens also to any .js and .css files buried somewhere in a module's folder, for example. Before implementing admin pages for this purpose, why not simply extending InputfieldImage? You may use ImageExtra as a starting point...

I'm wondering why you need to identify the default variation in the first place? Only use the sizes you generated and you should be fine and it won't break whenever any other functionality generates other sizes. It's not just the default variation created for the image inputfield, which might generate extra variations.

It's a bit dinky, but it works and can be bookmarked

You can use a hook like this in /site/ready.php: $wire->addHookBefore('InputfieldPageAutocomplete(name=link_page_url)::render', function(HookEvent $event) { $inputfield = $event->object; // Get the page being edited $page_id = $event->wire('input')->get->int('id'); $edited_page = $event->wire('pages')->get($page_id); // If the edited page is one that you want to target if($edited_page->template == 'basic_page') { // Append to the findPagesSelector property to exclude pages you don't want to match $inputfield->findPagesSelector .= ', has_parent!=/menus/'; } });

ProcessWire InputfieldRepeaterMatrixDuplicate Thanks to the great ProModule "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use a content module on a different page (e.g. in the same design), you have to rebuild each item manually every time. This module extends the commercial ProModule "RepeaterMatrix" by the function to duplicate repeater items from one page to another page. The condition is that the target field is the same matrix field from which the item is duplicated. This module is currently understood as proof of concept. There are a few limitations that need to be considered. The intention of the module is that this functionality is integrated into the core of RepeaterMatrix and does not require an extra module. Check out the screencast What the module can do Duplicate multible repeater items from one page to another No matter how complex the item is Full support for file and image fields Multilingual support Support of Min and Max settings Live synchronization of clipboard between multiple browser tabs. Copy an item and simply switch the browser tab to the target page and you will immediately see the past button Support of multiple RepeaterMatrix fields on one page Configurable which roles and fields are excluded Configurable dialogs for copy and paste Duplicated items are automatically pasted to the end of the target field and set to hidden status so that changes are not directly published Automatic clipboard update when other items are picked Automatically removes old clipboard data if it is not pasted within 6 hours Delete clipboard itself by clicking the selected item again Benefit: unbelievably fast workflow and content replication What the module can't do Before an item can be duplicated in its current version, the source page must be saved. This means that if you make changes to an item and copy this, the old saved state will be duplicated Dynamic loading is currently not possible. Means no AJAX. When pasting, the target page is saved completely No support for nested repeater items. Currently only first level items can be duplicated. Means a repeater field in a repeater field cannot be duplicated. Workaround: simply duplicate the parent item Dynamic reloading and adding of repeater items cannot be registered. Several interfaces and events from the core are missing. The initialization occurs only once after the page load event Attention, please note! Nested repeaters cannot be supported technically. Therefore a check is made to prevent this. However, a nested repeater can only be detected if the field name ends for example with "_repeater1234". For example, if your MatrixRepeater field is named like this: "content_repeater" or "content_repeater123", this field is identified as nested and the module does not load. In version 2.0.1 the identification has been changed so that a field ending with the name repeater is only detected as nested if at least a two-digit number sequence follows. But to avoid this problem completely, make sure that your repeater matrix field does NOT end with the name "repeater". Changelog 2.0.1 Bug fix: Thanks to @ngrmm I could discover a bug which causes that the module cannot be loaded if the MatrixRepeater field ends with the name "repeater". The code was adjusted and information about the problem was provided 2.0.0 Feature: Copy multiple items at once! The fundament for copying multiple items was created by @Autofahrn - THX! Feature: Optionally you can disable the copy and/or paste dialog Bug fix: A fix suggestion when additional and normal repeater fields are present was contributed by @joshua - THX! 1.0.4 Bug fix: Various bug fixes and improvements in live synchronization Bug fix: Items are no longer inserted when the normal save button is clicked. Only when the past button is explicitly clicked Feature: Support of multiple repeater fields in one page Feature: Support of repeater Min/Max settings Feature: Configurable roles and fields Enhancement: Improved clipboard management Enhancement: Documentation improvement Enhancement: Corrected few typos #1 1.0.3 Feature: Live synchronization Enhancement: Load the module only in the backend Enhancement: Documentation improvement 1.0.2 Bug fix: Various bug fixes and improvements in JS functions Enhancement: Documentation improvement Enhancement: Corrected few typos 1.0.1 Bug fix: Various bug fixes and improvements in the duplication process 1.0.0 Initial release Support this module If this module is useful for you, I am very thankful for your small donation: Donate 5,- Euro (via PayPal – or an amount of your choice. Thank you!) Download this module (Version 2.0.1) > Github: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate > PW module directory: https://modules.processwire.com/modules/inputfield-repeater-matrix-duplicate/ > Old stable version (1.0.4): https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate/releases/tag/1.0.4

@teppo Thank you. I didn't even notice the subforum until just now. Will be more careful in the future. ?

Welcome to the PW forum @Slideth. As far as I know, adding redirects directly from a page's setting is not a core-feature. Can you find out if this is a module? Or maybe done with a hook (?). If it's a module, you should try to find its own dedicated module support forum and ask there. But generally speaking, check this redirect-field setting under "access", maybe you can define things right there...

This is a good argument and something to think about. Of course the drawback as you said is that any new code in the generator would have to manually be added to sites that were generated in an older version of the generator. Very nice demo. I'm using UIkit 3 of course. I'd love to check it out.

Instead of figuring out which variations may be added from functionality inside PW, why don't you simply place your variations into a subdirectory of the asset path (/site/assets/files/1234/happyvariations)? To enumerate those variations you do not go through $image->getVariations() but use the contents of that subdirectory? Of course you do not get an array of images but only the filenames. That way you may even encode other information into the filename and retrieve those information using preg_match. Depending on your use case this may even be a time-saver since the image files do not need to be opened. Of course you do not see those "private" variants in the admin and need to manage them completely from your scripts.

Sadly no, at least not in admin or to my knowledge. If you like to have it sorted, think about using a PageTable instead. Probably not as comfortable as the repeater for this purpose.

Hi JavaScript experts! I wanted to use tippy.js ( https://github.com/atomiks/tippyjs ) for RockGrid but I don't know how to load the necessary files. I got it to work with the default theme by injecting the CDN files, but I need to add the light-border theme and that's not part of the CDN files from the docs. Can anybody please help me - I don't know how all this NPM YARN stuff works and how to get the right files in the right place and which files to add to my $config->scripts and $config->styles in the admin. Thank you!

Well... thanks for asking about the date format. I know I had set it and even tried several versions, but today it was not set. I checked multiple times yesterday, trying to figure out what's wrong... After setting the formats to a value I like, it now all works flawlessly - in the old and the new repeater! ? Is there a way to sort the repeater elements by a field (date)? Thank you! I feel kinda dumb now... ?

Unless you do not have a CKEditor field named "1" you'll have to specify the name of an existing textarea field (using CKEditor) at settingsField. If your reference field is named bodytext, it would be: settingsField=bodytext

Which CSS Framework are you going to use? I've built a FrontendThemeUikit module last November and used it for two sites, but it's nothing releasable yet. If you are interested I can share my work with you. The concept is similar to what Robin posted above. https://screencast-o-matic.com/watch/cFXnX1Y72l The goal would be to have one master theme that does all the tedious tasks (rendering menus, injecting styles and scripts, do the basic setup with markup regions) and have a second theme only for customisations.

I'm not really in favor of "inheritance" for this kind of usecase. I like code generation much more if something shall be editable. Like put all you basic, low-level components in some class or helper functions and have some means (cli or otherwise) to generate higher level composed template files in the users project. This way you're doing a bunch things: Show/teach users how to compose your low-level components. Give them the ability to modify with hardly any restrictions. The "your update broke my changes" problem is much less of an issue and easier to control. It's just the low-level components which need to be backwards compatible and not a maze of hooks and overrides and stuff. Generators can be split up and used more focuses and all throughout a projects lifetime. It's not going to get harder the older the project gets. Generators can change without code of users breaking. They might just complain that the old results are no longer available to be generated.

Lastpass is pretty solid, and the free tier offers quite a lot.

You can use a full path to the file rather than a relative one. I think it's a good practice to do this for all includes as it's more robust than a relative path. If you get tired of typing $config->paths->templates you can do something like define a shorter constant/variable in an auto-prepended _init.php, or just a shorter version in config.php, eg. $config->tp

No; Intelephense, not IntelliSense :-).

For me the most helpful is Intelephense:

@happywire I think in the foreseeable future we cannot expect Ryan to change the way ProcessWire manages images so it is up to us to implement it the way we want to. As it is an "advance topic" I do not think it will be documented in details, except if we do it ourselves. One good way of doing it is how @bernhard wrote a great tutorial, which was happily published by Ryan in the blog: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ If you have the time to do your own research regarding this issue and ask others for more info then you might want to sum it up for us to in a similar tutorial. Most of us have their own way of managing images but this should not bother you, just do it your own way and help others by publishing it you have the time. ProcessWire pages under processwire.com/docs/ cover most what is needed for developers to get started but the blog articles often highlight even more, it's just that they are buried in there. Forum and Githubs issues also have a lot of information, but those are even more buried. However, I do not think that it will be possible to organize it all, so doing our own research is a must. Most of us perform custom goggle searches in order to dig into all these sources. The goos thing is that under the hood of ProcessWire things rarely change, so most things you are going to read in these sources are still relevant and work. However, the there have been major upgrade to images field, just search like: https://www.google.hu/search?q=image+site%3Aprocesswire.com For example: "In the new images field, they are now 260 pixels in the smaller dimension, scaled to 130 pixels (for HiDPI/retina support). The actual size and HiDPI support can be adjusted in config.php settings in $config->adminThumbOptions, though we think most will likely want to keep the default settings." https://processwire.com/blog/posts/major-images-field-upgrade/ So using gridSize it is possible to set the dimensions: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/config.php#L636 I do not exactly know how it should work though. When I set 'gridSize' => 100 and 'scale' => 1.0 then "1.0=force non-hidpi" should kick in, and in my understanding with this setting I should get images no bigger than 100x100 pixels. However, with this setting I get 200x200 pixels or less. Maybe it's me who does not understand the comment in the code. Also, there is this part in the comment: "1=allow hidpi, 0.5=always hidpi" which does not make any difference at all. In my case not matter what is set to scale, the admin thumb will always be twice the value of gridSize. It's not that hard, just sart by reading https://processwire.com/docs/modules/ and Bernhard's article.

Just install the "regular" PW site profile, it has various blog features (comments, categories, pagination etc.) built-in. https://processwire.com/blog/posts/introducing-a-new-processwire-site-profile/ There's also an (older) blog profile you could try: https://modules.processwire.com/modules/process-blog/

Not a completly serious tip for listening during developing, but maybe a good one for listening before starting. ? or

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.