ryan

It's correct that passwords can't be retained if you are developing a site in > 5.3.7 and migrating to a server running < 5.3.8. Best bet is to avoid any web server running an old version of PHP. But if you can't do that, then you'll want to reset your password at the live server after migrating the site to it. I usually paste this into my site/templates/admin.php, open the /processwire/ URL (to run it), and then remove it. $u = $users->get('ryan'); $u->of(false); $u->pass = 'mypass'; $u->save();

Thanks Soma. Those links will probably just keep changing (especially since they were going to line numbers), so I went ahead and unlinked them.

The ProcessPageClone module is not yet updated for use with the LanguageSupportPageNames module, but it will be by the time LanguageSupportPageNames gets out of development.

In film.php, try changing this: include('./includes/head.inc'); $commentsForm = $page->comments->renderForm(); To this (just reversing the order): $commentsForm = $page->comments->renderForm(); include('./includes/head.inc');

I think that you need to increase your memory size to PHP. Especially for anything that deals with images. I'm guessing you've got it set to 16m or 32m right now. And you probably want to bump it up to 128m or better yet 256m. You can set this in the php.ini via the memory_limit directive. On a ServInt server, I believe this is located in the file /usr/local/lib/php.ini. You'll have to restart Apache after making the change to php.ini.

This would not be scalable. A large quantity of abstracted links generated over a long period of time are not something that an uninstaller could remove in one request. That's one of the reasons why I'm not totally happy with abstracting links. LinkMonitor actually does go further than just abstracting links. It also locates broken links to images and such, and then logs them (and emails you, if you want). So it's a nice upgrade from PageLinkAbstractor, and also compatible with it. I'll have to get back to work on it.

Most likely there is an image in the system that isn't quite valid in format and so the resize failed. But it must be close to valid, because the previous checks apparently missed it. My guess is a corrupted image.

Are you sure it's not a ProcessField instance? That's what it is when I test here in that scenario. In either case, you are right that the test for ProcessPageView isn't right and needs to be changed. Currently it would only work on the front-end. I am changing it to this locally and will test before committing: if(wire('page')) wire('modules')->get('ProcessPageView')->finished();

That's the truth! I haven't had a chance to try things out in IE10, but will plan to do so soon. Thanks for reporting them. Anyone else able to reproduce these issues?

I suppose another way to accomplish this would be to just run ProcessWire from an SSD. Though wouldn't a servers bandwidth need to exceed the hard drive access time? I guess I figured bandwidth would be a bottleneck before the hard drive, but I don't claim to know much about server administration. Thanks for your interest in ProCache!

Just to be certain: try the password reset again and make sure that you are keeping a window open to the "success" screen before clicking the reset link in your email. Basically, the password reset requires that you perform the action within the same browser session (for security). And the whole thing must be done by you in under 10 minutes. Otherwise it will expire. If it still will not work, the next thing to do is to get a hold of the server login information. Typically this would be an FTP or SSH login. With that in-hand, I can either login and reset the account for you, or I can provide you with a script that you can upload that will do it for you. You may email (ryan at this domain) or PM the information to me.

I started with $pdo as an API variable name. But it didn't feel at home in ProcessWire, which uses clear names for all API variables (page, pages, users, input, sanitizer, etc.). The problem is $pdo feels like a brand name and someone not familiar with what PDO won't realize that it's referring to a database. So I thought it was best to call the API variable exactly what it is, which is a $database. Ultimately $database is more consistent with our API variable naming system than even $db, as none of the other API variables are abbreviated. As for confusion between $db and $database, I would only have that concern if we were planning to keep both mysqli and PDO long term. The $db will be deprecated and eventually dropped as an API variable. But we'll give it a major version or two.

After doing some testing here, it looks like we can run PDO and mysqli at the same time without any real problems that I can detect. So I'm going to backtrack a bit and go with Teppo's idea of keeping them both. Mysqli will be deprecated in PW, but remain there for a couple major versions at least just so that there's less chance of breaking backwards compatibility. The way I've set it up locally is that $db refers to mysqli as it always has, and $database (a new API variable) refers to the new PDO driver. So you can choose to use whichever one you want. The core and core modules will only be using PDO. The mysqli driver ($db) isn't actually instantiated until something calls upon it. That way there's only overhead of two database connections when/if your site needs mysqli for an older module or something. $db; // refers to mysqli $database; // refers to PDO As a result, it will not be necessary to consider PDO in order to make your templates/modules compatible with ProcessWire 2.4. But if you want to take advantage of PDO, while still being backwards compatible with older versions of ProcessWire, then you'd still have to have some duplication: if(wire('database')) { // Newer ProcessWire: PDO is available } else { // Older ProcessWire: only mysqli available } I'd imagine that once PW 2.4 has been out for a little while, people won't use $db (mysqli) at all anymore in PW. But using Teppo's suggestion, we can at least make it available for the foreseeable future, to reduce the chance of compatibility issues during future upgrades.

I've always happily used VI (VIM) and always will. But I found a way to make the newest PHPStorm look and behave like VIM, so that's what I'm slowly adapting to. So far I like it, it's a fairly impressive piece of software. Lets me still be in VIM (or at least trick me into thinking I am) while giving me all the power of PHPStorm. I was also motivated by their support of open source–they provided the full license for free for ProcessWire development.

