ryan

Repeaters actually do have template files. In Setup > Templates > Filters, check the box to show system templates. However, this isn't going to help with sorting, as you'd need to define that on the parent. You could locate where your repeaters are stored in Admin > Repeaters and set the sort there, but you'd have to do it individually for each page. Ultimately, we need to just make this a configuration option with FieldtypeRepeater.

That's what I'm wondering too–potential JS errors. Mike, with your permission, I'll check your site to see if I can spot anything obvious. Installing CKEditor may be a good idea, but since you and your editors are already used to TinyMCE it probably makes sense for us to try and debug it first.

The above code should work. Just make sure you are outputting the truncated version ($summary) and not $child->text. echo $summary; // do this echo $child->text; // do not do this

Martijn is correct, and this profile is written for the HTML5 spec. I think there are a few more examples of the same thing in this profile as well.

I haven't taken a close look at it yet, but there is some info about localization for this timepicker on this page: http://trentrichardson.com/examples/timepicker/

Try adding this to the top of your /site/templates/admin.php, after the opening <?php tag: $pages->addHook('saveReady', null, 'makePageHidden'); function makePageHidden(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'category-site') return; // replace 'category-site' with your template name if(!$page->is(Page::statusHidden)) $page->addStatus(Page::statusHidden); }

The deleteAll() is actually a queued call that occurs when the page is saved. As a result, you might need to add $page->save() right after the deleteAll() call, just so that it doesn't end up deleting the newly added image too.

I've wondered why they do this too. There must be a good reason for it, but it escapes me. Any guesses? The guys that make Foundation aren't dumb (quite the opposite), and it's still my favorite css framework overall. But this extra <li class='divider'> seemed very unusual when I was working with it, though I just went with the flow and assumed they must know something I didn't. The only thing I can guess is that, semantically and visually, an extra <li> representing a divider might translate to any situation (even one with no CSS, though it'll look unusual). But I think of a divider as a style not a semantic element. I'd be curious on any other theories.

Soma any chance I can get a copy of the site (or maybe online/FTP/SSH access to it) so that I can try and debug it? I'm jut not sure I have a good enough of a test case here. I have a multi-language site that imports from a giant XML feed every day, including numerous repeater fields. But have not run into these issues. Though in my case, I set language values using $page->field->setLanguageValue() rather than switching the user to different languages, so that may be the difference. But it definitely sounds like there is a bug in there somewhere if you are seeing data1011 and 1011 is the ID of the default language. I think I could track that one down pretty easily once I can reproduce it. The fastest way to that may be to just get access to your site.

Another option that might work (though not yet tested to compare): $result = $pages->find("template!=admin, has_parent!=2, include=all");

I'm not sure I understand the question? The only thing I can think of you might be talking about is using comparison operators where you pass attributes to the Hanna code? The thing is, attributes are no different from HTML attributes (key=value)... they are assignments, not comparisons. So I'm confused about the question.

I think the answer lies in your FieldtypeTags module. Unless it extends FieldtypeText and inherits the capabilities of FieldtypeText (which includes support for the *= operator) then you will get the error saying that the operator is not implemented. As for why it works in one instance and not another, I have no idea without seeing the code behind the module. But just wanted to mention that operators like "*=" and "~=" and "%=" are not something that Fieldtype knows about natively – your module has to implement them instead. The good news is that it's very easy to do, and PW even provides a helper class to do it for you. See here in FieldtypeText for an example. You'll also need to make sure your Fieldtype's schema uses a fulltext index.

I'm not an expert on this, so correct me if I'm wrong, but wouldn't you be better off doing this with htaccess? This post by WillyC seems to have some good suggestions in that regard. But it seems like there would be real downsides to doing this with PHP rather than htaccess. For example, if using PW's template cache or ProCache, combined with ob_gzhandler in PHP, your cache files would end up gzipped and presumably re-gzipped when delivered. Or if PHP is smart enough not to re-gzip something then it seems likely that clients that don't support gzip could still get cached gzipped files? We could probably get around these issues by providing ob_gzhandler to ProcessWire's root ob_start() call, but I'd be curious to know the benefits of doing this with PHP rather than Apache, before suggesting that as a configuration option. I had always assumed this was something best left to Apache. Apache can do the same with your static assets too (CSS, JS, etc.)

Anyone else using the spellchecker with TinyMCE that knows how to fix this? I've not used TinyMCE's spellchecker yet, though will have to try it out. Mike, if we can't get TinyMCE's spellchecker working, we can switch you to CKEditor with Scayt (spell-checker-as-you-type) which seems to work pretty well.

Not in javascript. Taking a closer look, both FieldtypeFloat::sanitizeValue() and InputfieldFloat::sanitizeValue() get their hands on the value before sleepValue() does. They just do simple typecasting with (float) and a round() calls. The only thing I can think of is that maybe PHP's round() is not respecting the float internationalization? You might try removing the round() call from both of those functions. When it comes to float i18n it seems like PHP is trying to do too much for us in some places and not enough in others. I find it pretty confusing.

Try to assign the superuser role when logged into your 'admin' user account. Unless your 'admin' also has the 'superuser' role, they won't be able to assign it. Yes, they'll see it as an option, but once you try to save it, it will throw an error. ProcessWire doesn't know what your roles mean to you (like one user being above another), but it does know what superuser means, so it's not going to let a non-superuser assign superuser to someone else (or yourself). Beyond that, you should consider a user with administration control of users a fairly powerful permission at present. Though I do like your idea of limiting the assignment capabilities to the roles that the user administrator also shares. It would mean giving that user additional roles purely for the sake of assignment permission, which would be a different factor for roles than we usually think. But it is an interesting possibility. Though it might conflict with what page permissions you want the user to have. But if we can assume a user powerful enough to assign a role is also powerful enough to have all the permissions of that role (like with page editing and viewing, etc.–a safe assumption I think) then it could work. I'll think more on this and perhaps it would be a good feature to add.

What version of ProcessWire, and have you already tried replacing your /wire/ directory with a fresh copy?

No worries, that's pretty much what I already do. Unless a block of code is instantly understandable to me, I generally recode anything that goes into the core so that I can fully understand and comment it. That's why it sometimes takes me awhile to bring in PRs. But since I've got to support the code in the future, I figure I need to go through the process.

I think you could modify that PageList label by hooking in after ProcessPageListRenderJSON::getPageLabel. Argument 0 to the method is the $page that you want to get the label from, and the method simply returns the label that will be printed. Here it is if you'd like to take a closer look.

getQueryAllowedTemplates is basically a way to bypass inclusion of pages that use templates the user doesn't have access to. It deals with what pages will be allowed to be returned in a find/get result, and not anything to do with edit access. I tend to think you'd be better off going less low level than that. If the goal is to get things working right with count and pagination, then I think this can be bolted on to how the CustomPageRoles already works. Pretty much all page queries get routed through $pages->find() (including $pages->count()), so you can take advantage of that by hooking in before it and modifying the selector string (argument 0) to limit the found results to those within the users view access. For example, you might append "view_roles=$user->roles" to that selector string. That's a theoretical starting point at least. But if you'd prefer to do something like getQueryAllowedTemplates, let me know and I can make that method hookable (and thereby replaceable).

Thanks for this module Martijn! A couple minor things to mention: You might want to limit your hook to running only when the template is 'admin'. That way it won't be attempting to insert code in regular page renders (not that it does now, but it looks to be executing on regular page renders even if it doesn't do anything). You could do that by moving your hook-attaching code to a ready() method: public function ready() { if($this->page->template != 'admin') return; $this->addHookAfter('Page::render', $this, 'rewriteJsConfig'); $this->addHookBefore('ProcessPageList::execute', $this, 'appendStylesScripts'); } The other thing I wanted to mention is that you may not necessarily need to search/replace the rendered output. You can access the values that will be populated to the 'config' JS variable, anytime before render, with: $all = $config->js(); // returns array of everything for the JS config var $config->js('key', 'value'); // populate 'value' to variable 'key' $value = $config->js('key'); // get existing value of 'key' I'm not positive about what your search/replace was doing, so if I've misunderstood you can ignore this. But just wanted to pass this along in case it is applicable, as it might be more efficient to set/modify the values directly with $config->js before render, rather than search/replace after render.

