ryan

Sounds like you found a good solution. Other potential solutions are reading and re-writing the options from your render() method, or override the renderOptions() method, or just modify the protected properties inherited from InputfieldSelect (like $this->options or $this->optionAttributes).

If you use a renderReady() method, here's what the definition looks like: https://github.com/processwire/processwire/blob/master/wire/core/Inputfield.php#L1009 Remember to end by calling the parent::renderReady() method as well: public function renderReady(Inputfield $parent = null, $renderValueMode = false) { // perform any needed initialization here return parent::renderReady($parent, $renderValueMode); }

The thing you quoted from the API reference is specific to Module configuration. Configuration data for the module (that which is configured in Modules > InputfieldSomething) would be populated after __construct(), and before init(). But you are attempting to access configuration for a Field rather than a Module. The method you are using (getConfigInputfields) is what is used by Fieldtype and Inputfield modules for configuration of a Field. This is unrelated to Module configuration, because a single Fieldtype/Inputfield module can be used for multiple fields. Further, an Inputfield module can be used independently of ProcessWire's Fields system (like in other forms that aren't connected with PW fields) where a getConfigInputfields() method wouldn't even apply. For these reasons, you can't have field/instance-specific configuration data populated to Fieldtype or Inputfield modules as part of the usual Module boot process. For an Inputfield module, you would want to move whatever field-specific initialization you need into the ___render() method, or renderReady() method instead if you need it to happen before.

It would just depend on what's being worked on. I generally don't push stuff to GitHub until I know it's solid. If working on something that's going to take a couple weeks to get to that point, then I'll avoid having it appear on GitHub because it wouldn't be ready. Since plans for 2017 include a focus on some things that may go beyond the usual weekly timeline focus, I'd say that weekly activity on the GH repo would reduce a lot when these things are being developed. Of course, activity on the core code wouldn't be reduced at all (likely increased), but the frequency of commits that appear on GitHub would be reduced. Plans are to keep it roughly as-is. But since it's now ~130 posts, it's time to add a few more things like categories, related posts, next/prev post links, etc. I also want to upgrade it to be more guest-author friendly, so that it includes authorship information like we have in the tutorials (example).

Happy New Year! Looking back over the last year, it's been a really great year for the project, and wow has it gone fast! In this post we'll look back at some of what we've accomplished over the last year, and–more importantly–introduce and review our 2017 roadmap. Today we've also released version 3.0.47 dev, which doesn't add anything new feature wise, but does contain several optimization and bug fix comments. https://processwire.com/blog/posts/roadmap-2017/

Historically w3techs has been tracking this stuff the longest as far as I can tell, and their information is updated often. They show ProcessWire nearing in on the 0.1% market share threshold (only 2 spots away from the 0.1%+ table). The info on this page below is interesting. The entire page is sorted by market share (highest to lowest). It shows a lot of CMSs ahead of us, but a lot more below us in market share, including some fairly recognizable ones. https://w3techs.com/technologies/overview/content_management/all

Christmas stockings are where you find the small gifts, while the big stuff goes wrapped up under the tree. Yet, looking back, it often seems like some of the most useful stuff ends up in those stockings… Swiss army knifes, digital tire gauges, flash drives, and so on. This week, the big stuff is between you and Santa, but what we do have are lots of useful stocking stuffers for you to enjoy in ProcessWire 3.0.46! https://processwire.com/blog/posts/pw-3.0.46-stocking-stuffers/

This latest version on the dev branch includes several tweaks, fixes, upgrades and some nice optimizations. This post covers them all, plus a look at our new Page field configuration. Then we conclude with some fun API tips and tricks. https://processwire.com/blog/posts/pw-3.0.45/

Lots of fun new upgrades to our Repeater and Repeater Matrix fields this week. In this post we cover all the details along with a couple of screenshots. You can start using these now in ProcessWire 3.0.44 (dev branch): https://processwire.com/blog/posts/pw-3.0.44-repeaters/

This is the $input->url() method. Without a "./" before it, PHP could feasibly load that file from anywhere in the php include path, and this is why we always say not to do that in your PW templates (unless you really need to have it load from a undefined location). I've not coded FileCompiler to try and track down files from the include path, because FileCompiler can only work with files in /site/. So it does require that a directory be part of the include, even if it's the current "./" directory. It may still work in some cases without it, but I wouldn't recommend it. Also, per the blog post, the /*NoCompile*/ has to be within parenthesis. Or to state it differently, it means you have to use include/require/etc. as a function call like include("./test_include.php" /*NoCompile*/); Thanks, yes it looks like I had an error there that could be triggered in certain cases. I've pushed a fix that is now on the dev branch.

Hope you all are having a great week. In this post we cover ProcessWire 3.0.43 (dev) which includes a lot of updates and a newly upgraded $page->url() method. Also a bit on the FileCompiler and revisiting last week’s ProcessWire Weekly recipe. http://processwire.com/blog/posts/processwire-3.0.43-core-updates/

