ryan

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?

I don't know enough about this particular tool to say for sure, but if you are able to modify the core plugin to get it working, let me know what you change so that I can make the same change in the core. A lot of our users are in Finland and would like to have full support in everything from the core.

Horst, hadn't heard back from the last PM - did you get this figured out / able to install?

Since this module does not have a multi-language version, the best bet is to make your own with a repeater.

It is possible to extend the existing images field (by code) to make it do what you want. But a simpler solution (especially on the multi-language side) would be to use a repeater, where each item has a single image field and you add whatever text/multi-language fields that you need.

I'm thinking you probably don't want to use FieldtypePassword for your temporary password. I'm not sure PW will even support two of them in the same template. For a temporary password, I'd probably keep it in the $session rather than in a page field (session variables are temporary server side storage, with the data not present in the cookie). Since it's temporary, you don't really need it to have a permanent representation in the DB. This would also ensure the temporary password automatically expires with the session. Just don't ever show the user that password from the session, only use it to compare with one you've sent to them by some other means like email.

Joe, we haven't updated to ZipArchive in that part of ProcessWire yet. But if you know exec() is enabled, then try prepending your server path to the uploadUnzipCommand so that rather than "unzip ..." it says "/usr/bin/unzip ..."

That actually looks like a bug in this module. The error message is correct, as there's a "continue" in the middle of the function (not sure what I was thinking–I must have converted a loop to a function and not hit a date that would trigger the line). I'm not in the office where I can fix it, but I think it should be safe to just comment out or remove that line.

I haven't figured this one out yet but on the to-do list before 2.4 is released.

I wasn't aware of this issue and haven't ever experienced it myself. But just attempted to reproduce and sure enough I got the same thing. Here's a fix (attached), place this is /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.js -- I'll commit this to dev when I get back in the office. ProcessPageAdd.js.txt

16k pages is a lot to deal with one one request (if you are using the API as opposed to hitting the DB directly). It looks like MySQL has some resource limiter placed upon it in your case, so re-connecting probably won't help you (though that's a guess). You probably need to reduce the quantity of pages you are working with there, perhaps setting a limit (5000?) and keeping to it for each run. But if you want to check for a DB failure, your best bet is to wrap your operations in a try/catch. But I think the solution here will involve reducing the amount you do in a single cron run.

In your template files, you can always control access just by performing your own checks, and that may be the simplest route here. For instance, you could have something like this at the top of your template file: if(!$page->category->viewable()) $session->redirect('/path/to/login/page/'); Another way to do it is to hook into Page::viewable to perform your own permission checks. The benefit here is that you would keep it all in one place: wire()->addHookAfter('Page::viewable', function($event) { // if it was already determined page is not viewable, then we'll exit and stick with that // this may or may not be the behavior you'd want, but you probably want some "early exit" // thing to check so that you aren't completely disregarding what the existing // $page->viewable() returned if(!$event->return) return; // check that this page has a 'category' field that we are using for permission $page = $event->object; if(!$page->category) return; // we'll abort now if there is no category // if category isn't viewable, we'll say this page isn't viewable either if(!$page->category->viewable()) $event->return = false; // you could also do things like check user roles: // if(!$user->hasRole('some-role')) $event->return = false; });

I don't know of any changes that would have affected the URL it goes to (s=1 for example). I don't think there have been any edits to ProcessPageEdit in the last couple of minor dev versions. The dev version is up to 2.3.9 if you want to give that a try, but so far the issue you are experiencing seems like a mystery. Is it only occurring for you in Firefox or other browsers too?

That's a good question and I'm not positive about the answer yet. This is the second time I've see SetEnv not liked by a webhost, so I think we need to at least have a note about it mentioned in the .htaccess file as a possible thing to comment out when a 500 error occurs. The SetEnv here really is only to pass along a message to the installer, and not crucial at all. I've not seen an issue with DirectoryIndex before though, so will keep an eye out to see if that one shows up at any other hosts, in which case we should document that issue too.

Yep it's a bug, I'll get this one fixed soon but just had to take care of a few other things first (like catching up with the forum).