ryan

It's true that ProcessPageSearch may change down the road, though no specific plans on that at present. But if you are worried about that, rather than extending it (in the PHP class sense) you could just copy ProcessPageSearch to another module, and modify it to make your own. The PW API behavior doesn't change, so when you make something where that is the dependency (as opposed to the implementation of class that's already an endpoint) then it's a safer bet.

This might be too complex of a scenario for me to reproduce very easily here. I wonder if I could get a copy of the database, or at least an export of the field_acara_code table? Also wanted to check if you've tried to run a DB table repair on the field_acara_code table? If this issue isn't due to some stray character or encoding issue in the table data, then it sounds like potentially a broken index, or some MySQL index behavior I'm not aware of. It's interesting to me that '%=' worked while '=' didn't, because '%=' bypasses the index, doing a full table scan, whereas '=' uses the index. It might also be good to know what version of MySQL?

While I can't duplicate the small square, I do see that the dropdowns aren't showing for a user with the permissions you mentioned. I've fixed it and it'll appear in the next update. Thanks! I honestly don't agree, and really don't like sites/apps opening new windows/tabs for me (that's what option+click is for). But you aren't the first person to mention it, so I'll try to accommodate both preferences somehow or another.

You could replace PW's link dialog with TinyMCE's native link dialog, as I believe it provides the option of more attributes. I think this can be done by replacing references to "pwlink" with "link" in the TinyMCE settings, though have not tried it recently.

Uncheck the box to the left of latitude, then delete the latitude and longitude (make them blank). Save. Following that it should return to the default/unset location specified in the field settings.

Adrian's code shows you the date of the last updated page in the site (which may or may not be the current page being viewed). If you instead want to show the date that the current page being viewed by the user was last updated, you'd do this instead: echo date("j. F Y", $page->modified);

It wouldn't be safe to exclude pages without template files from most find()s as that would be making the assumption that all find()s are for presenting navigation or search results to a user. PW makes no assumptions about what you are using the data for, so couldn't safely exclude pages based on that factor. If we were to implement something for this in the core in the future, we'd probably do it with a new selector option like "template_file_exists=1" or something along those lines. But if you've got pages without template files showing up in your search results, it might also be good to look at whether your search might need to be made more specific, or if your pages with no template file should be excluded with an access controlled parent. But I'll keep marinating on this template_file_exists option for selectors, as it may be a worthwhile addition.

Great tutorial Soma! Thanks for making it. One thing I wanted to mention is that this syntax: wire("fuel")->set("helper", $this); has been replaced by this syntax: wire('helper', $this); // or this: $this->wire('helper', $this); But of course your tutorial is correct in using 'fuel' since it would be compatible with past versions of ProcessWire too. Just wanted to mention it since I think the API is simpler if all getting or setting of API variables is just done through the wire() or $this->wire() functions. But the old syntax will always continue to work as 'fuel' is itself an API variable, but one that I figured makes more sense as an internal-only API variable.

Sounds good, I'll add it.

Since this module doesn't have a toggle for that particular need, you might take one of these routes: copy the module files into /site/modules/MarkupPagerNavCustom/, modify it directly and install. str_replace or preg_replace in the output it gives you, to modify it according to what you need (i.e. adding next/prev links) you could always prepend/append the next/prev links with jQuery pretty easily.

Soma is right, this was already added a few months ago. Double clicking the trash icon on any file/image now marks all for deletion. Double click again and it unmarks them.

Do you have a green message that literally says "Saved page"? What is the URL in your address bar after saving? What version of ProcessWire?

For that I'd suggest using a multiple selection field rather than a single selection field. The simplest examples would be a <select multiple> or checkboxes. You can tell PHP to submit the result as an array by appending "[]" to the field name, i.e. <select multiple name='something[]'> <option value='1'>One</option> <option value='2'>Two</option> <option value='3'>Three</option> </select> From the PHP side, you can retrieve it like this: if(!empty($input->get->something)) { foreach($input->get->something as $value) { $value = (int) $value; // $value contains either: 1, 2, or 3 } }

I will upgrade to the latest MAMP here soon and see if I can reproduce it. You've got me wondering if there is some incompatibility with that version of MySQL (5.6.14). Though if it were widespread, you'd think we would have heard about it more than once.. and maybe we will. I'll keep an eye out and do some testing here too.

I don't know a lot about memcached either, but I know of others using it successfully with PW (after that change you made) and have not heard of any other issues. If you find it to be an issue, you could always switch to PW's native database-driven sessions module (included in the core).

I've been working on this one for a few months and just launched it this morning: http://villasofdistinction.com I also did the previous iteration of this site, 5 or so years ago (which was running ProcessWire 1.0). The new site is powered by ProcessWire 2.4 (2.3 dev). The site is responsive and designed for a good experience on both desktop and mobile. While I did all the development, the site's design/look and feel was created by the client (they have their own internal design agency). Most of the work in this project was actually not anything you can see on the front end. Instead, most of the work went towards back-end management, workflow and web services. The client has a large number of editors and agents that needed various capabilities, workflows, feeds and such. So there's a lot more going on here in terms of a management platform than in the previous iteration... and that's mostly what kept me busy for so those few months. Modules used here: Foundation 4 Profile All In One Minify (AIOM) FieldtypeMapMarker (with MarkupGoogleMap) Pro Cache Form Builder Hanna Code Redirects Selector test Changelog Version Control for Text Fields Batcher Admin Template Columns CKEditor Select Multiple Transfer CollagePlus And a few custom modules

I don't see the recommendation there anymore either. It used to be there anyways. I think the primary concern is that "domain.com" is usually associated with the homepage of a site. When people link to you as an entity (as opposed to a specific page) they generally link to "domain.com". But if your root URL (represented by "domain.com") performs a redirect, you sacrifice the pagerank potential / link juice. While pagerank may be allowed to flow through redirects, it's far from a certainty. I would suggest there could be some real SEO risk in having your homepage be a redirect. Maybe not a penalty risk, but a long term reduction of pagerank potential gained by external links.

I thought that "/" was the one URL you could count on every site having. At least, having a root URL that performs a redirect is not considered a good practice from an SEO standpoint (google webmaster guidelines say not to do this). That's why PW makes sure that your default language covers that one URL rather than "/default-language/". This would be filed under "it's a feature not a bug". But I'm not opposed to making it configurable if it's useful to you or anyone else. See the latest commit to dev, which now lets you configure that behavior in the Language Support Page Names module configuration screen.

This may be a problem related to ProcessWire wanting to use files for sessions and your server configured to use memcached, at least that's what the error message seems to indicate. The dev branch version has detection for this, so you might try switching to the PW dev branch and seeing if that fixes the issue for you (I'm guessing it will). Or if you want to quickly test it, just grab the index.php from the dev branch and replace the one in your installation.

If they should all be validated in the same way, then yes that's fine. Though I would usually convert something like this to this: $validateTextFields = array('location', 'notes', 'another', 'another1', 'another2'); if(in_array($key, $validateTextFields)) { // validate text value } If any integer is acceptable, you can sanitize just by typecasting the value to an integer: $cleanValue = (int) $dirtyValue;

Good idea about removing the permanent status–I will do that. I think it's best to leave the RTE in the core due to the fact that it's tightly integrated with other core components (ProcessPageEditImageSelect, ProcessPageLinkEdit). Updates to those modules and TinyMCE usually go together. Though the ImageSelect and LinkEdit modules can be used by other editors too (CKEditor), but whatever RTE is bundled in the core is what sets the core integration available to all RTEs. Or perhaps better to tie it to a more major version (3.0) when there will be more understanding of an upgrade involving more than a /wire/ directory replacement. I'm thinking 3.0 is also the version where we move everything to namespaces as well. If we go this route, I'm not sure how many more 2.x versions there will be after 2.4, as we may start working towards 3.0 sooner rather than later. But if we make that switch in 3.0, I think we've got to keep TinyMCE 3 as an available module for install, even if not in the core, for legacy use. Many (most?) people don't care about the differences between TinyMCE 3 and 4 like we might, so they might prefer just to keep using what they've already configured even after the rest of ProcessWire is upgraded. Thanks, I will check that out. I'm not sure that I was available when I last played around with TinyMCE 4. Good, because that adds another point in our favor for people that want a CMS that already includes an RTE (even if that doesn't mean anything outside of marketing). I also like the idea of just including both in the core (TinyMCE and CKEditor). But considering these RTEs represent the largest use of disk space in the CMS, I'm guessing others wouldn't agree with that strategy. Personally, I don't care about the disk space issue, as disk space is essentially free these days. But bundling two big RTEs might be considered bloat by some, so I'm shy about doing that.

Do you see any errors in your JS console? Are you using any kind of caching (TemplateCache, ProCache, MarkupCache) on the comments or comments page? Are you using the redirect after post option in your comment settings? It might also be good for us to get a look at your code that outputs the comment form.

That Apache redirect rule is essentially saying "if the hostname doesn't start with 'www' then redirect to www.hostname.com". That rule would not be compatible with a site that you are using to serve content to different hostnames. If 'mobile' is the only other hostname you need to serve, you might try adding it as an OR condition, i.e. "if hostname doesn't start with 'www' OR 'mobile' then redirect to www.hostname.com": RewriteCond %{HTTP_HOST} !^(www|mobile)\. [NC] RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

It would be ideal if there were some TinyMCE setting that could be used to disable this behavior. I'm guessing that there must be, but I don't know what it is. Beyond that, I think your solution is just fine. Though it looks to me like you could use a strpos rather than a preg_match, and a str_replace rather than a preg_replace here, as you are just matching a character rather than a pattern. Regular expression functions like the preg_* functions should generally be avoided unless you need to match a pattern. That's because they are relatively slow. Though it's unlikely there would be any perceptible difference by switching it. If you wanted to fix the value before it is stored in the DB, another strategy you could take would be to hook into InputfieldTinyMCE::processInput and fix the value right after processing occurs. /site/templates/admin.php <?php wire()->addHookAfter('InputfieldTinyMCE::processInput', null, 'hookFixNBSP'); function hookFixNBSP($event) { $value = $event->object->value; if( !preg_match('/\x{00A0}/u', $value) ) return; $value = trim( preg_replace('/\x{00A0}/u', " ", $value) ); $event->object->value = $value; }

It sounds like Securimage must try to set it's own session path? I don't know enough about Securimage to say where you'd place that, but the first place I would look is in any config/settings file that comes with that software. If there's nothing to be found there, perhaps you can just add the line to the top of its index.php or whatever php file initializes it.