ryan

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.

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/