ryan

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/

Werner, I tried creating a page with name "bäckerei-testmann", as well as changing an existing page to have that name, but seems to work fine here. Double check that you've followed all the instructions in the blog post, as it sounds like something may potentially be missing. However, the error message you mentioned indicates that maybe there really is a page with that name already in there, perhaps as a temporary one that you created but never saved (i.e. queued for deletion). Experiment with other page names to see if you can duplicate the issue. Of course, double check that your PW version is 3.0.12 as well, as this won't work on earlier versions. The guys mentioned it above already, but just wanted to repeat that PW always stores page names as ASCII so it's not going to matter what the collation is, and ascii is the correct one that it should have. UTF-8 page names are converted to and from ascii via punycode, just like IDNs.

In this week's blog post, Adrian Jones introduces his new Tracy Debugger module for ProcessWire. Enjoy this in-depth overview and tutorial where you'll learn a lot of new and useful things. An epic post on one of the most useful modules for PW! https://processwire.com/blog/posts/introducing-tracy-debugger/

ProcessWire 3.0.12 now supports the ability to use extended (UTF-8) page names, meaning your URLs can now have just about any characters that you want… https://processwire.com/blog/posts/hello-健康長壽·繁榮昌盛

I'm committed to support Repeater and Repeater Matrix with ProDrafts, but don't yet know on how soon it will be. Most likely it will be a little after releasing PW 3.0 as the new stable version, since Repeater Matrix requires PW3. The good thing is that both of those types (and PageTable) are based on PW pages already, and ProDrafts works with PW pages. So supporting it is more a matter of linking and delegating things in the right way, since technically we can already maintain drafts of all those types... but just yet not connected with the owning page. Btw, I'm thrilled to hear how much you like Repeater Matrix. I haven't heard from many people using it since I released it, so it's very encouraging to hear that you are getting good use out of it! I am definitely getting good use out of it here too.

If I've understood the question correctly, the answer is I don't know. But my guess so far is: I'm not sure you'll want Composer for this, as PW is still a system that needs to be installed and connected with a database, etc. Meaning, you can't use PW's API unless you've installed it, and that installation involves a few screens of configuring the DB, creating admin account, etc. Whereas, it seems that most of the things one pulls in with Composer are more PHP library specific. But it's a good question because we are going to be making the ProcessWire core available on Packagist, so it'll be interesting to find out exactly what one would do with it from there because ProcessWire is not something that will run out of a /vendor/ directory or just start working because one of its classes was autoloaded. I suspect we'll have some trial and error and things to discover here as we go through the process.

@gunter I'm not seeing that issue here. Double check the following: Your composer version is up-to-date. Your PW version is 3.0.11 (or newer). Your /index.php file is up to date with the core version. Your /composer.json file is up to date with the core version. Here's what I get when I run composer from a fresh installation: Ryans-MacBook-Pro:xyz ryan$ composer require processwire/google-client-api Using version dev-master for processwire/google-client-api ./composer.json has been updated Loading composer repositories with package information Updating dependencies (including require-dev) - Installing hari/pw-module (1.0.0) Downloading: 100% - Installing psr/http-message (dev-master 85d6369) Cloning 85d63699f0dbedb190bbd4b0d2b9dc707ea4c298 - Installing guzzlehttp/psr7 (1.2.3) Loading from cache - Installing guzzlehttp/promises (1.1.0) Loading from cache - Installing guzzlehttp/guzzle (dev-master 6a173dd) Cloning 6a173ddae1a8e58be871f6d010e88c029eaf5cae - Installing phpseclib/phpseclib (2.0.x-dev 9e586e7) Cloning 9e586e79f1fadced93cea6b8dfa09c1bde7904c2 - Installing psr/log (dev-master d8e60a5) Cloning d8e60a5619fff77f9669da8997697443ef1a1d7e - Installing monolog/monolog (1.x-dev a9ccae2) Cloning a9ccae25cbb5c0af6f2a549e4cc3ee6628c253ab - Installing firebase/php-jwt (v3.0.0) Loading from cache - Installing google/auth (v0.7) Loading from cache - Installing google/apiclient (dev-master 87dff99) Cloning 87dff9908464b150334283cd092d7d96e0dcc5bf - Installing processwire/google-client-api (dev-master 6d66c53) Cloning 6d66c53187a330669bd96ebeb5ea14e80d2c6897 phpseclib/phpseclib suggests installing ext-gmp (Install the GMP (GNU Multiple Precision) extension in order to speed up arbitrary precision integer arithmetic operations.) phpseclib/phpseclib suggests installing ext-libsodium (SSH2/SFTP can make use of some algorithms provided by the libsodium-php extension.) phpseclib/phpseclib suggests installing ext-mcrypt (Install the Mcrypt extension in order to speed up a few other cryptographic operations.) monolog/monolog suggests installing graylog2/gelf-php (Allow sending log messages to a GrayLog2 server) monolog/monolog suggests installing raven/raven (Allow sending log messages to a Sentry server) monolog/monolog suggests installing doctrine/couchdb (Allow sending log messages to a CouchDB server) monolog/monolog suggests installing ruflin/elastica (Allow sending log messages to an Elastic Search server) monolog/monolog suggests installing videlalvaro/php-amqplib (Allow sending log messages to an AMQP server using php-amqplib) monolog/monolog suggests installing ext-amqp (Allow sending log messages to an AMQP server (1.0+ required)) monolog/monolog suggests installing ext-mongo (Allow sending log messages to a MongoDB server) monolog/monolog suggests installing mongodb/mongodb (Allow sending log messages to a MongoDB server via PHP Driver) monolog/monolog suggests installing aws/aws-sdk-php (Allow sending log messages to AWS services like DynamoDB) monolog/monolog suggests installing rollbar/rollbar (Allow sending log messages to Rollbar) monolog/monolog suggests installing php-console/php-console (Allow sending log messages to Google Chrome) Writing lock file Generating autoload files Anybody else seeing an error when trying to run the composer require command?

This week we've been focused on one of the major 3.x roadmap items, which is to have strong Composer support in ProcessWire. In this post, we now have an outlined process and a full proof-of-concept module built to demonstrate it all, plus info on how other module authors can support Composer as an alternative installation method. To add to that, we get into Google's Client API with a new 3.x specific module and how to connect Google's Calendar services with ProcessWire. https://processwire.com/blog/posts/composer-google-calendars-and-processwire/

Most of this week and ProcessWire 3.0.10 has been focused on covering issue reports and related tweaks/fixes, which you'll see in the commit log. But we've also got a major upgrade to the core in 3.0.10 as well, with the introduction of ImageMagick and a new module type: ImageSizerEngine– http://processwire.com/blog/posts/processwire-3.0.10-expands-image-resize-options/

Thanks for reporting back. Glad to hear that was it and that everything is working now!

Probably WordPress. I'm guessing its default configuration has at least something to do with WP. There doesn't seem to be anything inherently wrong with Suhosin (rather, just how it's configured), and in fact it seems like it could be quite a useful security tool. But it would have to be configured for the software it's running with, otherwise seems like it's very likely going to interfere with that software.