ryan

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 */ }

Since you are pulling them right out of $_GET (or $input->get), you should filter and sanitize them before doing your http_build_query. $types = array( 'limit' => 0, 'my_string_var' => '', 'my_int_var' => 0, ); $params = array(); foreach($types as $name => $type) { $value = $input->get->$name; if($value === null) continue; // not specified, skip over if(is_string($type)) $params[$name] = $sanitizer->text($value); // sanitize as string else $params[$name] = (int) $value; // sanitizer as int } if(empty($params['limit'])) $params['limit'] = 10; // set a default $new_query_string = http_build_query($params);

Rickard, I have updated your access so that you can now get to the Form Builder board. Thanks for your order! I think it is okay to go ahead and use 0.2.1, which includes the multi-language features. I am now using it in production and it's been reliable for me. Otherwise, you can always use the old reliable method of cloning the same form into multiple languages too.

Looks like a good creative use of tags there. I hadn't planned on them being used that way, but it seems like a good use case. It makes me think I should add a hasTag() function or something, so you wouldn't have to do something like a strstr() and would instead have reliable word boundaries between tags.

One way you could do it would be to make the FieldtypeComments::sendNotificationEmail method hookable. If you want to add 3 underscores before that function name (in /wire/modules/Fieldtype/FieldtypeComments.module), I'll make the same change here. From there, it should be hookable. In this case, you'd probably want to override/replace the method completely. To do this, your hook function would populate the $event->replace=true; Using PW 2.3 dev syntax: wire()->addHookBefore('FieldtypeComments::sendNotificationEmail', function(HookEvent $event) { $event->replace = true; $page = $event->arguments(1); $field = $event->arguments(2); $comment = $event->arguments(3); $subject = "New Comment Posted!"; $body = "A new comment was posted to $page->httpUrl by $comment->cite: $comment->text"; mail($field->notificationEmail, $subject, $body); });

One of the changes coming in ProcessWire 2.4 (and the 2.3 dev branch) is that we're switching the database driver from mysqli to PDO. Over the next few days, you'll see the ProcessWire dev branch begin to be compatible with both mysqli and PDO. By the time we hit version 2.4, it will only be compatible with PDO. If you develop modules or templates that perform SQL queries, and you want to have a head start, you can begin make your module(s) compatible now by checking what the DB driver is. Though I'm thinking most modules out there don't do any kind of SQL queries, so it won't matter. But for those that do, I wanted to go ahead and mention it since it'll be showing up on the dev branch shortly (I already have it switched locally). Here is an example that issues the same exact query with the two different DB drivers. $db = wire('db'); $name = "example"; if($db instanceof PDO) { // driver is PDO $query = $db->prepare("SELECT COUNT(*) FROM my_fake_table WHERE name=:name"); $query->execute(array(":name" => $name)); $count = $query->fetchColumn(); } else { // driver is mysqli $result = $db->query("SELECT COUNT(*) FROM my_fake_table WHERE name='" . $db->escape_string($name) . "'"); $row = $result->fetch_row(); $count = $row[0]; } If you have any queries that you aren't sure how to convert from mysqli to PDO, just post them here and I'll code it for you.The PDO queries tend to be a little more verbose most of the time (even if not above). But the use of named parameters is something that we need, and mysqli just doesn't have them (unless you like using question marks). There are other benefits to using PDO, but the named parameters are the main benefit in the short term.

Thanks Guy, you should have access now. What version of FormBuilder do you have? The issue was originally reported by MadeMyDay and fixed a version or two back (can't remember which). Try out the latest version (0.2.1) just in case. Let me know if you still run into it?

Of course, that's easy for you and me. But I'm guessing that most users would not know how to do that. It's a little bit of work to reverse what it does, and you have to know what you are doing. It's not feasible for the module itself to do it at uninstall just because it could take several executions to perform on a really large site. Basically, I don't like building/recommending solutions that can't be easily reversed just by uninstalling. But LinkMonitor/PageLinkAbstractor may be a special case.

If $config->urls->root will suffice for a given situation, it is potentially a lot less overhead to use it. When you access $config->urls->[anything] you are just accessing already-loaded properties. When you access $pages->get($id)->url, you are triggering a page load, if the page isn't already loaded.

I agree. I will correct that.