• Content count

  • Joined

  • Last visited

  • Days Won


ryan last won the day on October 20

ryan had the most liked content!

Community Reputation

13,520 Excellent

About ryan

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Atlanta, GA
  1. 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/
  2. 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!
  3. 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/
  4. 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/
  5. 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.
  6. 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.
  7. 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.
  8. 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/
  9. 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/
  10. @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.
  11. 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.
  12. 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.
  13. 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.
  14. 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/
  15. 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/