ryan

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.

Thanks Manfred62, just corrected that and will send in the next commit.

You have to admire their social networking strategy. I think there are a lot of folks like me that have never heard of them, and these contests make their brand known. We derive the same benefit... it helps us whether we "win" the contest or not, as seeing ProcessWire on the first page may help get it on the radar of other visitors that don't already know about it.

Your code looks correct to me, other than that it's missing a kicks column. Is this the actual code that you are using? I'm guessing that your question is the same as mine: why are the punches and kicks columns blank for player 2 and 3? The answer isn't clear to me, as it appears they should be populated. It might be good for us to get a look at the actual code in use here.

It would be executed in a single query, except that there is a repeater in there. The repeater portion of the selector ends up executing a separate query. Repeaters always add overhead. Though 1 second still seems like a long time for that particular find(). Are you sure it's the find() call that takes 1 second, or does the 1 second include output generation time? If you find that it is the find() call that's the bottleneck, ideally you might want to make a copy of that enddate field in your event template, and have it populated automatically with a hook in your /site/templates/admin.php. You could hide the field so that it's not visible in your admin interface. /site/templates/admin.php $pages->addHook('saveReady', function($event) { $page = $event->arguments(0); if($page->template != 'event') return; $enddate = 0; foreach($page->times as $time) { if($time->enddate > $enddate) $enddate = $time->enddate; } $page->enddate = $enddate; }); In doing this, you are essentially creating a cache for the max 'enddate', and that cache should give you a big performance improvement. If you take this route, you'll have to create the cache once at the beginning, just to establish values: foreach($pages->find("template=event") as $event) { $event->of(false); $event->save(); } You could then delete the above code after running it once.

Thanks for investigating this. If you find that it is something repeatable please send over a GitHub bug report (or post here if you prefer). I did just try to reproduce it myself (in MAMP), but wasn't able to yet.

Does your /stats/ directory have its own .htaccess file in it? Based on the name (stats=web stats?), I'm guessing it has an .htaccess file and that it is being used for http authentication? If so, it could be the ErrorDocument. Try adding this to the top of your .htaccess file in /stats/: ErrorDocument 401 "Unauthorized"

Specifying /path/to/parent/ is only supported by database-driven selectors at present. That would be a good one for us to add to the in-memory selectors. You could do this though: $parent = $pages->get('/path/to/parent/'); $events = $events->filter("parent=$parent"); Which is essentially the same as what you did: $events->filter("parent=4352");

That was in Firefox right? The issue was that the jQuery show() method defaults to showing it with "display: block". In order to display it correctly, Firefox needs it to be "display: table-row". This issue is fixed in the latest version, pushed out yesterday. You certainly could. Though they wouldn't technically be Page fieldtypes, they would just be IDs of pages you gave them the option to select from your custom Inputfield. But you could make it behave just like a Page reference Fieldtype without much trouble.

What language would be represented by the root URL then "/" ? I was able to reproduce it. I've just pushed a fix for this. Though have only tested it locally where all my sites are running off of subdirectories. Please let me know if you run into any more trouble with it.

It's been awhile since I've used this module, but I think this could be accomplished by using another role. Keep in mind a user can have any number of roles (people often assume a user can have just one role). Take the role that you want to have limited access, and give it page-edit, but not page-edit-title permission. Assign to the appropriate template. Note however that the 'title' field may not be a good one to do this with, as the field is typically required for creation of any new page. So unless the role you are talking about doesn't need to create new pages with the given template, you may run into trouble limiting access to the title field.

Sounds like you are on the right track. Make your default language the one you want guest to see at the root URL. For setting your own language in the admin, this isn't related to the default language. Since you are a logged-in user, you can choose your language from your user profile.