ryan

The "noMove" option means that the page can't have it's parent changed. But it may still be sortable with it's siblings. The PageList uses the "move" label in a more general sense to refer to either changing the parent, sorting, or both (just depending on where you happen to drag the page to). As a result, a "move" link may still appear in the page list even if a page's template has the "noMove" option set. In this case, the "move" link is only referring to sorting within the same parent. If you drag the page to another parent, PW should tell you "no". Though, after getting the alert box, it might still look like it moved in the PageList, but that's only because I haven't figured out how to reverse it from the javascript (yet). The page didn't actually move. Hit reload or click "pages" and it'll be back where it was. Though let me know if you find it's not working this way.

Thanks I'm correcting the case issue. As for the "@" in front of the chmod, that just suppresses warning messages, so not sure it would matter here. Using it is just an old habit that pops up every once in awhile, though I generally prefer not to. Then again, I don't use Windows – does it account for something different in Windows? I'll adjust the function name case now. Not sure why I've got UCWords case on those! oops. Can you confirm that this error definitely appears to have something to do with the image size or resolution? Do you run into any issues on smaller images? If not, do you know about where the cutoff is?

It's funny you should mention that because I just added ability for InputfieldPageTitle.js to convert single to multi-char about an hour ago. So we should be able to make it convert "đ" to "dj". Do you know if this is a fairly universal conversion? I'm not sure if this character appears in any other languages where it might be converted differently?

I didn't write the module (other than adding a few edits), so can't say for certain, but I'm thinking this might work: <?php $page->setOutputFormatting(false); if($page->map) { // display the map $page->setOutputFormatting(true); echo $page->map; } else { // no map to display. $page->setOutputFormatting(true); } If that doesn't work, you may want to just modify the module itself. I would try editing the formatValue() function and adding this at the top: if(!$value) return ''; Lastly, another option is that you could edit map field's config settings and turn off the auto-generated map markup. Then generate your own (like in the earlier examples in this thread).

I'm thinking it should just go through the same exact validation as all the other uploaded files, if possible. This validation mainly consists of making sure it's the right file type (via extension) and renaming the file to be consistent with the characters PW allows for filenames. Though it also does some other stuff, like optionally unzipping zip files. The image Fieldtype also resizes the original image file if necessary (as you know). But don't worry too much about this stuff now– If you get a working example going, I'll be happy to place all the code where it needs to go. And of course, take your time… no rush. I just wanted to make sure I get you everything you need and all questions answered when you need it.

Wow, 1000 posts didn't realize that. Thanks!

