ryan

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.

I've not tried seddass's solution, but it looks right on. I'm using some of his code in my example too. So here's another option, which is to piggyback onto the MarkupPagerNav module, even though you aren't dealing with pages. <?php // get the images you are going to display $items_per_page = 4; $start = ($input->pageNum - 1) * $items_per_page; $total = count($page->images); $images = $page->images->slice($start, $items_per_page); // make this to give MarkupPagerNav what it needs $a = new PageArray(); // add in some generic placeholder pages foreach($images as $unused) $a->add(new Page()); // tell the PageArray some details it needs for pagination // (something that PW usually does internally, for pages it loads) $a->setTotal($total); $a->setLimit($items_per_page); $a->setStart($start); // output your images foreach($images as $p) { $img = $p->img; echo "<img src='{$img->url}' alt='{$img->description}' />"; } // output the pagination navigation echo $a->renderPager(); Btw, an images field on a page isn't going to scale infinitely. At some point, you are going to find it difficult to manage, sort, etc. So I would still place some limits on yourself for the max number of images you are going to attach to a single page.

We are already prepared for field-level access control in PW (for those that want it), so that will be coming at some point. But in your case, you are wanting to do something fairly custom to the point where I'm not sure you'd want to use the existing ProcessPageEdit. If I'm understanding correctly, that is to display a field in two (or more languages), but only make one of the languages editable. Short of a capability like this coming from a module in the future, this may be a good case where you want to create your own custom template to provide exactly the editing function you need. That's what I usually do... it's a quick and easy way to get something specific. Down the road when PW has full multi-language support and field-level access control, PW will be able to do this on it's own.

Definitely green light, as you say. Any improvements in this area are certainly welcome. If it's something that is pretty universal then of course makes sense in the core. I am excited about the possibilities here.

Not sure why. Double check all filenames are where. I will try when I get back to computer

Yes the before render is I think what you need. That should work. Always hard for me to tell the right things when away from the computer (just on mobile today)

Sorry Soma, typo--my mistake, it should be $this->config->scripts not $this->scripts

Congrats on your first module and nice job! Also wanted to mention another way you can get the JS into the document without having to modify the HTML. Instead of an str_replace, you can do this in your loadJS function: $this->scripts->add($this->config->urls->ModulesTOC . "ModulesTOC.js"); The way you are doing it now is just fine too. But since PW already has a system for adding scripts in the admin theme, I figured I'd point out this option too. Thanks, Ryan

I could modify it to not require a header row. I guess I just figured every CSV file I've ever come across had one.

I think that the time it takes the browser to display those title attributes is not within our control... as far as I know, browsers implement this internally. FireFox displays the tooltip/title attribute in 1 second. Chrome waits a couple seconds to display the first one, and then displays any others in half a second. I think I prefer the timing behind the Firefox one. Though not sure I'd want it any faster than that because these tooltips can be annoying if they are showing up when you don't need them... and I'd say 95% of the time (for me at least) I'm not there to look at the tooltip. I'm not opposed to putting in the page ID in there, seems like a good idea. Though for some reason, using page IDs for anything has always made me feel a little dirty... like the CMS should really be protecting me from having to deal with IDs. But I realize there are very good reasons for using them, so it's something I need to get over.

Soma, Pete – thanks for the kind words!