ryan

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.

The problem is that your links get converted to tags like {123} and the only thing that knows what that is, is PageLinkAbstractor. So if you were to ever stop using PageLinkAbstractor, all those links would be broken with no clear way to fix them short of manually editing each page. But if people really like the module still, I do have a much newer version (compatible with PageLinkAbstractor) called LinkMonitor that I could release. The nice thing about LinkMonitor is that it alerts you when it finds a broken link too. It checks for broken image/page links in the background when rendering pages. The only reason I've not released it is that I've been thinking abstraction of links isn't a good idea since it is 1) a drug you can't stop using; and 2) ultimately makes the content less portable. But maybe these are worthwhile tradeoffs. The 2.3 core comes with a module called PagePathHistory. It's not installed by default, but you can install it just by clicking "install" in the modules screen. It will keep track of all page movements and setup redirects to ensure links aren't broken.

This makes sense to me, I've gone ahead and changed it. It should appear on the dev branch next time I'm pushing updates to it, probably later this week.

On an unpublished page, there are two buttons at the bottom: Save and Publish. To save changes to an unpublished page, and keep it unpubilshed, you would click "save" rather than "publish". If you are worried about a novice editor, one good thing to tell them is to use the Save button at the bottom rather than the publish button at the top. Perhaps the button at the top should be the Save button, with the publish button at the bottom instead–I'll look into that.

$pages->find("parent.template=news-month-archive"); $page->rootParent->find("parent.template=news-month-archive");