ryan

This week's version adds the new Uikit 3 admin theme to the core! Plus we've got some nice upgrades our built-in Password field. https://processwire.com/blog/posts/processwire-3.0.83-core-updates/

This week's version, ProcessWire 3.0.82, focuses on fixing several things reported from GitHub issue reports (dev branch commit log). So there are quite a lot of commits in this week's version, but none interesting enough to warrant a screenshot or real blog post. There was also one addition, which was support for repeater fields in the Setup > Fields > Export/Import functions. This week also brings several updates to the AdminThemeUikit module, which we may be pulling into the core dev branch as soon as next week. So if you are using AdminThemeUikit, be sure to grab the latest version, in addition to ProcessWire 3.0.82. That's all for this week. Have a great weekend!

I saw your question in the FormBuilder linking to this thread, so replying here rather than there because I don't think it's related to FormBuilder, as it doesn't look like you are using FormBuilder for the forms here and as a result it shouldn't come into play. A couple things to look into: I'm wondering if there is an unexpected extra redirect occurring somewhere. It might be good to watch your developer tools Network tab (in Chrome) to look for 301 requests. It could be as simple as a page requiring a trailing slash and one not being present, or the opposite, and thus a redirect occurring. Or it could be that you've got those pages access protected using PW's template access control, and its redirects are happening before your _init.php even gets called. While you are testing, you might want to disable the _init.php code just to see what difference it makes. Take a look at markup regions and make sure that your final output is as you expect when viewing the source of the pages. I noticed you are using the markup region tag termination hint <!--#regPostContent-->, which is good—that gives Markup Regions a shortcut to find where your tag ends, saving it time. But in another case you are using <!-- #content end -->, which might be confusing the markup regions because it should instead be <!--#regContent-->, and I don't see a <div id='content'> in the markup you pasted in. I think markup regions is probably just ignoring your <!-- #content end -->, but try replacing it with <!--#regContent--> just in case.

ProcessWire 3.0.81 makes major improvements to the Role editor, simplifying the setup of access control in ProcessWire: https://processwire.com/blog/posts/processwire-3.0.81-upgrades-the-role-editor/

This week we've got a new version of ProcessWire 3.0.80. In this post we also look at how to create a language pack, and answer a lot of common questions about Pro module renewals, upgrades and more. Lastly, we take a brief look at the upcoming CKEditor 5. https://processwire.com/blog/posts/pw-3.0.80/

This week there's a new ProcessWire core version posted (version 3.0.79), as well as a new version of AdminThemeUikit posted. However, the focus this week was on covering issue reports and fixing little things, and I don't think it makes an interesting blog post, so we'll skip it this week. If you want to see what's new for 3.0.79, be sure to check out the dev branch commit log. While the changes to AdminThemeUikit were pretty little, the admin theme does continue to evolve nicely and I recommend grabbing it if you are using a previous version. Actually, even if you aren't using a previous version, I recommend grabbing it (along with the latest PW core version). Other than for a few small details and rare cases—in my opinion it's nearly production ready. Thanks for reading, and I hope everyone has a great weekend!

This week we're getting down into some of the smaller details of the Uikit admin theme. We take a look at that in this post, along with a couple of screenshots. Consider this a brief continuation of last week's post. https://processwire.com/blog/posts/more-admin-theme-updates/

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/