ryan

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.

I still think this strategy would be fragile over time. It's not the job of a web service to keep track of deleted things, that's the job of the client accessing the service. I don't know of any major web service that attempts to bundle deleted items in a feed. The problems arise when something really does get deleted, and your web service has no record of it. If the client accessing your service expects you to keep track of all deleted items, then this will break sooner or later. You can't count on everything being in the trash. That is just a temporary container. Sooner or later it has to be deleted. Not to mention, showing deleted items in the feed means your feed has unnecessary overhead. The responsibility has to rest on the client side or else the system will break down at some point. Here's what I usually do on the client side: Keep two extra fields per record in the feed: import_id (integer) and import_time (unix timestamp). The import_id reflects the unique ID of each item from the feed, and is needed to connect items from the feed with your local items. The import_time reflects the timestamp of when the item was last updated. Before the feed is pulled, the client records the current timestamp and keeps it somewhere, like in a variable: $startTime = time(); Then they pull the feed, iterating through each item in the feed and updating or adding an associated page item for each. Note that the import_time of each page item is updated regardless of whether any changes occurred. You are essentially identifying all the items that are still active by updating their import_time field. $parent = $pages->get("/path/to/items/"); $http = new WireHttp(); $feed = $http->getJSON('http://domain.com/path/to/feed'); if(is_array($feed) && count($feed)) { foreach($feed as $data) { $item = $pages->get("import_id=$data[id]"); if(!$item->id) { // add new item $item = new Page(); $item->parent = $parent; $item->template = 'some-template'; $item->import_id = $data['id']; $item->save(); } else { $item->of(false); } // populate item $item->title = $data['title']; // ... // update import_time $item->import_time = time(); $item->save(); } // after importing the feed is complete, find the pages that were NOT updated // these pages may be deleted or trashed foreach($parent->children("import_time<$startTime") as $item) { $item->trash(); } } I like if the web service also provides an "exists" function, to determine that an item really has been deleted. This returns a thumbs up or down for each item requested, as to whether it exists or not. It's not entirely necessary, but it adds a little extra peace of mind as a backup in case something goes wrong. This is described in one of my posts above. Combined with the code above, the part that does the $item->trash() would just be preceded by a call to the exists feed to reduce the list of $items to only those that are confirmed to be deleted: // find which pages weren't updated $ids = array(); foreach($parent->children("import_time<$startTime") as $item) { $ids[] = $item->import_id; } // send the IDs of those pages back to the feed, asking it to confirm deletion $feed = $http->getJSON('http://domain.com/path/to/feed/exists?id=' . implode(',', $ids)); foreach($feed as $id => $exists) { if($exists === false) { // deletion confirmed, so page may be deleted $item = $pages->get((int) $id); $item->trash(); } } As for memory issues: any feed dealing with a lot of data needs to provide pagination of feed data (example), otherwise it will not be able to scale and will break if there is too much data. Pagination of a feed is a lot simpler than you'd expect for both the service and the consumer. It not much more than wrapping everything in a foreach.

Make sure that you are putting that code somewhere that gets executed on every request, and before any code that needs to use it. Also, attaching the hook to $pages may be the problem in your case, because Pages is different from Page in terms of the underlying PHP classes. A better approach would be this: wire()->addHookAfter('Page::path', null, 'hookPagePath');

Is it possible your browser doesn't have the necessary plugins to display videos (Flash, etc.) or has some kind of blocker installed? I know with my copy of Firefox, both are the case (no flash, and everything external blocked... but it was intentionally configured that way).

If you rename the template, then you'd also have to rename the associated language file, otherwise they'd be disconnected from each other.

It does grab the version automatically, though only once per day (and it caches it). So it may take up to a day at the most in order to display the updated version number.

I love the idea of getting TinyMCE out of the core and as a module that's installed separately. But the reality is that the marketing folks wouldn't let us do it. They love to be able to say "includes rich text editing!". Lots of people look for this in the features list when evaluating a product and don't bother proceeding if it doesn't include a rich text editor. When people are evaluating products, they don't necessarily know about the module ecosystem and how easily things can be added. Just recently I read someone slamming Drupal because it didn't come with a rich text editor. Obviously that's a silly statement, but perceptions like this matter in growing a product. The other side of it is that providing a really good rich text editing experience means integrating the editor into the system more tightly than most other modules. For instance, our rich text editors (TinyMCE and CKEditor) are integrated into the image and link selection modules. Making sure this all stays working smoothly dictates that it's best kept in the core and upgraded with the core. By this token, I'd like to have CKEditor integrated into the core too, but bundling two rich text editors is probably just too much. As for upgrading to TinyMCE 4, I'd like to do this soon. I had tried to already in the past, and ran into all sorts of issues (they have changed a lot, but it was in beta when I tried it), but this will happen sooner or later. Because of the significant differences, we may have to produce TinyMCE4 as a separate module... or rather keep TinyMCE3 active as a separate non-core module, if we replace the core with TinyMCE 4. That's because the two aren't totally compatible with each other, and anyone that's doing anything complex with their MCE installation may be dependent upon version 3 already. Because switching to TinyMCE 4 is nearly a different rich text editor, we may consider replacing it with CKEditor for our core rich text editor, given that this module is already pretty much in a stable state. Whether the core includes TinyMCE 4 or CKEditor 4, people will have to reconfigure their editors after the upgrade either way. I hate creating upgrade hassles for people, so maybe the best thing to do is just keep TinyMCE 3 where it is in the core and develop other rich text solutions separately. I don't really know, just a whole lot of factors and compromises no matter which direction we go.

As for how to make the ProcessPageEditImageSelect module accessible from the front-end, you'd need to open it in a modal window from your editor. Both our TinyMCE and CKEditor modules are already configured to do this, using jQuery UI modals. Note the properties passed to the ProcessPageEditImageSelect window (as GET variables) from TinyMCE or CKEditor in the admin. You'd need to duplicate those properties in your own usage (if not already using TinyMCE or CKE). Without looking at the code here, I believe it includes things like the page ID and image selection (if one already selected). Note that the ImageSelect module does nothing more than populate some fields in its own screen. You'll see these fields on the screen you see after selecting an image: filename, width, height, and whether it's linked to larger version. It's the TinyMCE or CKEditor plugins that do the rest of the work, pulling those values out of that modal window (with javascript) and inserting them into the editor. So those plugins are also good to look at, and I'd imagine they could be used on the front-end like they are used on the back-end. The ProcessPageEditLink module works exactly the same way.