One thing you could do would be to use PhpMyAdmin (or mysqldump) to export the whole database (or just the relevant field_[name] text field tables) to an SQL/text file. Load it in a quality editor that won't mess it up (like BBEdit/TextWrangler), and let it run a spellcheck. It should red underline everything it thinks is misspelled. It will be simpler to make manual corrections in this one file, and then re-import the whole thing, than to go through it online. As for space fixing, I wouldn't worry about it. Assuming they aren't non-breaking space characters, they will get collapsed down to 1 space in HTML either way. So it doesn't really matter how many spaces one uses after a sentence, because it'll always be displayed as one.

It looks like you have the "forgot password" module installed, so that's a good place to start. When you proceeded with the password reset process, did you get an email from it? When you completed the process, did you get the opportunity to enter a new password? When you completed the process, did it give you a success message?

Lets say you want to setup a role "pr-editor" that can add press releases as children of page /about/pr/. The page /about/pr/ uses template "pr-index", and the individual press releases (children) use template "pr-item". Create a new role "pr-editor" and give it "page-edit", "page-add" and any other permissions you want. Give that "pr-editor" role to a user that you will test with. Edit the template "pr-index". On the "access" tab, check the box for "add children" for role "pr-editor". Optional but recommended: On the "family" tab, set the "allowed children" to be template "pr-item". Save. Edit the template "pr-item". On the "access" tab, check the box for "create pages" for role "pr-editor". Optional but recommended: On the "family" tab, set the "allowed parents" to be template "pr-index". Save. Login with the user that has the "pr-editor" role and test it out.

Looks very cool Alessio! I look forward to seeing this in the modules directory.

I agree, there is tons of duplication, but just temporarily. You'll see plenty of duplication when I commit the PDO updates to dev. But I think it's okay since it's only for a few months until the 2.4 transition is complete. There's also the factor that PW doesn't have a lot of SQL queries in the first place–most of the application logic is behind the PW API. Converting all the queries in the core took me less than a day. Once 2.4 is released, I'm going to go back and remove all of the redundant mysqli statements, since they won't be relevant anymore. The syntax is a lot different between the two. I'd not ever used PDO before, but after playing around with it a lot, I thought it had a lot of benefits over mysqli. Most significant to me are the benefits with prepared queries and ability to use named parameters. I'd always thought mysqli prepared statements were awkward and annoying in almost every sense, so tended to avoid them. But in PDO, they are very clean and easy to use, and help to make not just safer queries, but more readable queries. Btw, if you don't need to check the return value, a wire('db')->query('sql statement'); will work the same between mysqli and PDO. So there are some instances that may not need to be accounted for. Backwards compatibility isn't a major factor here just because our API isn't based on DB queries. So usually when DB queries are used, they are doing something out of the ordinary. There aren't a lot of modules using SQL queries. I'm guessing less than a dozen. I figured better to get this change in place sooner rather than later, as it's a lot easier to do now than it will be a year or two from now. Good and interesting idea. Is it possible to have two database drivers (PDO and mysqli) connected to the same DB at the same time? Maybe it is, in which case, I'd be open to going this route. In that case, I'd probably just leave $db the mysqli one and make it deprecated but functional till 2.5, and call the new PDO one $pdo. No plans to cut ties with MySQL and no plans to adopt other databases just yet. Going with PDO is motivated purely by making sure we're giving our users the best tools out there. PDO is looked upon much more positively in the PHP community, and that perception has just been increasing over the last couple of years. But I think it's beyond perception and there's a lot of good reasons to use PDO over mysqli. Given this, I think that combined with our switch to supporting namespaces and Composer (2.4), it will help ProcessWire to grow in the PHP community in addition to the web developer community. It's also a good time to do it because 2.3 modules aren't going to be compatible with 2.4 already, purely because of namespaces. Though this one will be very simple for module developers to correct, simply by adding "namespace ProcessWire" at the top of the file (I think).

Sounds like you need a newer version of ProcessWire. I think the findComments() function was added in 2.2.9, but I'd suggest just using 2.3. I've not heard of that behavior before. What version of ProcessWire, and what browser/version are you using? When you upload, are you dragging-in, or using the 'Browse' button?

Not sure I understand the question–these are already static assets, what is there to cache? For something like images a CDN would probably be the next step, not a cache? Though note that ProcessWire does already cache image manipulations. So when you make an API call for an image at a certain size, that size gets generated only on the first call and a cached copy is returned for all later calls. They stay in their original location. They are already static assets, so no need to duplicate or copy them anywhere else unless for a CDN. ProCache hooks into all ProcessWire create/save/delete actions and makes adjustments to cache files as needed. So if you delete a page or change its URL, then the cache file for that page is deleted. ProCache also comes with a screen of config options for you to fine tune this further if you'd like. ProCache contains the rendered output produced by ProcessWire. For most sites, this is essentially a static HTML file for each cached page. It is the same thing as if you viewed a page on a website in your browser and clicked File > Save, producing a static HTML file.

Thanks for all the positive feedback you guys have posted there!

Thanks guys I really appreciate it!

I wonder what they will do when PHP 5.3 is EOL'd and safe_mode is gone for good? Something tells me they will be a lot better off.

Be careful not to pass values from $input directly into a selector. They would need to be filtered before going into the selector. // convert to unix timestamp then back to string, just to ensure it's valid (this is just one way) $date = date('Y-m-d', strtotime($input->post->date)); // sanitize name to be a pageName $name = $sanitizer->pageName($input->post->name); if($pages->get("parent.name=$date, name=$name, template=event")->id) { /* set error to 1 */ }