ryan

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.

Do you have any other modules installed? PW was checking for a POST with count($_POST), then it didn't see the expected 'submit_save' POST var and threw the message you received. I think this is the way the code has worked since 2.0. So I changed it to just look for 'submit_save' instead (no reason to do both I suppose). My best guess is that $_POST was populated with something for some reason, even though there was no POST. Would be interesting to see a print_r($_POST) to see what was in it. The only thing I can guess is perhaps something from another module?

Pete is right about that approach. Another option is that you can edit /site/config.php and change $config->advanced = true; Following that, when you edit templates, you'll see a 'system' tab that provides several other more advanced options like the 'noMove' option. These are intended primarily for PW core and module development.

Glad to hear it's working after a re-upload. I think it was most likely just that htaccess file… That's the only unix-hidden file in PW.

Looking in the code, the only way you can receive that message is if something is POSTed to ProcessPageAdd that isn't from the ProcessPageAdd form. I went ahead and changed it to check a different way (just in case?), if you want to grab the latest commit, or just this file if you prefer: https://github.com/ryancramerdesign/P21/blob/960742d2c91ec66e7d593926f59a0c9d6f2125a9/wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module

Based on where the majority of our traffic comes from, I think it might be considered a European forum.

Double check that you've got the .htaccess file in your webroot. The favicon.ico messages shouldn't appear in your error log because the .htaccess file prevents them from going to PW. So if there is a favicon.ico message there, it makes me think the .htaccess might be missing or is from an older version of PW?

See the pagesAfterSave function above. If the page was moved then $page->parentPrevious is set. That var holds the old parent, while $page->parent holds the new parent.

Thanks guys, don't give me too much credit or you'll be disappointed in this thing because it was put together quickly and there really isn't much to it. But I figure it at least gives us a good starting point.

Here are examples of hooks you asked about: <?php public function init() { $this->pages->addHookBefore('save', $this, 'pagesBeforeSave'); $this->pages->addHookAfter('save', $this, 'pagesAfterSave'); $this->pages->addHookAfter('delete', $this, 'pagesAfterDelete'); $this->pages->addHookAfter('trash', $this, 'pagesAfterTrash'); $this->pages->addHookAfter('restore', $this, 'pagesAfterRestore'); } public function pagesBeforeSave(HookEvent $event) { $page = $event->arguments[0]; if(!$page->id) { // set your own var name to check after page saved $page->this_is_new = true; // do anything else you want here } else { // page is an existing page } } public function pagesAfterSave(HookEvent $event) { $page = $event->arguments[0]; if($page->this_is_new) { // check the var you set before to determine if it's new // page now has an ID, so do something with it if you want } if($page->parentPrevious) { // page was moved. $page->parent is new parent // and $page->parentPrevious is old parent } } public function pagesAfterDelete(HookEvent $event) { $page = $event->arguments[0]; if($page->is(Page::statusDeleted)) { // page was deleted } } public function pagesAfterTrash(HookEvent $event) { $page = $event->arguments[0]; // page was moved to the trash } public function pagesAfterRestore(HookEvent $event) { $page = $event->arguments[0]; // page was moved out of the trash }

Sounds like a lot to keep track of. But I think you'll be able to do most (or all) of it by hooking into: $pages->save() $pages->delete() $pages->trash() $pages->restore() If you only want to hook these things in the interactive PageEdit, as opposed to all of the API, then you'll want your hooks to check the value of wire('process') (or $this->process) and confirm that it is 'ProcessPageEdit'. Let me know if you find you need other hooks that we don't already have. In PW, making a function hookable is as easy as prepending 3 underscores to the beginning of it. So I've not attempted to add all possible hooks in the system, instead taking the approach of adding new core hooks as needs arise. Sounds great! You've really thought this through. I like all that I hear. In PW, you can make a new API var (available to all templates and modules) by calling: Wire::setFuel('api_var_name', $your_api_var); Thanks, looking forward to it!

I was originally thinking maybe you had a version prior to 5.2.4 because I had the same problem on a PHP version older than that (one of the reasons why PW doesn't support versions before 5.2.4). It doesn't sound like that's the case here... A couple more things to try: 1. Look in /site/assets/logs/errors.txt to see if there is anything in there. 2. Try installing a fresh copy of PW under some subdirectory, just to see what the installer says. The installer might find an issue that wouldn't be apparent when migrating an existing site.