ryan

This week we’ve got another update to the new Uikit 3 based admin theme, AdminThemeUikit. It now has the flavor of Tom Reno’s fantastic AdminThemeReno, and now it's starting to feel like home. In this post we take a closer look with screenshots and more. https://processwire.com/blog/posts/uikit-3-admin-theme-updates/

You can renew any time. The auto-generated renewal invoices expire on their own after awhile (I think 90 days or thereabouts). So if you find you can't renew when you want to, just send me an email or PM and I can refresh it so that it'll work.

It uses ProcessWire's API to send the mail. If you need specific SMTP settings, you'll want to install one of the WireMail modules from the modules directory, whichever one suits your needs best.

Thanks. Just to clarify, this is not a core module, and won't ever be. When it comes to the core, I think it's best to intentionally limit the front-end "inputs", and leave anything further to one's own template files or modules that you may install (like this one). That way, we can be certain that the common front-end inputs to ProcessWire sites never exceeds the actual needs of an individual site, which I think is good for security. It already supports multi-language. It uses scssphp and lessphp. People who have already rolled their own solutions may prefer to stick with what they have, since presumably you've customized it to your needs and workflow already. But the compilation in ProCache is definitely handy, and I think folks that haven't already settled on a workflow of their own may find the one built into ProCache very useful. ProCache has always monitored your CSS and JS files for changes (and now SCSS and LESS files) to determine when it needs to merge and minify them. So making scssphp/lessphp part of that process makes a lot of sense. No external watchers, editors or background processes are needed. It's also handy if you want a common solution between servers that works regardless of whether in the dev environment, staging environment, or directly on the server, etc. It's nice knowing that a change will get compiled regardless of how or where the file is edited. You could disable it by editing the module file. But I wouldn't recommend it. A form that allows one to create a new ProcessWire login account without validation would quickly get abused. Over time it would just fill up with millions of bot accounts.

This week we've got new versions of the Uikit 3 admin theme, a new version of ProCache with SCSS and LESS support, plus a brand new module that provides user login, new user registration and a user profile editor, all for the front-end of your site. And of course, a new core dev version too (3.0.76)! https://processwire.com/blog/posts/pw-3.0.76-plus-login-register/

This week: A hurricane, no electricity, a new version of ProcessWire on the dev branch, and a new version of ProDrafts that adds repeater support and workflow support. https://processwire.com/blog/posts/processwire-3.0.75-and-a-new-version-of-prodrafts/

@AndZyk Just to confirm, this is your process adding the field: 1. Go to Setup > Templates > some-template 2. Add the FieldsetGroup field (example name: test_fieldset). It should automatically add the test_fieldset_END field, so that you see test_fieldset followed by test_fieldset_END. 3. Save the template. 4. When the page reloads, you should see test_fieldset, followed by all the fields in the fieldset, then test_fieldset_END. From what I gather (and from your GIF earlier), on step 4, you don't see the fields in the fieldset, and instead see just test_fieldset and test_fieldset_END - is this correct? If so, are you doing anything else between steps 2 and 3, like sorting of fields or changing other settings before saving? If so, I'd need to know what so I can attempt to reproduce here. The way it adds the fields to the fieldset is in the hookTemplateFieldAdded method on line 657 of FieldtypeFieldsetGroup.module. That hook is called after a field is added from ProcessTemplate.module. I can step through and watch it get called from here, so am thinking perhaps the hook isn't getting called in your case for some reason. The only other thing I can identify is that it looks like you are running a custom admin theme. It might be worth trying with the default admin theme, just in case. Though I kind of doubt that's it. It might also be worth testing on a clean installation, just in case there is some other module or hook at play that is specific to this installation.

It might be that you have to grab the current dev branch. I probably should have bumped the version up to 3.0.75, but was thinking there weren't enough differences. I must be wrong about that. If you grab a fresh copy of 3.0.74, chances are it should work.

I've updated the download thread with v2 of FieldtypeFieldsetGroup, which I think should fix the issue mentioned here. This version also excludes the _END field per abdus request.

I can't duplicate that one here yet, but InputfieldFieldsetOpen is a quasi module, so starting to see how that might happen. Wondering if you change line 472 to this, if that fixes it? $inputfield = parent::getInputfield($page, $field); You are right there's no reason for it to show that, so I'll update to exclude it. The working solution you found is the way I usually do it. However, you could also do if($f->type instanceof FieldtypeFieldsetClose). It will add the fields, but you have to hit "Save" first. So add the FieldsetGroup field to your template, then Save, and then you'll see the fields in the fieldset.

Wrapping up the fieldset trilogy comes part 3: Fieldset Group, which is now released. In the post we take a closer look at it and compare it to the other fieldset types. Then we wrap up with some hints about more coming up in the weeks ahead. https://processwire.com/blog/posts/fieldsetgroup-module-released/

Last week we talked about new Fieldset modules for ProcessWire, and I was happy to hear about all the enthusiasm for these. In that post, we primarily looked at the new FieldtypeFieldsetGroup module in detail. This week we'll continue along a similar subject and look at the new FieldtypeFieldsetPage module. Actually we'll do more than look at it, we'll release it – it's now in ProcessWire core version 3.0.74, ready for you to use: https://processwire.com/blog/posts/processwire-3.0.74-adds-new-fieldsetpage-field-type/

This post is all about fieldsets in ProcessWire. Version 3.0.73 adds some nice UI upgrades when it comes to working with them. Plus we cover two new modules we have in development for managing groups of fields in fieldsets: https://processwire.com/blog/posts/processwire-3.0.73-and-new-fieldset-types/

