ryan

Craig is correct, as this is most definitely related to the sessionFingerprint, as your IP address is clearly changing when the VPN disconnects and reconnects. It sounds like in your case, you should disable that feature by setting it to false in your /site/config.php file. I'm 99% sure that'll fix the issue you are experiencing.

The consensus around here has been that captcha is not worthwhile. Most of us get better results by using honeypots, which are simpler both for the user and the developer. However, if you or anyone else decides to build a Captcha Inputfield I'm here to support and answer any questions you have, and I'm sure there will be an audience for it in the modules directory. But if your goal is to prevent spam submissions, definitely look into using a honeypot first, as your users will thank you and you'll likely see less spam too.

Conversion of image type is more complex than just changing the extension. All the data in the image has to be uncompressed then re-compressed with the new format, and that's something that goes beyond the scope of our image manipulation functions at present. While true that some browsers will recognize a jpg as a jpg regardless of extension (by detecting the type in the image data), the file becomes essentially corrupt as it's no longer consistent with the indicated type.

Are you suggesting that a PSD file should be automatically renamed to a JPG file? Those are two very different file types. However, if you have the need to do that, I may be able to suggest a hook. But I anticipate you wouldn't be able to use any of the image manipulation functions on the renamed file without getting exceptions (unless PSDs can now pretend to be JPGs through some file data tricks). Regardless, a PSD is a full-blown Photoshop file and not an appropriate format for web storage unless you intend to distribute source files, in which case you'd definitely want to keep the PSD extension.

The module may need a Pages::deleted hook: public function init() { $this->pages->addHookAfter('deleted', $this, 'hookPageDeleted'); } public function hookPageDeleted($event) { $page = $event->arguments(0); $this->db->query("DELETE FROM " . self::TABLE_NAME . " WHERE pages_id=" . (int) $page->id); }

Thanks lpa! I am adding these to dev.

Field settings are saved in a compressed format that eliminates empty values. The value 0 is considered an empty value because it resolves to true in comparison to a blank string. So a blank string can be seen as the same thing as 0 in this case. Are you able to enter and save negative values on your page that is using this validation? If so, let me know as the validation in InputfieldInteger might need an adjustment.

Is your error message still appearing? ProcessWire doesn't abort a save even if there was an error on some field, so that is normal behavior. Though it will prevent an unpublished page from being published if there is an error occurring. If you want to literally prevent the save from occurring, you may have to throw an exception.

I'm not sure there's really much difference in sending them a reset URL or a password, as neither is encrypted once it goes out in an email. Though I prefer to use a unique reset URL, as it's less work for the user. Expiring that URL is definitely a good idea. I don't see it often used, but I also like to limit the usage of that URL or password to the session that initiated the request. Meaning, when you request the password reset, you get a unique token set in the session, along with a timestamp of when it was set (so you can determine when it should no longer be valid). This token can be the same as the unique URL you sent them. When the user comes back from the URL they clicked on in the email, the request is only honored if the token you set in the session is still active and matches with the URL they requested. Using this method provides a better accounting for the fact that email is inherently insecure.

Definitely check out version control for text fields if you haven't already. This module is so good, that it's rare I wish for anything else. That's not to say that there isn't more to be done with regards to core version control, but Teppo's module covers the most common version control needs beautifully.

For truly dynamic pages that need to change on every request, don't use a template cache or ProCache, and instead use MarkupCache for the parts that don't often change (if you need to use a cache at all). No doubt, delegating things to javascript where possible is very cache friendly with template caching and ProCache. Even if you are shifting things to be ajax-loaded, the ajax requests can themselves be delivered by ProCache or template cache, perhaps just on a shorter cache time. Not to mention, the results of those ajax requests can be cached client side in cookies if needed, serving as a client-side cache that you control. But I honestly don't think most people need to get into this level of caching, unless dealing with some major traffic considerations and/or server that can't keep up with it dynamically.

