ryan

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!

Thanks for continuing to submit issue reports at GitHub, this has been really helpful. We've made tons of progress in the last week. There are still more items left in the list (all minor) so I'm going to give this a few more days, especially with some larger changes recently made to the Setup > Template > Access tab. Once I get through all the issues and we can make it through a day or two with no new bugs found, we'll consider it the first official 'full' release version of 2.1. Also wanted to mention that because we're very close on the final release version, and everything is quite stable, I've updated the Download page to steer people towards downloading version 2.1 rather than 2.0. At this point, I don't think there is any reason to start new sites in 2.0. But for people that are already using 2.0 and intend to stick with it, I will keep that version around indefinitely and fix any major bugs if they ever turn up.

Sevarf2, good points. You are right in that if maximizing the search accessibility potential of the pages is important, then a solution that ensures each language version has a unique URL is key. If not using a multi-tree approach, you could still do this with URL segments on a multi-field approach. But multi-tree is the most straightforward way to ensure search accessibility. As for subdomains, I'm not sure there is an easy answer to that question since it depends on how your web server is handling subdomains. On my server, I can configure the subdomain to run from a subdirectory off the main domain so that site.com/test/ is equivalent to test.site.com. So the first thing I would try would be to setup the subdomain in the web hosting control panel, remove any /test/ directory it creates, then create a /test/ page in ProcessWire and see if it works. If that doesn't work, you might have to symlink /test/index.php to /index.php and /test/.htaccess to /.htaccess. I haven't had the opportunity to experiment with subdomains in PW yet, so let me know if you are able to experiment with this.

Like with jQuery, the attr() method is just way way to say "I only want to deal with HTML form attributes". Anything you set with attr() is going to end up as an HTML attribute in the form field, and likewise anything you get with it is from an HTML attribute. Inputfields also have the usual set(), get() and direct reference ($a->b) means of access just like everywhere else in PW. You can also use them to get/set attributes just like with attr() and they are largely interchangeable… except for setting a new HTML attribute. If the attribute doesn't already exist, and you set it like $inputfield->something = '...', there's no way for ProcessWire to know that you want "something" that to be an HTML attribute. But if you set it with $inputfield->attr('something', '...'), then PW knows you intend that to be an HTML attribute. My recommendation is to use the attr() method when setting and getting HTML attributes on an Inputfield. While it's not always necessary to do so, it does make it clear in your code when you are dealing with HTML attributes versus other properties in an Inputfield. Btw, if you ever see reference to setAttribute() and getAttribute() with PW Inputfields, these are just verbose ways of saying: attr(key, value) and attr(key). The verbose versions are just there for internal use and hooks. So it's preferable to use attr() in most API code.

Here is a new module for ProcessWire 2.1 that imports pages from a CSV file. By default it will create new pages from data in the CSV file, but you can also configure it to modify existing pages too (existing pages that have the same title). Please give it a try and let me know how it works for you and if you run into any issues with it. This module is something I've had in the works for awhile, and regularly use on various projects, so figured I should clean it up a bit and release it. Also attached are a couple screenshots from it. How to Install: 1. Download from: https://github.com/r.../ImportPagesCSV 2. Place the file ImportPagesCSV.module in your /site/modules/ directory. 3. In ProcessWire admin, click to 'Modules' and 'Check for new modules'. 4. Click 'install' next to the 'Import Pages CSV' module (under heading 'Import'). Following that, you'll see a new menu option for this module on your Admin > Setup menu. Supported field types for importing:* PageTitle Text Textarea (including normal or TinyMCE) Integer Float Email URL Checkbox (single) *I'll be adding support for multi-value, page-reference and file-based Fieldtypes in a future version.

Martin, I think Safari may not have not loaded the new JS. You might have to clear your cache and/or hit reload on the page once or twice. Sometimes Safari can be a little tricky with cache. Also, I'm assuming we're talking about PW 2.1 (not PW 2.0), but let me know if I'm incorrect.

Thanks Pete, it seems to work great! Nice job.

Great update! Thanks for this!

Looking closer in the snippet you posted earlier, your hook needs to be Page::render, not Page::loaded.

I'm not sure that it matters, but remove 'session' from your addHook line. Just make it: $this->addHookAfter(...) Also for testing purposes, change the preg_replace to str_ireplace: $event->return = str_ireplace("<body>", "<body>" . $code, $event->return);

That's right, sorry I meant addHookAfter (trying to type too fast). If you need to show on the live end of things too, then I think you are right about the best method to use. I would probably change the regexp to this (add the "i" at the end), just in case someone is using uppercase tags for some reason: $out = preg_replace('/(<body[^>]*>)/i', '$1' . $code, $out);

Try running this script on the same server and browser and let me know what you get: <pre> <?php if(count($_POST)) print_r($_POST); else echo "POST is empty"; Just want to make sure you don't have some spyware or something behind the scenes trying to experiment with POST vars.

You could change it to an addPageAfter hook and then just prepend it to the output, i.e. <?php $out = $event->return; $code = '<p>Site in maintenance mode</p>'; $out = preg_replace('/(<body[^>]*>)/', '$1' . $code, $out); $event->return = $out; PW's <body> tag doesn't actually have any attributes, so you could also do this (below) but the above is a little safer just in case we add attributes in the future (or somebody else's theme does): $body = str_replace('<body>', '<body>' . $code, $body); Another option is to use JS in your hook. In this case, you could use the Page::render hook, or another if you preferred. $this->config->scripts->add($this->config->urls->YourModuleClassName . 'your-file.js'); Your JS file would have this: $(document).ready(function() { $("body").prepend("<p>Site in maintenance mode</p>"); }); It's perfectly fine to use a JS-only solution in PW admin because PW admin requires JS.

That's correct. While there isn't an attr() method on the Template object, you could set it from the API like this: $template->noMove = 1; or $template->set('noMove', 1); (the first example routes through the set() method behind the scenes)

That's not the intended behavior. Some of my code is still adjusting to jQuery 1.6. Thanks for finding it. Fixed in the latest commit.