Change this: foreach($rootPage->children as $child) { to this: foreach($children as $child) { The reason why that's necessary is because every time you call Page::children it's returning a new PageArray. So you need to specifically use the one that you ran the prepend($rootPage) on.

PW actually won't attempt pagination with limit=1. It needs at least limit=2 before it'll attempt to determine totals needed for pagination. This is an optimization that lets the system run more quickly, since so many parts in PW use limit=1 (and this is the first instance where a limit=1 need has turned up in pagination). The more I think about it, I have to imagine that pagination wasn't working before because page numbers must have been turned off in the template. That's the only reason I can think of why our previous examples may have not worked on his site. One option for single-page pagination is to just use next/prev buttons. $page->next() and $page->prev() return the next and previous sibling pages, making this type of pagination very easy. i.e. <?php $prev = $page->prev(); $next = $page->next(); if($prev->id) echo "<a href='{$prev->url}'>Previous Page</a> "; if($next->id) echo "<a href='{$next->url}'>Next Page</a> "; You wouldn't want to do this with something that has thousands of pages, but it would be a good solution for smaller pagination groups.

I haven't tried it, but I think it would probably work if you added this right above the foreach(): $children = $rootPage->children; if($rootPage->id == 1) $children->prepend($rootPage); Then your foreach would be changed to this: foreach($children as $child) { You'll also need to add something to prevent it from going recursive on the homepage, otherwise you'll get a double menu. So I think you could take this approach -- anywhere that says $page->numChildren or $child->numChildren, change it to $page->numChildren && $child->id > 1, like this: if($child->numChildren && $child->id > 1 && $parents->has($child)) { and if($page->numChildren && $page->id > 1) $s = str_replace(...); Let me know if this works...

Glad that you got this working. Though admittedly, I still have no idea exactly what's happening on the front end or what it looks like. All I know is that it sounds good. The ProcessPageEdit doesn't actually have any logic for saving custom fields, all that is delegated to the Inputfield modules. For instance, InputfieldFile. That module creates an instance of WireUpload (/wire/core/Upload.php) to retrieve the file and make sure all is good with the filename, file type, etc. I'm thinking that's probably where the logic should go (WireUpload class), because then it'll be available to all file upload fields. The destination path for a given page's files can be found from the field it's going to, i.e. $page->your_files_field->path; You can also get it without knowing the fieldname like this: $page->filesManager->path;

You mentioned that pagination wasn't working–can you provide more detail about what it is doing? Also, double check that page numbers are supported in your template settings, under the "URLs" tab. Without that turned on, pagination will not work.

I'm not sure what needs to be done to support the multipart/form-data on PW module side? PW's forms are multipart/form-data already, but I think you are referring to something else. I don't know how the HTML5 upload script works exactly. But if there is anything I can add, just let me know and I'll do it.

The best place to do this is in your field settings. Lets say you've got a field called 'body' that is using TinyMCE. Go to Admin > Setup > Fields and edit that 'body' field. Click on it's "Input field settings". You'll see a hidden section for TinyMCE settings. Click it to open, and from there you can configure TinyMCE's variables. Documentation for these options is at the TinyMCE web site.

Nice images. Though I couldn't reproduce any errors. They all uploaded and resized just fine for me (still using the max 800x600 setting). It is possible you are running up against a memory limit as you mentioned, though these are all pretty small images in terms of file size (300k, though jpeg compressed). I would make sure your PHP has at least 128m allocated to it. Also take a look at your phpinfo() and see what GD version it has, just in case there are any known issues there.

Cool site Soma.

I couldn't seem to duplicate here. I changed my max width to 800 and max height to 600, then uploaded a portrait orientation image of 734 pixels in height. It seemed to work as it should. Can you think of anything else I should try? I know that sometimes PHP's image functions can't handle some images I've thrown at it (high DPI images).

While I've not built a multi-language site before, I kind of think that mapping sounds very convenient for creating pages. But I wonder if you really need to do any more than that in your version 1.0? Seems like just that one feature (creating pages) would cover the biggest need that most have? Following that, people might even prefer to manage other aspects in the trees (I'm guessing). So some of the more advanced mapping stuff might be fun to save as options for a version 2.0? The way I see it, on 80% of sites, clients will just be creating and editing pages. Whereas, the big moves, deletes and other big operations are something that more often falls in the court of the developers, and usually during a site's initial development. (just speaking in very general terms). So you might be able to cover the needs of 80% of people before adding the more complex mapping features?

I think I've got this ready to go if you want to give it a try. Replace your /wire/modules/process/ProcessPageEdit.module with the attached version. Then, when you want to save a field via ajax, POST it to the ./fields/ URL, i.e. /processwire/page/edit/fields/. For example: var page_id = $("#Inputfield_id").val(); var postData = { id: page_id, title: 'This is a test of changing the page title', }; $.post('./fields/', postData, function(jsonResult) { console.log(jsonResult); }); You can specify as many fields as you want in postData, but they have to be ones that are attached to the page's template in Setup > Templates > Fields. Currently you can't change fields that are built-in to pages, like: id, name, template, parent, etc. I opted to do this with a "./fields/" URL off the page edit because I didn't want to use the same save code. Ajax stuff needs to react quickly and I thought it would just be faster if the code that saves ajax results didn't have to build and process the entire form. So instead, it just deals with the fields that are posted. Once we've got it all working, I'll commit the ProcessPageEdit updates to the 2.1 source. Edit: Somewhat unrelated, but also wanted to add: whenever you are posting files, the form that posts them needs to have an 'enctype' attribute of 'multipart/form-data'. I mention this only because I always forget it and finally realize it after pulling some hair out. Edit #2: Wanted to clarify that you don't need to add a /fields/ page in your admin. ProcessPageEdit knows to handle that URL segment, so you don't need to do anything other than replace your existing ProcessPageEdit.module file and set your JS to post to the same URL as you were before, but with "/fields/" url segment appended to it. Edit #3: found minor error in my code example above, as well as in the .module file, fixed both. ProcessPageEdit.module

That sounds like a perfect solution. I'm working with it now...

That's exactly what it was intended for. Sites where you have a lot of templates and just discovered you need the same field added to all of them. Without it, you'd have to go edit each template and add it individually. In practice, I've only used this once or twice. For some reason, I thought it would be a lot more useful at one time. But I'm going to fix it and then move it to be an advanced option, so it'll still be there for those that want it.

The core has support for it, but it's not been fully implemented in the modules. The reason is for this is that it's simple to implement with some fieldtypes, and not so simple with others. I wanted to wait until I could get to the point of providing consistent support for it in all the fieldtypes where it makes sense.

ProcessWire doesn't specifically know what "lists" are, so it's just using that term in a more generic sense as a "list of pages" returned by the API. Likewise, it assumes every API call is a form of "search". It just knows the API functions it provides to you, but doesn't know what you'll ultimately do with the results. That's by design, it doesn't want to start telling you where things should go. So when a page is "hidden" that means that PW is going to exclude it from any functions that return multiple pages. The most common examples would be $pages->find(), $page->find(), and $page->children(). When you call those functions, PW doesn't know if you are generating search results, building navigation, or what you are doing with them. Though if you want it to include those hidden pages in your results, you can add "include=hidden" to your selector. The best way to achieve what you are asking about is to add your own fields, specific to your need and context. Add two checkbox fields and name them something like "is_searchable" and "is_listable" (or if more convenient, "not_searchable" and "not_listable"). Then when you use selectors to find your pages, you can specify what you want according to the context you are in. For instance, if you are generating search results, you might do something like this: $results = $pages->find("body*=$str, is_searchable=1"); or if you are using a 'not' type of field: $results = $pages->find("body*=$str, not_searchable=0");

I think that the only thing PageEdit needs to save a page is the actual 'id' as a POST var. But it's not specifically designed for saving one field at a time, so I'm thinking that in this scenario ProcessPageEdit be inefficient at best, or unpredictable at worst. So I think we probably need something more designed for this (within ProcessPageEdit), or at least I need to update ProcessPageEdit to know to expect it. I'm going to finish replying to messages here and then going to experiment in the code to see if there is a simple solution (I think there is).

You are right it doesn't look like it's working. I haven't used this option in such a long time, I'm must have broken it recently. I'm not sure that anyone else really uses this, so wondering if maybe I should moved this to be an advanced mode option (after fixing it).

There are problems with PW adding words in this manner, like apeisa mentioned. But I can see that people will want to have different approaches for automatic page name generation. So perhaps this is a good area for us to make more easily hookable.