Good links from Kongondo there. I also want to mention that if you like to learn by example, have a look at Adrian's FieldtypePhone and/or FieldtypeMapMarker modules in the modules directory (among others). These are Fieldtype and Inputfield combinations that present objects as their value, similar to what you are talking about. The big difference in your case is that your need is simpler (though not as DB friendly), because you'll be bundling it all up into a single JSON string. The place where you would convert your object into a JSON string is in your Fieldtype's sleepValue() method, and the place where you'd convert it from a JSON string to an object is in your Fieldtype's wakeupValue() method.

I had to setup a similar thing for the cmscritic.com site. Previously it had been running WordPress, which had all the articles living off the root URL. We wanted the new site to maintain all the same URLs as the WordPress site, rather than setting up 301s. So all the articles still live off the root URL, despite the fact that they are actually located within the tree. This is the case for other pages in the site as well. As an example of how to do it, see the cmscritic case study, and the /site/templates/home.php template file code in particular.

Since you are comfortable with using the MVC pattern, this may be the way you want to go in ProcessWire too. ProcessWire is very much supportive of the MVC pattern, it's just that it doesn't require it. ProcessWire is providing your models, your template files provide your controllers, and you provide the views with the TemplateFile class (or some other view loader of your own if preferred). You can also choose to target some template files/pages as views and call $page->render() on them. If you are interested, the Blog profile does use an MVC-style approach and would be worth looking at. But after you spend some time with ProcessWire, I recommend finding the approach that best suits a particular situation rather than locking yourself down to using the same one all the time. ProcessWire is giving you a lot more in some areas than a typical MVC framework does, so you may find even faster and more maintainable ways to structure your code, depending on the situation.

I'm wondering if you might have one of those buggy MySQL versions that keeps turning up at some hosts? Can you tell what MySQL and PHP versions are running there? I also find the "undefinedpage" thing very odd–it makes me wonder where that's getting injected from, because I don't think it's coming from PW. I would open up our JS console and make sure there are any JS errors occurring when you see that "undefinedpage". It sounds like you've uploaded a new copy of DB, but you might also want to upload a new copy of the site itself. Rather then replacing into, remove or rename the existing /site/ and /wire/ directories first, creating new copies of them when uploading.