ryan

Sorry I'm a little behind with messages here, I'll be caught up by mid week. But I've got a good excuse. Yesterday Karena Savannah Cramer was born. She is our 2nd daughter (Hanna Ryan, age 3 is our first). We will all be coming home from the hospital hopefully tomorrow.

I've run into a similar issue on one of my sites that has a lot of accounts to manage. I'm hoping to improve the core modules (ProcessPageType and/or ProcessUser) in this regard whenever there is bandwidth to pursue it.

Nice job Soma! Any chance I can talk you into adding this to the modules directory?

There is a little overhead in using this module since it has to parse through the abstractions and translate them to/from URLs. There's also the aspect of being unable to stop using the module once you start (since abstracts get stored rather than URLs). As a result, I think it's best not to use this module and instead just do a search/replace on your SQL dump before you migrate it from a subdirectory install to a root install. Though I am hoping to have a native/core solution for this particular issue before long.

Not sure I understand -- Why? It's a Friday here, end of the day, and my mind is lazy.

I wonder why this is the case? Sounds like bug to me, I will have to try and duplicate. Has anyone else run into this? I'm unclear about why the homepage should be hidden and unpublished? From an SEO standpoint, I think it's a little better to let your homepage (root, no language segment) serve as the homepage for your default language. The thinking here is that people often link to your domain rather than a specific page in the domain. It's technically stronger to have those links resolve to an actual page rather than to a redirect. Here's another good example of a language switcher that uses the multi-language page names module: http://processwire.com/talk/topic/2979-multi-language-page-names-urls/?p=33537

These two URLs resolve to different places. If I take out the http and domain, they are still different: /site/assets/list-details.json /site/assets/data/list-details.json Is that it? Or just a typo?

I think this sounds like a fine approach, though would be more inclined to generate it dynamically. Assuming the JSON is originally generated from ProcessWire, having it generated dynamically is going to give you more flexibility and make it easier to update. Having a dynamic request cached is basically the same thing as having a static file. You could cache it with MarkupCache, the built-in template cache, or ProCache. On the other hand, if the data really is static, then you don't need ProcessWire to generate it or serve it, as you could just upload a JSON file to a page and be done with it.

It looks to me like the way you are doing it is right, if I understand it correctly. You could set a user-defined variable to $page, like $page->myJS = 'some javascript here'; and then output that before your closing </body> tag. The skyscrapers profile is probably an even better example of the main.php approach. Whereas the blog profile is also taking an MVC approach, so there's a little more going on in the blog profile that may be harder to follow at first. Though note that in the skyscrapers profile, the "main" file is called _out.php.

With template files you generally have a documented set of API variables ($page, $pages, $user, etc.), and this is what the set() methods of TemplateFile are geared towards. On the other hand, when passing variables into a $page->render(), variables passed in may be unknown/undocumented to the template file, and will be installation-specific, since PW doesn't pass in API variables that way. By having them in a known array ($options), you have a way of inspecting them, or at least knowing where they will be. Otherwise, the template file would have no means of self discovery for these things. It decreases the unknowns, increases the portability, and introduces an appropriate level of separation from the system API variables. On the other hand, this is largely theoretical… I've never had the need to pass in variables to template files in this manner, so am mainly just trying to accommodate the needs brought up in this thread.

After you do a $session->login() the $user variable that was already there will still be the same one that was there before the login. So you need to change the $user variable yourself, i.e. $user = $session->login($email_address, $asmUserId); Also be certain that none of this is mission critical from a security standpoint. This is a publicly accessible interface to creating, modifying and accessing user accounts.

For a PW upgrade, you shouldn't have to re-import data from a CSV? That sounds like kind of a difficult way to piece things back together. I would follow the traditional upgrade process if you can (by replacing the /wire/ dir, and any other version-to-version instructions included).

I just tried upgrading a PHP 5.2.17 install and ran into the same issue as you did. Though the errors got logged for me, and I'm not clear why PHP 5.2 triggers these errors that PHP 5.3 doesn't, but it was easy to fix. I've pushed a couple of small fixes to dev so that it should work with 5.2 again.

It should still work fine on PHP 5.2. You won't be able to use anonymous functions, but ProcessWire itself doesn't have any PHP 5.3 requirements yet. I'm thinking we shouldn't have that requirement until the next major version (PW 2.4). The error you are running into does sound a lot like a opcode cache error. Though it also could be a PHP 5.3.8 bug–it sounds like PHP doesn't like the fact that MarkupCache implements two interfaces that require a __get() method. That's not actually a problem, but will keep an eye out if anyone else runs into it.

You can move your /wire/ dir wherever you want and use symlinks. However, I don't think this would do anything for security. The benefit of doing it would be just if you want to share the same /wire/ dir amont multiple installs. I think that some CMS products are prone to vulnerable files and so you want to move them out of web root. ProcessWire is not one of those products and your .htaccess file protects several directories from web access. You can try modifying PW's /index.php file to choose a different $config->assets dir. But I don't recommend it, as I've not tested it. Yes, you can store these assets wherever you want. ProcessWire doesn't actually link to them, only you do, in your template files. As a result, it doesn't matter where you put them.

