ryan

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.

Just found a Suhosin setting that will definitely interfere with PW files fields: Note that 64 as the default setting for "max length" of variable names in POST requests. This appears to be ON by default with this value in Suhosin. That's going to cause issues all over the place in PW. If you have a files field with a name more than 18 characters, or any files field in a repeater, then Suhosin is going to block any data in it. It looks to me like Suhosin's default settings will potentially interfere with most of PW's multi-value inputs, not to mention some of Suhosin's other default rules will interfere with other parts of PW (and I'm guessing almost any powerful CMS other than perhaps WordPress).

Just looking at all the things Suhosin gets involved with (https://suhosin.org/stories/configuration.html), it seems likely to me something with your files field(s) are generating a false positive with Suhosin. For instance, maybe it doesn't like something about the property name used by file descriptions or some combination of factors. It looks like there is a whole lot of stuff that can be configured with Suhosin that could cause all sorts of problems with different web applications. So after looking closer at Suhosin I stand by what I said earlier of this probably being the first thing to look at. If you are using Chrome, it's definitely not the browser. I think the majority of us here are using the latest Chrome as well. These permissions are usually considered to be far too open. It's certainly possible suhosin is having a problem with this. Though since you are on a dedicated VPS, maybe it doesn't matter much for your situation, but perhaps it does to Suhosin. Since you are using suphp, you can actually lock those permissions down quite far... the files likely don't even need to be readable outside of the user account. Whereas, your current permissions have them globally readable and writable to everyone (even if everyone is just you, since it's a dedicated environment, it's still likely to trip security-related things like Suhosin). If disabling Suhosin doesn't do it, see if you can just find any installation producing the issue reliably on a core Images field, and we can take a look at that.

@Ovi_S we run on a ServInt server here too, and actually so do all my clients… and pretty much every site I work with, for the last 10 years. I can't say I've ever observed the issue you've mentioned. So I doubt it's a ServInt issue, and instead must be related to something about the server configuration. For instance, none of the servers I use at ServInt have suhosin or suphp active. Now I doubt that suphp would be an issue, but suhosin–maybe. It would be worth trying to disable that at least temporarily if you can. Since the issue you've described seems a little random and no errors are involved, it has that sound of something interfering with the normal requests, which I think suhosin might do. Based on available info so far, I'm inclined to think this is the first thing that should be looked at. I'm sure you've tried this, but does using a different browser make any difference? If you look in your /site/config.php file, what settings are you using for $config->chmodFile and $config->chmodDir? Are you able to duplicate the issue on completely stock installation of PW 2.7.x or 3.0.x using one of the default profiles? (with no 3rd party modules installed). If so, I'm happy to take a look at it if you don't mind PM'ing me the PW admin login and FTP (or SSH) login to the installation. I would also need instructions on exactly what steps to take in order to reproduce the issue.

Since PW doesn't control your front end output, there are some things it can't update without doing a refresh. Though it should be able to dynamically update most text-based fields. For others, you can either let it do a refresh (which it should do automatically) or if you prefer, you can always provide hints to it. Though if you've got a heavily javascript-driven layout, refresh is always going to be reliable. If you've got a text field that you think it should be able to update dynamically, please post a copy of your entire HTML output of the page to the ProDrafts board (or PM to me), so that I can test with it here. Thanks. It's a ProDrafts setting, but affects both server-side and client-side.

For this week we've got a new version of ProcessWire 3.x, version 3.0.9. This version adds some useful UI enhancements in the admin that were originally envisioned by members of the ProcessWire community. ProcessWire 3.0.9 and also has a few other refactoring, bug fixes and tweaks. We've also got more info on the new version of ProDrafts released yesterday. https://processwire.com/blog/posts/processwire-3.0.9-adds-new-long-click-and-save-actions/

ProDrafts version 2 is now available for download in the ProDrafts board. This one includes the "Live Preview" capability shown in that video above. It also includes "View Both" capability, and several other improvements.

Hey guys, here's a video demonstrating the Live Preview feature of ProDrafts. This feature should be available to ProDrafts users this week. Please view the larger + HD version so that you can see it better.

This week it's a relatively focused blog post, largely in part to much focus going into the ProDrafts documentation today. Specifically, ProDrafts is now in pre-release! Here is today's post: https://processwire.com/blog/posts/prodrafts-now-available-in-pre-release/

If you've added "namespace ProcessWire" to the top of your template files, then you template files are now running in the ProcessWire namespace rather than the global one. AIOM runs in the global namespace, since it's not specifically made for PW3. Since AIOM uses static method calls to add files (if I recall correctly), you would just need to change those calls from "AIOM::something" to "\AIOM::something", with the leading backslash. That tells PHP to access something from the global namespace. By the way, you don't have to disable compilation for templates individually if you don't want to. If you don't want the template compiler at all, just set $config->templateCompile = false; in your /site/config.php and the template compiler will be completely turned off.

I can't think of any reason why the page name would come into play for the sorting. What I would take a look at though is where your PageTable items are stored (common parent for all, vs. children of page being edited). If using a common parent, look at the sort settings for that common parent on the Children tab, and make sure there isn't some predefined sort being applied. Likewise, look at the template used by that parent page and check the sort settings under the Family tab. If not using a common parent, then perform the same check as above, except for the page being edited (that page that contains the PageTable field). In your PageTable field settings, click the "Details" tab and review the "Sort fields" and make sure that it is blank. If it is blank already, go ahead and hit "save" anyway, just in case there's something caught in the field settings that needs to be refreshed.

That's exactly right, filtering the entire page tree at once, not just 1 level of children in a branch.

Thanks, glad you guys like it. I've lately worked on some projects here with a lot of pages deep in the site (and paginated no less), and the PageList bookmarks weren't cutting it. I found myself keeping two browser tabs open all the time so that I could keep my spot in the PageList. So I've been motivated to make this work better, but always got held up trying to figure out exactly how. Basically the goal has been to make the PageList behave as if it was an offcanvas panel that was always ready for you where you last left it. Back in PW 2.5 dev I was experimenting caches of the PageList, but the problem was that any changes in PageEdit could then make that cache stale, really limiting the utility of it. Last week I started messing with <link rel='prerender' href='...'> tags to the opened page list in order to keep a ready-to-use pre-rendered PageList that I could get to whenever clicking the "Pages" tab... it was quite cool, and instant, but also a real waste of background resources to be pre-rendering a PageList (and all the ajax requests) in the background while in the page editor. But just going through that process led to the current result, which uses JS cookies to remember the spot, and lets PageList perform a pre-render of what was previously split into multiple ajax requests. It's not as fast as using the link prerender tags but a lot more reliable and less wasteful of resources, so seemed like a good compromise. I had not seen that, wish I could say I had. But sounds like we're all on the same wavelength here! Great! Yeah it should run at the same speed regardless of quantity of children. I think one of the next improvements we'll want to look at is the ability to filter by text in the PageList. For instance, if you typed "something" in a text input, it would open all the branches directly to pages having the word "something" in their label. I think this has been brought up by others in the past too. The current search box in the masthead kind of does this already, but without any context of where those matches are, which is something the PageList could do. This could be handy in so many instances.

This week we've got a really nice improvement to ProcessWire's page tree, something that I believe everyone that uses the ProcessWire admin will appreciate. Also a big focus this week was on ProDrafts and wrapping that up so that we can release it and make it available to you. More on both here: https://processwire.com/blog/posts/processwire-3.0.8-brings-smarter-faster-page-tree/

This week we have another new ProcessWire 3.x version for you that includes several updates and optimizations. We’ve also greatly expanded upon the field rendering with template files, with lots of info covered in this post. https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/