ryan

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.

You got it–a 404 should be thrown before you start outputting a page. If there is some other fatal error that occurs after you've started rendering your markup, it's better to throw a more generic WireException('your error message').

It would probably be quite easy to go between the current file format and another, especially another JSON/YAML type file. Our current file format is very simple. I'm not totally clear on the format that would be required by Transifex though. I'm also not sure I fully understand the value of these services since they can't parse the PHP source files for translation strings? Maybe I need to get in there and play.

Same here, anchor button doesn't work, and it grays the whole screen with no way out other than to exit the page. Tested in the latest Chrome. Doesn't matter whether it's normal or inline mode. No Javascript errors, so not clear about what's going on here.

The best way to have pages appear at the top of a list when they are created is to set their default sort field to be '-created' (or reverse created in the admin). But as for having a manual sorting, PW's admin will only add pages to the end of a manually sorted list.

Apeisa is correct in that inputfields can be represented as arrays, and it's fairly simple to convert them to or from arrays. In the case of FormBuilder, the forms are converted to an array and then to JSON for storage. So far the only place I've found this useful is in FormBuilder, though I'm sure there's more potential. As for manually composing inputfields or forms via arrays, I don't really like doing that because there is no interface… just a faceless array. Reminds me a little too much of configuring forms in Drupal. But I'm fine with supporting the option if people like it.

You have to enable it in your Form Builder module settings: InputfieldFormBuilderFile. On an existing FormBuilder installation, you may have to install the module before you can enable it. The $e['file'] should be an array of filenames. In the case of a single file, it would just be an array of 1 file. The actual file URL is protected from direct access, so you have to ask Form Builder to generate one for you. It's not the prettiest in terms of API access, but I think this should work: $form = $forms->get('contact-form'); foreach($form->entries()->find() as $entry) { foreach($entry['file'] as $filename) { $path = $form->entries()->getFilesPath($entry['id']); $url = $forms->getFileURL($form->id, $entry['id'], $path . basename($filename)); echo $url . "<br />"; } } Regarding submission date, Soma is correct that it would be contained in $entry['created']; as a unix timestamp.

Seems like we do need another shutdown hook of some sort here that gets called regardless of whether it was a pageview or a redirect. Semantically, it probably makes sense that ProcessPageView::finished doesn't get called on a redirect, though not sure it really matters. What do you guys think would be best of these 3 options: Make $session->redirect() call $processPageView->finished(); before exiting. Add a new ProcessWire::shutdown hookable method that always gets called. Add an optional finished() method to the module interface. Like the ready() method, but gets called automatically (on modules that have it) when the request is done.

I'm assuming the 404 you are getting is an Apache one rather than a ProcessWire one. You are seeing mod_security in action. When mod_security gets in the way of legitimate content management, then it's configured in an overly agressive manner. I would ask your host to loosen things up a bit, or if they can't, have them disable mod_security for your account.

Looks like you are on the right track there. As for the field name and/or id, I'm guessing you don't want to use the title though. In order to make sure you've got something unique, you might want to use "myfield{$cat->id}" or something like that. If you don't need to support images/files in repeaters, then it won't be too difficult. You would add one or more repeater items at the end, but make them hidden or collapsed. You could have a little javascript link that says "add item" and when clicked, it unhides the next one. Make the fields in each follow a different name format, like "myfield_new1" for the first one, "myfield_new2" for the second one, etc. Basically, some name format that your processor would know is referring to a new item it should add. Then it could process them like this: $n = 1; $name = "myfield_new$n"; while($input->post->$name) { $item = $mypage->myrepeater->getNewItem() // populate any fields in the repeater you want $item->title = $input->post->$name; $item->save(); $mypage->myrepeater->add($item); $n++; $name = "myfield_new$n"; } if($n > 1) $mypage->save('myrepeater');

The whole idea of a maintenance mode is something to be careful with on a site that depends on any kind of search traffic. It's not a great idea to make a habit of it, that's for sure. So if you need to put a site in maintenance mode, try not to do it for long. Personally, I have never had the need for a maintenance mode. Though there have been a couple times where I was pushing in a major update to a site, and I temporarily added the following to the top of the /index.php file: die("Go away! We are trying to upgrade the site.");

Thanks Soma, I have updated it.

I'm guessing that's the case (a blank <p></p> added by Markdown). Can you try replacing your /wire/modules/LanguageSupport/LanguageSupportFields.module with the attached? I think this may fix it. LanguageSupportFields.module

I've been making regular updates on the dev branch to the LanguageSupportPageNames module, so if you guys are using this, you may want to keep track of the updates. The good news is that this module is now running a production site: http://tripsite.com/cruises/ (only the /cruises/ site, as the rest of the site is running on a different copy of PW). This morning I pushed an update that makes it easier to tell if a given $page is viewable in another language. Now you can do this: if($page->viewable($language)) { ... } // Language object if($page->viewable('es')) { ... } // Language name That is basically telling you if the page has its "active" checkbox checked. Since these pages would already be excluded from search results, you don't typically need to use it except when on a given page and trying to determine what other languages that page is available in (like if you want to link to them, as the select box at the top of tripsite does).

I develop all my sites of subdirectories on localhost, but when migrating them they usually aren't running off subdirs. I usually load the DB sql file into my text editor and do a search/replace "/mysite/" => "/", before migrating the DB to the live site. But it won't be long before we have this task taken care of internally without any need to do replacements.

What are your settings for the field? Double check that you've defined the float precision.

@k07n: The module looks good. But start your class with an uppercase character, otherwise it might confuse PW's module parser, which is expecting it for categorization purposes. @jmart: 301 would really be the right way to do it and would not be a nightmare. Use Apeisa's redirects module and life will be easy. But if you really need all pages to be accessible at root level (which is not something I'd recommend) you could accomplish it by editing your 'home' template, clicking to the 'URLs' tab and enabling URL segments. Then in your home.php template: if($input->urlSegment1) { $p = $pages->find("name=" . $sanitizer->pageName($input->urlSegment1))->first(); if($p) { $session->redirect($p->url); // 301 redirect to it // echo $p->render(); // or output it here, no redirect } else { throw new Wire404Exception(); } } else { // render homepage }

Looks like getlocalization supports JSON and transifex supports YAML. It would be fairly easy to convert to/from formats they recognize.