ryan

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!

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);