ryan

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");

Art, could I look at the relevant template files? If you don't want to attach them here, feel free to PM them to me.

That makes sense to me. Seems like a good approach.

PHP safe_mode was deprecated in 5.3.0 and eliminated starting in version 5.4.0. If the web host is advising not to turn it off, it would make me concerned about that web host's security. Any idea why they are advising that or suggesting that it involves a performance penalty? (it sure shouldn't)

I'm not sure I follow all of this or understand the https certificate issues that may be interfering with it, but you might want to try having a second invisible iframe that comes before the first (in the source/markup), to attempt to register/initiate the session?

I am guessing that maybe there is a module installed that had an older jQuery version dependency? jQuery tends to deprecate a lot of widely used stuff with new versions. We upgraded jQuery versions in the 2.2 => 2.3 upgrade, so if there was some jQuery dependency in a module installed in 2.2, that seems like a potential place to look. I would start by uninstalling 3rd party modules, especially those that might affect the PageList and see if you can track it down. Let us know what module it is.

Whenever you get that error message, go and enable debug mode in /site/config.php, just so that you can get some more details as to what is happening. Double check that your homepage template has the guest role enabled. No need to sanitize the password btw.