Which version of PW are you running?

Looks awesome Horst!

This is now present on the dev branch. It throws an exception at save() time if the field contains pages that are outside the defined rules in the Inputfield.

That particular setting is meant to be translated per language. If you add /wire/modules/LanguageSupport.module to your translatable files list in Setup > Languages > [language] > then you can adjust the setLocale setting as you see fit, without having to modify the LanguageSupport.module file. Basically, anything that appears in __('') or $this->_('') or $this->_n('') or $this->_x('') is translatable.

In order to get a stack trace you either have to have debug mode on or be logged in as a superuser.

I recommend using this method (requires 2.3 dev branch): foreach($languages as $language) { if(!$page->viewable($language)) continue; // language marked not available $url = $page->localUrl($language); echo "<a href='$url'>$language->title</a>"; }

$config->scripts and $config->styles are meant to hold filenames, not entire tags. So you want to switch things around. $config->styles->add($config->urls->templates . "styles/mystyle.css"); <?php foreach ($config->styles->unique() as $style) { echo "<link rel='stylesheet' type='text/css' href='$style' />"; } ?> Also make sure that they are happening in this order. So if you are using a head.inc file, then you would want to make sure that your stylesheet file is added sometime before the include("./head.inc"). This by the way is one reason why I think using a main.php is a little better than head.inc/foot.inc.

Enhanced debug mode The dev branch also includes an enhanced debug mode in the admin. It's all been cleaned up to look better and provide more info. It also includes a new section that outlines all of the runtime attached hooks currently active in the system:

No. MySQL can execute hundreds of well optimized queries faster than one unoptimized one. And MySQL can often execute lots of simple queries faster than 1 complex one. ProcessWire takes advantage of this where it can. Query counting isn't useful anymore (if it ever was).

You have to consider XSS anywhere that the [untrusted] user can enter content that will be saved and echoed back to other users. In a default ProcessWire installation with no 3rd party modules, there aren't many places to consider this. The admin is designed for trusted users only. The comments module is the only thing that accepts and stores untrusted user input. It won't store markup in comments. It filters by stripping markup before storing a comment, and by entity encoding output when displaying a comment. Also consider that ProcessWire is designed to let you do what you want to do. If you want to create a text/textarea field that lets you enter script tags, then ProcessWire won't stop you. There are plenty of legitimate uses for such things. There simply isn't anywhere that an untrusted user can enter markup. But HTMLPurifier might have a place in your individual installation. If you are dealing with untrusted user input and allowing markup (HTML) then HTMLPurifier is essential. We have an HTMLPurifier module, ready to use. Content is validated and sanitized server-side, not client side. Though on text-based fields entered in the admin, we make no assumptions about what you are using them for. Even scripts are a legitimate use case (consider video embedding, etc.). Some Inputfields may have client-side validation built-in to do one thing or another (TinyMCE is an example). Though ProcessWire doesn't care about client side validation. What sanitization/validation takes place depends entirely upon the Fieldtype. From the admin side, the text-based fieldtypes are designed to contain any text, including any kind of markup. This is one reason why ProcessWire's admin is focused on trusted users only. While I don't recommend using PW's admin with untrusted users, there may be situations where you have "mostly" trusted users. In such cases, you may want to avoid things like rich text fields and focus on LML-based text formatters (safe ones, like Textile Restricted or BBCode) or even HTML Purifier. Our new CKEditor module actually does use the HTML Purifier for inline mode, since inline mode markup is not entity-encoded when presented in the admin. This is a consideration for any text fields that you don't want to support markup. Such fields might include your 'title' and 'summary' fields, but would exclude something like your 'body' field, which is designed specifically to contain markup. ProcessWire uses a type of modules called Textformatters. For any field that you want to have runtime output formatting, you can add an HTML Entities (or other types) Textformatter from Setup > Fields > [your field] > Details. This is only applicable to text-based fields. For entity encoding output yourself, use $sanitizer->entities($str). Generally you wouldn't ever use this on your managed content stored in PW. Instead, you would use it when echoing back something that the user entered, like search query: $q = $input->get->q; if($q) { $results = $pages->find("body%=" . $sanitizer->selectorValue($q)); echo "<h2>You searched for: " . $sanitizer->entities($q) . "</h2>"; if(count($results)) echo $results->render(); else echo "<p>Sorry, no results were found.</p>"; } ProcessWire's API does not use SQL queries, unless you choose to use the $db variable. So if you want to execute SQL queries, then you should follow best practices towards avoiding SQL injection. However, there are very few scenarios where any of us use SQL in developing websites or apps in ProcessWire, so it's generally a non-issue. What you do have to consider instead is selector injection, even if it's not nearly as potentially dangerous as SQL injection. So that's why we have the $sanitizer->selectorValue(); function. Note the use of it in the code segment above. Yes, all ProcessWire forms are CSRF protected.