To check category permissions I need permissions set by template access for each category? DIfferent templates for the categories? Yes, though I used that only to keep the example really simple. Your actual needs may demand something more. For instance, if you wanted to define the roles that could access, with each category page, then you might create a new "custom_roles" Page reference field that selects from pages in /processwire/access/roles/. Then add that field to your "category" template, and edit your categories to select the roles. Then you could modify the previous example to be something like below, that adds a viewable() hook to category pages as well. /site/templates/admin.php <?php wire()->addHookAfter('Page::viewable', function($event) { // if it was already determined page isn't viewable, exit now if(!$event->return) return; $page = $event->object; $user = wire('user'); if($page->template == 'category') { $found = false; // check if user has any of the roles selected for category foreach($page->custom_roles as $role) { if($user->roles->has($role)) { // user has the role, so this page is viewable $found = true; break; } } // if no matching roles found, page is not viewable if(!$found) $event->return = false; } else if($page->category) { // if category isn't viewable, we'll say this page isn't viewable either if(!$page->category->viewable()) $event->return = false; } }); // the rest of admin.php ...

Module has been updated for this change (config.entities=false)

Teppo, the way you describe the entities config option, that makes sense to me. Given these issues, I wonder why they have it true by default. I have updated the InputfieldCKEditor module to have the entities option set to false by default. I really can't think of any security issues with doing that, especially given that we're requiring HTMLPurifier for the inline editor. As for why I seem to be getting the entities=false behavior for quotes already, I have no idea. Maybe something to do with HTMLPurifier and inline mode vs. regular mode.

Since ProcessWire doesn't generate markup for you, you'd have to do this from the API side. Here's a simple example where you have an email subscription form and you accept an email address and store it in the 'title' field of a new page. <?php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { // parent where we will store our new page $parent = $pages->get("/subscriptions/"); if($parent->child("title=" . $sanitizer->selectorValue($email)) { // this checks if we already have this email echo "<p>You are already subscribed!</p>"; } else { // create a new 'subscription' page $subscription = new Page(); $subscription->parent = $parent; $subscription->template = 'subscription'; $subscription->title = $email; $subscription->save(); $showForm = false; echo "<p>Thank you! You have been subscribed.</p>"; } } if($showForm) echo " <form action='./' method='post'> <label for='email'>Enter your email address</label> <input type='email' name='email' id='email' /> <input type='submit' name='subscribe' value='Subscribe' /> </form> "; There are also some tools that can automate this process to some extend, like FormBuilder, and the FormTemplateProcessor (proof of concept), among others. But the best way to get exactly what you want is to use the API.

That module is meant for admin use only and I don't think it's something that could be used on the front-end as it performs checks to make sure that the page is editable, etc. It is also capable of generating new images based on your selections (for resizing) so it particularly safe from a front-end standpoint either.

Google Maps doesn't like being initially hidden. It will produce the effect you see in your screenshot. The solution would be to initialize the map at the time you intend to show it (like after the reveal modal opens). An alternative would be to trigger an event on the map, telling it to redraw when shown. Credits to diogo for figuring this one out, as it's the solution we implemented in the InputfieldMapMarker for when a map is on a tab. For Zurb Foundation reveal, you'd do something like this below. The "mgmap1" is the map from MarkupGoogleMap module, so you may need to change that according to your map name, etc. The setTimeout() below may not be necessary, or you may be able to reduce the delay from 250 down to 100 or something. $(document).on('opened', '[data-reveal]', function () { setTimeout(function() { google.maps.event.trigger(mgmap1, 'resize'); mgmap1.map.setCenter(mgmap1.options.center); }, 250); });

I've used a remote database before and saw some slowdown, but not major. Is the connection is going through a consumer link (cable, DSL, etc.)? If so, that may not be practical for a production site. Otherwise, I'd think it should work, even if not ideal. Most hosts don't open up their MySQL for outside connections, so if you are using one that does, it might be good to check with them to see what they suggest in terms of ideal settings.

Thanks for mentioning that saml. I've had to do the same thing a few times with clients that were running their own server. This is not something you'll encounter in a professional hosting environment, but when running your own server or dealing with a client running their own server, the AllowOverride setting is something you are likely to come across.

Same answer as before. Saving a template does not include a $_POST variable with embedded HTML, so it's not going to trigger mod_security. Mod_security doesn't like $_POST or $_GET variables with embedded HTML, especially more than one of them (like body and sidebar). Basically your web host has to disable that aspect of mod_security, as it is definitely not CMS friendly. You may also be able to resolve it by making sure you have not more than 1 field with HTML in it (i.e. just a "body" field). This is not uncommon, because WordPress typically only has 1 HTML field present, so some hosts configure their mod security to allow 1 through and not more. Personally though, I would not use a web host placing this kind of restriction unless the hosting is free.

There is so much mentioned above, that I'm not sure there is an answer without a more specific question or code snippets to respond to. This topic of this thread is not the approach that I use, but I think it's a good question so don't want to leave it unanswered. I think that for the most part, the same performance rules would apply here that would apply regardless of how you are approaching templates. You don't have much to think about if you are dealing with under a hundred pages. Once you start getting into hundreds and thousands of pages, you have to take care that you aren't loading hundreds and thousands of pages on every request by using things like pagination and calls like $page->children("limit=10") rather than $page->children(). If you'd like, tell us more about your context and details of the approach you are using we can give a better answer.

When you are using pagination, PW assumes all of your selectors are paginated (see the side effects section on the pagination docs page). As a result, you need to tell it which ones are not by adding a "start=0" to it. I'm thinking this will fix the issue in your case?

This is on the repeater roadmap, but no ETA on this yet. There are currently a couple of items in front of it, for repeaters: custom labels, custom sort, and collapse settings. Once those are in place, we're going to start at looking for ways to introduce pagination.

The trash shouldn't be a consideration in a web service feed like this, because items in trash are targeted for deletion and we have no control over when somebody will decide to empty the trash. So for all practical purposes, items in the trash should be considered the same as deleted items here. The code above won't pull pages out of the trash, so it should already work the right way, so long as you don't add "include=all" to the selector. If you do need the behavior of include=all, then I would suggest doing this instead: $trash = Page::statusTrash; $results = $pages->find("template=product, status<$trash, id=" . implode("|", $ids)); That should give you the same behavior as "include=all" but exclude pages in the trash.

It sounds like the second snippet of code is working, but not the first. Double check that URL segments are enabled in your "home" template settings. This is on the URLs tab. If that's not it, look at your PW version. Is it older that 2.3? If so, try replacing "urlSegmentStr" with "urlSegment1". Still not working? Add this at the top of your /site/templates/home.php file, temporarily, just to make sure it is working: echo "<h1>urlSegmentStr: $input->urlSegmentStr</h1>"; What do you see?