ryan

Soma, while I wasn't able to duplicate that here, I was able to find a bug when using just parent.title, so I'm wondering if it might also be responsible for the result you were getting. Can you try the latest dev branch and let me know if you are still experiencing the error?

This is true as the requests are delivered as static HTML files. So it doesn't touch the DB unless the request isn't cached. It is a great way to let your server handle a lot more traffic. But regardless of what caching is in place, if you start to see a "too many connections" message regularly, then it's time to talk to your web host to see if the amount of traffic you are getting would benefit from a higher-end hosting plan. There are also cases with some web hosts where the resources are simply oversold and you might see those kinds of MySQL error messages even if you aren't getting a lot of traffic. In those cases, it's a good idea to find a new web host.

You can get by without the symlinks option. It's there because I tend to make regular use of symlinks, and am guessing others do too. But nothing in PW actually requires it.

If something triggers a fatal error, then the save can't be performed. Attempting to move a page somewhere that it's not allowed aborts the save. Also, template changes are confirmed with the user if the new template contains different fields. As a result, it has to be handled as a separate operation.

The "missing required field" error message is translatable in this file: /wire/core/InputfieldWrapper.php

Textformatters are intended for front-end rather than back-end. So you won't see the results of a Textformatter in the admin side. However, if you apply the SmartyPants Textformatter to any text field (Fields > edit field > Details > Text formatters), you should see the results on the front-end.

I'm planning to bring the same import/export system that's in FormBuilder to Fields and Templates.

What you are describing sounds very much like a custom application. It also sounds a lot more like a CRM than CMS. You could certainly do it in ProcessWire, but you are going to be in for some custom coding no matter what system you build it in. Whether using ProcessWire or another system, I recommend that you hire an expert to build this for you. Also, since everything you've mentioned is more specific to a CRM, I also recommend evaluating software like Salesforce for your needs. You can easily send data submitted from a website into into Salesforce using their web-to-lead forms. ProcessWire Form Builder can also submit data to Salesforce (and other services) natively.

The ProcessWire 404 will look like your site. The Apache 404 will look like plain text. Though I actually think this is mod_security either way. I think this is something that only your host can answer. Though if someone else knows better, hopefully they will reply.

I was wrong, the PageList won't work without Javascript at present. ProcessWire just delivers JSON for the PageList, and the markup is actually rendered in Javascript. Try this URL for an example of the output that ProcessPageList produces: /processwire/page/?id=1&render=JSON

We'll be adding more configurability to repeaters in the next version or so, including an option to have them collapsed by default (the repeater items themselves), ability to control labels of repeater items, and automatic sorting.

In ProcessWire you need to set: Who, What and Where. You've got the Who and the What, but not the Where. The "Where" is typically defined by template, though can also be controlled by hooks.

What is on line 1 column 2? That sounds like the first element in the file. I am guessing that a PHP error message is appearing where the start of the RSS should be. Either that or you have whitespace before the <?php tag in your template file. Viewing the source of the RSS feed should reveal what the issue is.

Go ahead and make your module implement ConfigurableModule, even if you don't want any interactive configuration: class MyModule extends WireData implements Module, ConfigurableModule { Add a getModuleConfigInputfields function to your class that just does this: public function getModuleConfigInputfields(array $data) { return new InputfieldWrapper(); } For data that you want to store, call upon the $modules API var like this: $data = array('foo' => 'hello', 'bar' => 'goodbye'); wire('modules')->saveModuleConfigData($this, $data); For data that you want to retrieve: $data = wire('modules')->getModuleConfigData($this); Your config data will be populated to your module automatically after __construct() but before init(). As a result, you might want to set default values in your __construct(): public function __construct() { $this->set('foo', 'hi'); $this->set('bar', 'bye'); } public function init() { // $this->foo is now 'hello' (not 'hi') // $this->bar is now 'goodbye' (not 'bye') } Using this method, your module can always access it's config data directly via $this->foo and $this->bar. Meaning, you probably won't ever need to use the getModuleConfigData() function, but it's good to know its there. However, you will need to use the saveModuleConfigData() function since you are saving configuration data non-interactively.

That's unusual. Are you getting an Apache 404 or a ProcessWire 404? If the file actually exists and you are getting a 404, chances are that Apache can't read it (i.e. file is not readable) – double check the file permissions.

Not sure how I missed that. I will correct and update to the dev branch today. Thanks!

