ryan

Macrura, looking in InputfieldSelectize.module, I think the issue might potentially be that there are no default values established for the configuration properties. For instance, there is no $this->set('itemDataArray', array()); in the __construct() method. Though if something was working before, and stopped working after this upgrade, then I'd rather continue making it work than have existing modules have to make changes. I'm wondering if this change might be the culprit? Can you try changing it back to the previous setting to see if it makes any difference in your case? https://github.com/ryancramerdesign/ProcessWire/commit/132ea079f79c574dd39a4a7ca37bd852259e217a#diff-581dc8ba34896b025170325efb07ec90L789 If this is the issue (?), I can think of some other ways to approach this that should resolve it. If that's not the issue, please let me know too and I can continue hunting for it.

This week we have some nice optimizations and enhancements for the core, as well as some great upgrades in the forums! Our Inputfield forms (including page editor) got a whole lot faster, and our Password field got a ton of nice enhancements. These updates are all available in version 2.8.22 as well. https://processwire.com/blog/posts/upgrades-optimizations-pw-3.0.22/

We've got some great updates for you this week, especially for those still running ProcessWire 2.x. ProcessWire 3.x also got a lot more stable this week. In fact, this week ProcessWire 2.x and 3.x got a lot closer! https://processwire.com/blog/posts/processwire-3.0.21-and-2.8.21/

Working through GitHub issue reports was the focus of this week, and it looks like we've got one more week to go in working through the current queue. There have not been any major bugs in 3.x, so things are looking more and more stable. Most updates in this weeks version (3.0.20) are about fixing minor bugs and various cosmetic things. There's nothing particularly exciting to report in this version other than that. But working towards a fully stable 3.x master version is itself an exciting thing. So rather than focus on the small tweaks and fixes from this week, lets backtrack and review all that's new in 3.x relative to the current 2.7 master version… https://processwire.com/blog/posts/review-of-processwire-3.x-so-far/

All the language sites should now be up too. i.e. de.processwire.com and so on. wiki.processwire.com didn't survive the server change. Somehow its database had grown to multiple gigabytes, and it appears that it may have been hacked or something. I've lost trust in MediaWiki for our use. Since everything on there is pretty well out of date at this point, we opted not to copy that over to the new server. We could spend days trying to figure out why a small wiki had a 3.5 gigabyte database, so I figured we were better off without it.

@mikeuk Don't worry you are doing fine, don't take anything too seriously. We're all friends here and occasionally like to hit each other with the zen stick, but it's always friendly. The demo site is filling multiple shoes. Sometimes people ask where they can take a look at a Pro module, in which case I'll install it on that demo site since it's already all setup with guest admin logins and such. But LostKobrakai is right that ProCache is disabled as soon as you are logged in, so it's really only there as a demo of the configuration screen. Though admittedly, I do like having it installed there just because for whatever reason people like to scrape that entire site regularly, so ProCache lets them do it more quickly, without consuming too much server resources. I suppose that doesn't matter much now that we're on this new server which has a ton more resources than before.

This week our focus was on the server side of things rather than on the code side. Sometimes you've got to open the hood and change the oil in order to keep things running smoothly. But rather than just changing the oil, we opted to replace the entire car, moving from our compact family sedan to a turbocharged supercar, so to speak. Basically, we've had some major server upgrades this week! This post covers them in detail: https://processwire.com/blog/posts/web-hosting-changes-and-server-upgrades/

There are still a few little things to work out, but we're mostly there. The biggest one I'm aware of at the moment is that forums have no outbound email. It turns out we're required to use an external SMTP server in this case, so working on setting that up. @kongondo I've been messing around with email settings on the modules site this last week, trying to get it working with Mailgun, and decided to just wrap it up once everything was transferred. Outbound email should start working everywhere again hopefully by tomorrow.

All switched! Please let me know if anyone runs into any issues. The new server is quite a bit more powerful than the previous, so hoping you might notice a speed difference too–I sure do.

Just wanted to let you guys know that we're moving all of the ProcessWire sites to a new web host today around 12pm (noon), EST. Our new dedicated server is from IBM/Softlayer, and this is going to be a really great upgrade for us. I'll cover more in this week's blog post, but wanted to give you a heads up that things will be switching today and there may be a brief period of down time. I may take the forums down for a bit when the change is taking place so that we don't have messages getting posted on one server and not another while the DNS updates.

ProcessWire 3.0.19 lets you work with thousands of pages at once, with a new $pages->findMany() API method! https://processwire.com/blog/posts/find-and-iterate-many-pages-at-once/

Version 3.0.18 continues from last week, making major upgrades to our images field. This week we got into some of the finer details, and we've got plenty for you to look at here, as well as a screencast (at the end) to demonstrate it all. https://processwire.com/blog/posts/more-images-upgrades/

Thanks to Renobird and LostKobrakai, ProcessWire’s images field has been re-designed and redeveloped with a lot of great new features we think you’ll love! This new images field is available for use now in ProcessWire 3.0.17. The linked blog post covers it in detail. There’s also a screencast at the end that shows you the new images field in action. https://processwire.com/blog/posts/major-images-field-upgrade/

