ryan

I'm not sure what's up but it looks like the caching from GitHub was failing, as I tried to reload it several times but no luck. That issue has turned up in the past too. I went ahead and made /api/cheatsheet/ a redirect to http://cheatsheet.processwire.com - major thanks to Soma for developing the Cheatsheet into a ProcessWire site. It's quite impressive the way he's got it setup with Fredi too. I'm going to start adding more new PW 2.3 functions to it today.

You can enable this option by editing your /site/config.php and setting $config->advanced=true; Next edit the template (Setup > Templates > edit) that you want to be able to change the createdUser. Click on the "system" tab (this is only visible in advanced mode). You'll see checkboxes for various options–check the appropriate one and save. Go back to your /site/config.php and remove the $config->advanced line you added earlier… as you don't usually want advanced mode on (some settings can be dangerous). But you should now have the ability to change the created user for pages using that template.

I've now got ProcessWire (local dev) fully converted to PDO and running with both PDO ($database) and mysqli ($db) available to the API. When in the admin, the debug mode info at the bottom highlights queries from each, so that you can more easily identify mysqli queries that you may want to convert to PDO. As a matter of efficiency, ProcessWire doesn't actually initiate the mysqli connection until you access something from the $db API variable. Meaning, the core and a stock install of PW doesn't use mysqli at all (or attempt a DB connection through it), but it makes it available if any modules or your site want it. In order to achieve this, I had to abstract the existing mysqli Database class behind a passthrough gatekeeper class. The only way you will notice that is if you are using any kind of type hinting for the old Database/mysqli class, OR if you are using procedural mysqli functions. I don't think I've seen any modules type hinting the old Database class or mysqli except for my own (like Form Builder). But I do think I've seen procedural use of mysqli at least once (I think it might have been in one of Teppo's modules?). Anyway, not sure if this matters to anyone, but just in case, here's the things to watch for with mysqli: // If you are type hinting mysql or Database like this… function example1(Database $db) { ... } // this function example2(mysqli $db) { ... } // or this // …then remove the type hinting: function example1($db) { ... } function example2($db) { ... } // if you are using mysqli procedurally with a $db param: $result = mysqli_query($db, "SELECT COUNT(*) FROM pages"); list($count) = mysqli_fetch_row($result); // use it without specifying $db param… $result = mysqli_query("SELECT COUNT(*) FROM pages"); list($count) = mysqli_fetch_row($result); // …or better yet, use the OO version: $result = $db->query("SELECT COUNT(*) FROM pages"); list($count) = $result->fetch_row(); Since PW 2.4 will be backwards compatible in terms of the database, lets not worry about switching our 3rd party modules over to PDO until 2.4 is actually out in a stable version, which is still months away.

The hook you'd want to use would probably be Page::viewable. However, hiding pages that a user can't edit just doesn't work in a tree hierarchy, because how then would a user get to the pages that they can edit? A better strategy would be to figure out exactly what you don't want the user to see in the admin tree, whether it is branch of a tree, a specific page, or all pages using a specific template. And take into account the fact that nothing under the page(s) will be editable since the user won't be able to navigate to them. public function init() { $this->addHookAfter('Page::viewable', $this, 'hookPageViewable'); } public function hookPageViewable(HookEvent $event) { if(!$event->return) return; // page already not viewable $page = $event->arguments(0); if($page->template == 'my-private-template') $event->return = false; }

Since the error is coming from Apache, I would bet that it's from an Apache module (mod_security?). The 401 authorization required is also interesting. PW doesn't care if it's running from web root or a subdir. But I would check your web root for an .htaccess file and see what's in there–it's possible there's something in there conflicting with/overriding ProcessWire's .htaccess.

I'm not really sure how this module could be tweaked for local videos, as it's built around oembed, so really more about web services than local hosting. I think that the best solution for local video hosting will depend largely on what player you want to use to display the videos.

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).