Facebook doesn't let you pull images if you aren't logged in. Meaning, only the client side can pull images, the server side cannot (meaning, ProcessWire cannot since Facebook blocks it). So if you are going to use picture or picture_url (or other images), you have to refer to it directly in an <img> tag using the URL facebook provides, rather than trying to pull a copy and store it in PW.

This week's post is actually last week's post, just updated with a lot of new content. Since the topic is pretty much the same as last week, I thought it fit better this way. We've continued to make a ton of progress with the export/import features over the last week, and it's all covered in the updated blog post here: https://processwire.com/blog/posts/processwire-3.0.71-adds-new-core-module/

This week we added the new pages export/import feature to the core! In this post, we tell you how to install it and cover all of the new things added over the last week. https://processwire.com/blog/posts/processwire-3.0.71-adds-new-core-module/

In this week's post we'll take a closer look at the importing side of our upcoming export/import tool. Plus we'll look at something new in 3.0.70 called markup region hints, which are worthwhile if you are using markup regions in PW3. https://processwire.com/blog/posts/pw-3.0.70/

This week's version of ProcessWire on the dev branch is 3.0.69 and it includes several minor bug fixes. This week's post focuses in on a new module released today called Login for Facebook, which I think many might find useful, and we've got all the details here: https://processwire.com/blog/posts/pw-login-for-facebook/

Yes, planning on this. May not be in the initial public/dev branch version though. Most definitely. I think that part of it should already work, but have not spent time testing it yet. That's probably one of the next things I'll be testing here, as this would be needed before adding it as a core module. It will work like the existing template/field import, i.e. you'll be able to un-check certain updates that you don't want to occur. Though for applying granular updates, the JSON copy/paste is really nice, as you can also just modify the JSON directly too. Not planning to pursue that. This is purely about page import/export. If it needs a particular Fieldtype module to be present in order to import a field, it'll let you know of the prerequisite. The info about required Fieldtypes are stored in the export, so that the import can look at that before attempting import. This one has already been in the core for awhile. See Setup > Templates, then see the Export/Import buttons at the bottom. We have the same for fields as well.

This week we've got more to tell (and show) you about our upcoming page export/import feature, along with several screenshots of the progress: https://processwire.com/blog/posts/processwire-3.0.68-and-more-on-page-export-import/

@Macrura looks like a could have saved a lot of time here if I'd found your module first, sounds like we were after the same thing, except that you were well ahead of the curve on this. Right down to the Selectize library even. I started working on this after the post a couple weeks ago detailing how to handle multi-language with images, and feeling like an idiot for not even checking to see if someone had built this already. I ended up modifying the Selectize library because I couldn't get it to work quite how I wanted to for a couple of instances. Like when doing the createFilter, where you only allow certain tags, if you hit enter and the tag wasn't allowed, it would submit the form and save the page, rather than just refusing the tag. There were a couple little things like that I had to tackle, but otherwise it's pretty close to stock. To answer your questions, I didn't add support for Selectize skin, and instead modified the default style to be independent of color palette so that it would work equally well regardless of admin theme. I just thought the other theme colors weren't mixing well with our admin themes. As for interference, there may be. I don't know a good way around it other than to check if Selectize is already in the core, like if(is_dir($config->paths->JqueryUI . 'selectize')) { $modules->JqueryUI->use('selectize'); } else { /* selectize not present */ }. But since your module came first, perhaps a good route would be for the core to detect if your module is present and skip over the built-in tag stuff when it is? Yes, the tags can be limited in the field settings. No it can't be changed per-template yet, but that's simple, I'll add that. @matjazp I'm not sure I understand the question? At least, I don't have to save a page before I can add tags, but if you think there's an error let me know steps to reproduce.

This week's version includes some helpful UI updates to the tags feature available in our File and Image fields, which we'll be taking a closer look at in this post. Like many versions, this also includes some other updates consistent with submitted GitHub issue reports. Read on for all the details… https://processwire.com/blog/posts/processwire-3.0.67-upgraded-file-and-image-tags/

We aren't using a load balancer for this processwire.com server (just a single Amazon instance). But for the sites where we are (and running PW), there is a shell script that syncs /site/assets/ and /site/templates/, across the instances. I don't know exactly how it works, but can find out more. I know it runs every 30 minutes (cron job) and whenever a change is detected. Note that it also specifically excludes /site/assets/cache/ and /site/assets/sessions/, as those vary between the instances. Also important, is that when it comes to using the PW admin, we setup a separate hostname for that purpose (admin.domain.com) that always hits the same instance (which we call the "A" instance). This is the instance that the shell script considers the master when it comes to syncing files. That way, any changes that occur to the synced files always originate on the A instance. There is a setting in AWS that lets you lock a hostname to a specific load balanced EC2 instance. Then we keep any editing locked to that hostname by adding this to /site/templates/admin.php: if($config->httpHost != 'admin.domain.com') { $session->redirect('https://admin.domain.com/processwire/'); } And we keep non-authenticated requests out of the admin hostname by having this in the /site/templates/_init.php file ($config->prependTemplatefile setting): if($config->httpHost == 'admin.domain.com' && !$user->isLoggedin()) { $session->redirect('https://www.domain.com' . $page->url); } This ensures search engines don't get in and start indexing another copy of the site on the admin hostname.

I don't think it'll be an issue for this case because the words may be the same, but the case is different. But there's actually another function in the posted version called __value('name'), which is what you can use if you prefer it. It returns whatever bit of text has the given name, regardless of what kind it is. However, it's pretty easy to avoid these kinds of collisions even without the __value() function.

This week we’ve got ProcessWire version 3.0.66, and this post takes an in-depth look at the new “Functional Fields” ProFields module, just released today… https://processwire.com/blog/posts/functional-fields/