There's no difference in how you would use $session, $input, or any API variable or any PHP superglobal ($_GET, $_POST, etc). These have nothing to do with namespace. If you must disable the template compiler, edit your /site/config.php and add $config->templateCompile = false; to it. That will prevent any of your template files from getting compiled. As for compiling modules: At this time I wouldn't recommend disabling the module compiler, otherwise almost no 3rd party modules will work. That's because there are few if any PW3-specific modules at present. If you come across a module that isn't working after being compiled, let me know about it so I can investigate it. When it comes to template files (and you've disabled the template compiler): you don't need to add a namespace to all of them. You only need to add it to those that are calling ProcessWire specific functions like the wire() function, or those that are referring to ProcessWire constants or classes directly. Things like this: $foo = new PageArray(); $date = wireDate('Ymd'); $page->addStatus(Page::statusUnpublished); The parts in bold above are those that are referring to things in the ProcessWire namespace. Adding "namespace ProcessWire;" to the top of the file makes it simple, that's all you'd have to do. If you didn't want to do that, you could also just update a wire() function call to be like this: $date = \ProcessWire\wireDate('Ymd'); Or you could just enable the template compiler, which will do this for you. However, maybe you aren't using things like the wireDate() or wire() functions and maybe you aren't referring to things like Page::statusUnpublished. If that's the case, you can skip adding a namespace at all, and likewise don't need the compiler. ProcessWire's API variables like $pages and $input and $session and all of that are going to be present either way. These have nothing to do with namespace.

Last week I mentioned we'd be continuing the documentation updates into this week and that's exactly what we did. All in all, these documentation updates involved 46 files and 5264 additions, so far. Read more about it in this weeks' blog post: https://processwire.com/blog/posts/processwire-3.0.16-continues-expanding-documentation-and-more/

I actually don't think this is a matter of file paths. That error points to one file (like _func.php) having a namespace, and another file (like main.php) not having a namespace (or not referring to the function in the namespace that it exists). If you are letting PW decide whether to compile a file based on whether it has a namespace or not, then you've got to take those same considerations for any files it might include(). A file that doesn't get compiled isn't going to have files include()'d from it compiled either. So it sounds like you probably do have a namespace defined in your _func.php file, but not in your main.php file (or the opposite). For your case, since you are adding a namespace to the to of all your .php files, I'd suggest disabling the compiler by setting $config->templateCompile=false; in your /site/config.php.

I'm not positive this is the solution to the exact issue you are seeing, but I think there's definitely an issue with the include() statements being relative... so the question becomes, relative to what? The screenshot shows on /views/layout/ directory off of the installation root, and another off of the /site/templates/ directory, so I am also confused. The _done.php file appears to be in the /site/templates/views/ directory, but it's using include statements like this that don't specify the starting point: include("views/layout/head.inc"); The problem with the above is that no starting point means it's off to being looked for in all of PHP's include paths. If you want the starting point to be from the current directory, then you'd want to make it "./views/layout/head.inc". However, that wouldn't seem to be right here, since _done.php is already in the "views" directory (rather than the /site/templates/ directory). So it seems like it should instead be this: include("./layout/head.inc"); I'm still a little confused about there being multiple /views/layout/ directories (if I understood that correctly), so it may be worthwhile to be even more specific, like specifying if you want the one that's off of $config->paths->root, or the one off of $config->paths->templates. For example, include($config->paths->templates . "views/layout/head.inc");

Hey guys, I think a few things in the code examples above need to be moved around. Also, since Repeaters don't know about languages, if you are creating repeater items on your own from the PHP side, you'll have to enable those items for all the languages they are applicable to. I replied on that GitHub issue report, along with suggestions for adjustments to the code.

This week I've got to keep the blog post a little brief because I've been so caught up in this weeks' updates that I've run out of time to write much in the post! The updates this week are not actually to the core code, but rather to the API reference documentation for ProcessWire 3.x. There's lots more work to do still, but I definitely have a good start, so going to introduce it here in this post. https://processwire.com/blog/posts/processwire-3.x-api-reference/

The File Compiler may still compile the file, but that doesn't mean it'll use it. It can compile a file for no purpose other than to determine if there would be any differences provided by compilation.

In my case, it's only been worth the effort for one site that I deal with that is doing constant imports all day. It makes a difference in the performance of other requests there. There are a lot of technical benefits to InnoDB relative to MyISAM for sure. But in the PW context (or most CMS contexts) it's hard to derive much value from those benefits until you run into specific needs or scale. In 15+ years and thousands of MyISAM tables around here, I've never experienced any kind of data corruption or loss associated with MyISAM tables. If starting something new I think InnoDB is worthwhile if it can be supported in your environment, but for most cases of existing PW installations I don't think it's worth the effort unless the circumstances mentioned in post are present. From what I understand, MyISAM's fulltext indexes may still be stronger than InnoDB's, though not positive that's still the case. Btw, PW will use InnoDB either way for cases where it makes the most difference.

This week's version of ProcessWire adds several new panels that provide simpler and more direct access to the page tree, page view and debug tools. New page view options also include multi-language selection and configuration support. And if that's not enough, we've also got install-time utf8mb4 support and more! https://processwire.com/blog/posts/pw-3.0.15/

Getting closer to the ProcessWire 3.x stable release, version 3.0.14 focuses largely on updates and optimizations specific to recent GitHub issue reports. We also have optimizations and in-depth coverage of PW’s file compiler, some new options for required fields, along with a review of some best practices when working with fields. https://processwire.com/blog/posts/processwire-3.0.14-updates-file-compiler-fields-and-more/

For Chinese characters, I just copied the characters I needed to use in a page name and appended them to my $config->pageNameWhitelist, like this: $config->pageNameCharset = 'UTF8'; $config->pageNameWhitelist = '-_.abcdefghijklmnopqrstuvwxyz0123456789' . 'æåäßöüđжхцчшщюяàáâèéëêěìíïîõòóôøùúûůñçčćďĺľńňŕřšťýžабвгдеёзийкл' . 'мнопрстуфыэęąśłżź健康長壽·繁榮昌盛'; You'll have to make sure that your /site/config.php file is UTF-8 encoded, which it should be by default. But depending on what editor you are using, it's always possible it's not.

This week we've got major upgrades to ProcessWire's selector engine, a great new version of Form Builder, and a few other core updates as well! https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/