I agree with renobird that it's pretty rough on the eyes, though I can see how it would appeal to kids. I get the impression that the designer must know his/her audience well. And we aren't that audience. But I can respect what they are doing here. I have to admit this reminds me a bit of geocities time when the web was a lot less designed, less serious, and more playful place. Not that I long for that period at all. But the period definitely had its own [youthful, tacky, random?] style about it.

I'm confused because not sure if your definition of 'user' here is a ProcessWire User, or you are maintaining your own system of users? To me it looks like you are maintaining your own user system, but not sure? This would affect the answer. I think we also need a little more context about where this code is going. Is this simply to check access on a page being viewed, or is this compiling/aggregating all access information to display somewhere? I'm guessing this is to aggregate somewhere since you mentioned looping through all the items? One thing that might be worth looking at is the PageEditPerUser module, which I think does some of what you are trying to accomplish here.

$sanitizer->username() is a deprecated holdout from PW 2.0, which didn't store users as pages and email addresses were allowed as usernames. So that's a typo on my part as the username() call should have been $sanitizer->pageName(), as users are themselves pages.

I think that file/image/page URLs in textareas are the only place where the issue can occur. It happens just because editors like TinyMCE are storing ready-to-output HTML. Everywhere else in ProcessWire (except cache files), everything is stored as references, so it doesn't matter where the site is running. Our eventual built-in solution will just ensure that any local URLs in textareas are always saved as if the site were running from root (via the sleepValue function), and prepend any subdirs to root paths at runtime (via the wakeupValue function).

I agree. We already have a hookable function that one could use to target a pageview vs. redirect (after Page::render). I've already updated Session::redirect locally to trigger ProcessPageView::finished, so it'll be in the dev source soon. I don't think it'll break any backwards compatibility just because I can't think of any module or situation that relies on finished() not getting triggered.

Sounds good. My account name is processwire. Though I've not received their activation email yet, so not sure my account is active.

Namespace aliasing is fine, but I'm really hoping to isolate our users from having to think about namespaces at all (unless they want to specifically use something outside of PW). I would gather that most of our users don't care or know about namespaces, so any extra technical verbosity reflects poorly on the simplicity of the system. I don't want people to have to have 'namespace' or 'use' statements at the top of every template file (unless they want to, again), but module files are ok. Not sure if that's even going to be an issue.

I added this to the dev branch last week, so that you can now pass additional things to $page->render(): https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/PageRender.module#L212 One of the things I wasn't thinking about before is that $page->render() was already capable of accepting an array of options (though not commonly used, mostly internal). So we weren't starting from a blank slate, and had to make something that was compatible and complimentary to what was already there. In terms of API calls, you can now do any of these: $page->render($filename); // $filename assumed in /site/templates/ $page->render($pathname); // $pathname is full path, but must resolve somewhere in web root $page->render($options); // array of options and/or your own variables $page->render(array('foo' => 'bar')); // same as above $page->render($filename, $options); // specify filename and options/vars, etc. The $options variable was already something that $page->render() accepted before. Only it was used to specify some little-used modifiers to render(). Those are still there (and they are necessary), but now the utility of $options has been extended. When you want to specify options (outlined in the link above) you only need to specify the ones you want to change from the defaults (of course). Typically you don't need to change them, so I'm guessing that most would use $options to specify their own variables. Every rendered template now receives a copy of that $options array locally scoped. That $options array contains any variables you passed to $page->render(). It also contains PW's default options, should you want to examine any of them. If you made this render() call: echo $page->render('myfile.php', array('foo' => 'bar')); myfile.php could access the 'foo' variable like this: echo $options['foo']; // outputs "bar" One other addition that I'm thinking people might like is $options['pageStack']. That is an array containing a stack of pages that called render(). So if you are doing any recursive rendering of pages, any template can access $options['pageStack'] to see what page is rendering it, and any others before it. Previously this was not possible, and the only way a template could tell what other page was rendering it (if any) was for that renderer to tell the renderee, via $mypage->caller = $page; or something like that.

I understand. Well the good thing is that our code standards are mostly similar to PSR-2, without some of the oddities it has (though I suppose that's subjective). I've found that I can go to/from PW <-> PSR-2 largely with simple search/replace, so I have no problem if people submit PSR-2 code. One of the nice things about code standards is that they are generally consistent and predictable, so going between different standards is not difficult. Thanks for your interest in this. I haven't yet started here, though know that mindplay.dk has done some work in this area and ProcessWire. Ultimately I want to gain the benefits of namespaces in PW without changing the way that people use the API. If people have to \Start\Doing\Lots\Of\This in order to use PW for typical web development, then it's a failure. The end goals are in place but not yet the whole plan. The plan should start coming together within the next 1-2 months though.