Makes sense, thanks. While I think PW core needs to remain kind of independent of a specific theming system, I do agree more options here would be helpful if we had some ways for the audiences you mentioned to be able to get up and running without delving into development. It's not just a matter of those audiences, but also could be helpful to us on projects where we don't really have much of a budget to work with, but just need to get something up and running without having to resort to WP, SquareSpace, etc. So I definitely support the idea of community profiles like this. But of course the foundation of PW's core is that it doesn't produce front-end markup. Site profiles are independent of the core, so it works well that way. The core shouldn't adopt a particular front-end theme strategy, but if one evolves on its own through the community I think it'd be beneficial for sure. What I was alluding to in the blog post is that in the short term, PW would benefit from having a few more site profile installation options from the get-go. The current "beginner", "intermediate" and "languages" profiles are focused more on developer skill level rather than "what kind of site do I want". And the "classic" profile is so old it needs to be dropped. I think we'd be better off with options like these: basic beginner site(s) for learning (like the current profiles) business/corporate site multi-language site (business/corporate?) blog site brochure site (single page on the front-end?) Maybe some other options would be worthwhile too, these are just the first that come to mind. But the point would be to have more starting points that are closer to what someone's looking for in terms of their actual needs. Rather than being bare bones like the current site profiles, these would be attractive sites in their own right (hopefully as a result of the great designers we've got in this community). Maybe a community profile would even evolve as a part of this process. I've always done it with just one page and template file as the controller utilizing $input->urlSegmentStr (or individually) for specifying actions and query strings for specific key/value things. This keeps it simple. Of course it may pull in lots of other pages, but as for the service itself it usually needs nothing but a single page and template. Usually when people are building a web service, they are trying to accommodate some specific need. So a lot of these details become irrelevant when building something to answer to the need. If building a full blown REST API, then yes it gets complicated because you have to account for anything that anyone wants to do. But this doesn't change the reality that building a web service for a specific purpose in PW is incredibly simple, and probably more often simpler than even configuring a full flown REST API, if it existed. Showing the right content type when an error occurs is a given, so yes one shouldn't leave uncaught exceptions, of course. I might not have understood what you meant on that. Using PW's $input var does not override using PHP's $_GET or $_POST vars. Honestly I use whatever is more convenient in a specific instance. Most of the time I prefer $input, but if need something outside the scope of $input then of course I go to PHP's superglobals. There isn't really a major benefit to using $input unless you are chaining it with a sanitizer method at the same time. Years ago, portable coding around these superglobals was annoying because you had to determine if PHP was messing with the data, like adding slashes to input. You don't really come across this anymore. PW's $input is not meant to replace the superglobals, it's meant to provide an alternative to them that may be more convenient in many cases. This is again a reason why I like the simplicity of building services to fit the need. I fully support a REST API in PW, but am just not convinced it would save anyone time except maybe non-developers. Like you mentioned above, PW has quite a diversity of possible data types, and always will (since Fieldtypes are modules, and anything can be installed). So a REST API that accommodates anything could become quite complicated. All the while, web services for specific needs remain one of the simplest things to build in PW. The biggest benefit of a full REST API in PW as I see it would be for marketing, for having a box to check, etc. And I can't argue with that.

What you are describing is already what PW is for the most part. Though maybe there's additional helpers that could be added to support the front-end developer as you mentioned, I'm not sure. But what simpler context for a REST API could you have than what PW already provides? My experience has been that this kind of module is counterproductive – I deleted the web services module I'd built awhile back because I thought it costed people time rather than saving it. Maybe what's needed is a guide showing you how to implement a simple REST API on your own, without any module, since PW already makes it easy. But I appreciate your comments and will certainly look further into both options. That's basically a theme – what WordPress, Drupal, etc. are for. I'm not against the idea as something for us to collaborate on as a community, but from the core standpoint, it's the opposite of what the core aims to provide. Great ideas regarding the "community" profile, and I think it makes a great community thing, just not a core thing. I don't want to blur the line between PW and platforms like WP, Drupal, etc. Though I do think it's good to show that PW can do these things too. But if we had community efforts like this (and more diversity of profiles separate from it) the core really wouldn't need anything other than a blank profile. Though until that time, I do still think it's good for the core to demonstrate the diversity of output possibilities at the simplest level. These are still on the roadmap and have been for awhile. What gets implemented depends on resources, but front-end image resizing seems like it's got good potential for the near future, while front-end $pages API may take longer (but I still hope to accomplish that for 2017). Chances are I won't be the one developing the front-end image resizing stuff, as the ideas were brought in by another person, and I know little about it. But it is also one of the features that gets me very excited, so hopefully we can get some momentum going on this soon.

What's in the new master version 3.0.42, and covering the release of the new ProDevTools modules: ProfilerPro and API Explorer. Plus, a look at some of what we'll be focusing on in 2017! https://processwire.com/blog/posts/processwire-3.0.42-is-out-and-prodevtools-is-released/

This week we've got a new master version 3.0.41 and this post covers what's new. We also take a look at the API Explorer module from the ProDevTools set of modules, which will be released next week. https://processwire.com/blog/posts/processwire-3.0.41-and-a-look-at-api-explorer/

While we don't have a new core version for you this week, 3.0.41 will be here next week, with 3.0.40 becoming the new master at the same time. This week, I'll introduce something new I've been working on for awhile here (ProfilerPro), and think some of you might find it as useful as I have. https://processwire.com/blog/posts/a-look-at-the-new-profilerpro-module/

@horst That's great! Thanks @arjen! The more people we have working on it I think the better. I think part of the issue before was just that I created the page 5 years ago and had been the only one making updates to it, and likewise only one that crosslinked it to the CMS and CMF list pages on Wikipedia. I'm guessing this flags it somehow, as Wikipedia likes to see more community involvement (which makes sense). Since I'm still the person that originally created the page, I think it's also best that I'm not the one that adds it on other sections in Wikipedia. If any of you guys thinks that ProcessWire belongs on the Wikipedia CMS and CMF lists, would you consider adding ProcessWire to these pages below? List of content management systems: https://en.wikipedia.org/wiki/List_of_content_management_systems List of content management frameworks: https://en.wikipedia.org/wiki/List_of_content_management_frameworks

Thanks @adrian great to see it back! It looks like you know Wikipedia much better than me, would you be able to help maintain the page for ProcessWire going forward too?

I emailed with the guy that deleted it last month. I didn't get a clear answer about what the problem was, but there were a couple of old links in there that went to 404s, so I think that was part of it. It also sounds like some people helping to manage content at Wikipedia don't think that those involved in a project should be the same ones to maintain the Wikipedia page on it. I think that makes sense in a lot of cases (like for commercial projects especially), but doesn't make much sense in our case. I am aware that nearly all the other CMS projects (open source and commercial) are maintaining their own Wikipedia pages. If someone else would be interested in helping to maintain the Wikipedia page I think that would be good, so that it's clear it's a community and not just some dude in his basement trying to write a Wikipedia page for something that nobody knows about. I did make a lot of edits and removed old links, updated information, etc., but honestly can't figure out how to publish it. So it remains a draft for now. I think we may need someone that knows Wikipedia better to figure this out. But I would like to go ahead and re-publish our Wikipedia page. But how?

New master and dev versions released, more coverage of what you can do with the new Functions API, plus a couple useful tips and tricks. https://processwire.com/blog/posts/processwire-3.0.40-core-updates/

I recommend using API $variables for most cases, but here are a few instances where you may prefer the function versions: If an API variable is out of scope (like in a function), then you may find the new function versions very useful. If your editing environment provides more benefits to you for using the function versions (like auto-completion and docs) then that's also a compelling reason to use them too. This is something we haven't been able to provide before now. If both of the above apply to you, then also use the functions API where you would have previously used wire(). If neither of the above apply to you, then just use API $variables (fewer characters to type, and no questions about what instance). Basically, use whatever provides the most benefits to your scenario. For all practical purposes, $page and page() are synonymous. I don't see any reason to use $wire in template files–that's really more for core use. The new skyscrapers template files were specifically developed to demonstrate the API variables as functions for that blog post. Basically, I wanted to show you how they work rather than just telling you. So I went out of my way to use them for this particular case. I personally use API variables in my sites, though will be glad to have the convenience of more options when needed. Function alternates to our API variables have been requested multiple times. That's because it's more friendly in how it enables communication between developer and editing environment. I agree that's a good reason to have them. However, you'll likely only want to use them if you find them beneficial in this way. It's completely IDE friendly, and that's actually one of the reasons for this approach versus using user defined $variables for regions. We're just working with strings here. Keep in mind the "+" is only something you add to the region name if you specifically want to prepend or append to an existing value that's already present in there… and most usages probably won't involve that. I'm not sure how to make prepending or appending more convenient than adding a single "+" character to the region name. I'm lazy and don't like to type a lot, so gravitate towards the simplest possible solution. But always open to suggestions.

This week has been busy! We've got updates to our demo site, a new functions API, and other core additions that you may find useful in template files. https://processwire.com/blog/posts/processwire-3.0.39-core-updates/

This week we've got a new dev branch version with several updates which we'll merge to master soon. This post also includes a useful recipe on how to log all outgoing emails sent from your site. https://processwire.com/blog/posts/processwire-3.0.38-core-updates/

In addition to our regular core updates, we also have a new ProFields module to introduce to you this week. It’s something a little different that we’ve found pretty useful and think some of you will too. It's also available for download now in the ProFields board. This blog post covers it in detail: https://processwire.com/blog/posts/text-blocks/

So far things are going great for our new master version of ProcessWire, version 3.x. In this post, we'll take a look at what's new in ProcessWire 3.0.36 master, plus a look forward at what we'll be working on in the weeks ahead. https://processwire.com/blog/posts/processwire-3.0.36-and-looking-forward/