ryan

If you upgrade to 2.3 now, you'll just want to test everything in your site out to make sure it still works how you expect. There have been some core changes and optimizations that should not change any behaviors, but sometimes small things don't become apparent until it's in broader usage. So just test thoroughly. Also note that once you've got 2.3, you shouldn't go back to 2.2. It does make some minor DB schema changes in some cases, which 2.2 wouldn't know about. It also uses a different hashing mechanism for passwords that 2.2 doesn't support.

I'm still confused about why pages are getting deleted as part of the migration. You mentioned in your first post that you were getting the error message when adding a page (presumably on the production server?) but in your post directly above it sounds to me like you are referring to an error instead on the staging server, where you were deleting the pages? Apologies for my confusion. Can you abstract your question further, perhaps take it out of this specific context. For instance, I've wondered if your question is this: "When I delete a page with repeater items, the page gets deleted but the repeaters don't. Why?". If that's your question, can you tell me which version of ProcessWire and what other 3rd party modules are installed?

I think that you can do this all with CSS. Once you've got a crop, you can automatically CSS position it within a markup container (that has overflow hidden) to achieve variations like those you mentioned. That is, so long as the crop is something smaller than the original. You could go about it either using an <img> in a <div>, or just a <div> with a background image. If you need to just scale, or scale and crop, you'd probably want to use an actual <img> tag that specifies either the target width OR height (not both) with the other dimension overflow:hidden by the container. If you are supporting high DPI/retina displays, you are probably already doing this to some extent, in terms of the scaling aspect.

Great work! Thanks for making this. I have updated your modules.processwire.com listing to include the screenshots too.

I am confused about how your includes are being done. You mentioned you are using a File field and including them, which sounds concerning from a security standpoint. But the snippet you mentioned (/site/templates/snippets/...) is not in the path where file uploads go, so I'm confused on that point. As for why they aren't translating--have you specifically translated them? By that I mean, did you go to Setup > Languages > [some language] > Translate New File > Enter filename: /site/templates/snippets/sidebar/content/projects_page_promotion.inc ? If you have translated them, then the translation will only work so long as the file stays in the location that you translated it from. That location is called the "textdomain", and it's the primarily way that set of translations relates to a file. So if you translated the above file, and then uploaded to your site somewhere else, it would not continue to be translated.

Anything is possible. In this case, someone would create a plugin module to do it. The existing Comments module would probably be a good base to build from, for that particular need. The Discussions module may be similar. Since it is built on Pages, any other fields (like rating) can presumably be added without much trouble. The Comments module could also be extended fairly easily to support threaded comments (with some development). Though personally, I'm not a fan of threaded comments... the only one I've found tolerable is Disqus.

This doesn't not already exist. But it seems like a good idea for a module.

You could also look at it from the point of view that almost everything is (or at least can be) a category. Not a blank slate at all. In my opinion, traditional categories are very limited. And I always struggle with that when using other systems.

If you don't specify a permission, then your module is available to all admin users. If you specify an existing permission, like 'page-delete', then your module's execute() method(s) will only be available to users that have that permission. You can also have your module install a new permission, and then set it as the required permission. Example: $p = wire('permissions')->add('page-draft-control'); $p->title = 'Ability to create draft pges for edit/preview'; $p->save(); I think that the above is probably not exactly what you are looking for. In your case, you are using a Process module as an 'autoload' module, so your hooks are getting attached regardless of any specified permission (since that permission only applies to 'execute' methods). What you should do is check that the actual $page is editable() before performing runtime actions: public function hookPageListActions(HookEvent $event) { $page = $event->arguments[0]; if(!$page->editable()) return; ... } public function executeCreate() { $page = $this->pages->get((int) $this->input->get->id); if(!$page->id) throw new WireException("Page doesn't exist"); if(!$page->editable()) throw new WirePermissionException("You don't have access to edit that page"); ... }

You are right, we could probably use a section on the Page fieldtype here (among others). And a "how to create categories" guide/tutorial makes a lot of sense. I think we had one in the forums at some point, but think it's buried somewhere. Personally I learn best from examples, so that's the way I tend to communicate too. The Blog profile is a great example of the Page fieldtype in use for both categories and tags. Though it only uses them as flat (not nested) categories. The skyscraper profile also demonstrates the Page fieldtype, though not necessarily in the category context. We definitely need more written content in this area.

One other benefit is that those relation/taxonomy pages are often quite useful new pages in your site that you wouldn't have had otherwise. Take the skyscrapers site as an example. The original plan for the site was to just show skyscrapers. Architects were setup as a multi page reference field. The architect template just has nothing but a "title" field. But since all the architects are now pages, we just implement a template file for them and they now add a lot of value to the site as they are quite useful landing pages.

Good suggestions, but if you want to use the hidden inputfield here or somewhere else, you should hide it (or whatever part of it you want) with CSS. This is what ProcessWire does. The reason it has a label is just because Inputfields need a common/predictable set of things going on.

If you need one-time toggles, individual checkboxes are a fine way to go. But for multiple related items like categories, the Page reference field is the way to go. You can create a structure of pages representing any amount of flat or nested categories. If you use nested categories, choose the "Page List Select Multiple" as your input type, and set the root level of your categories structure as the "Parent".

It's possible he's talking about the comments module. All the review systems I've built on other sites are simply the comments module, except that I name my field "reviews" when I create it. When generating the output, I also override the headlines to refer to reviews rather than comments, etc.

Thanks for making this module and adding it to the directory.

While I've not tried it, I would guess that this module does not collaborate with or accommodate the LanguageLocalizedURL module in any special way. Though Pete could say for sure.

I'm not clear what you mean about "deleted all my pages". At least, this is not usually a step one would take when moving a site to a production server. So I think I may misunderstand what you mean. Can you clarify?

When you get 404s for everything but the homepage, that means the .htaccess file is not working. Edit your .htaccess file and paste in some garbage at the top, like "alkjaelfkjaef" and save. Now view your homepage. If you get a 500 error, your .htaccess is working (and you should look at the RewriteBase Nik mentioned). But if your homepage still works, then you know your .htaccess is not working. At this point, you need to tell your web host to turn it on. Or if you run the server, you need to add "AllowOveride All" to your httpd.conf for the account.

That makes sense. Perhaps what we really need are rows of two inputs each. Though that might be more trouble than it's worth in this case.

Pete this upgrade is great. I can actually enter code and have the formatting retained. I can even go back and edit it, and all is good. It looks to me like IP.Board has fixed the bugs finally!

The field 'process' is a system field, so you won't see it in the admin interface as an option to add to a template unless you have $config->advanced=true; in your /site/config.php. You can also add it from the API side.

You can hook before Fieldgroups::save or Templates::save. public function init() { $fieldgroups->addHookBefore('Fieldgroups::save', $this, 'addProcessField'); } public function addProcessField(HookEvent $event) { $fieldgroup = $event->arguments[0]; if(!$fieldgroup->hasField('process')) $fieldgroup->add('process'); }

I think this is definitely a great idea for a module. But it's also true that it kind of goes against the whole markup agnosticism, and is pretty limited when you consider the broad range of inputs possible with Inputfields. In the context of ProcessWire, it's only a partial input solution. Most importantly, front-end editing goes against content portability and is thus not a best practice. We should be abstracting content away from design, not tightly coupling content into it. I think many using a front-end solution would try to design and fit their content for the space they are typing in. Then the content is a mess when the site goes mobile, responsive or gets redesigned, etc. Promoting content portability is an important job of a CMS, and front-end editing is not good for content portability. That being said, it's great eye candy and there are plenty of cases where I think the benefits of it would outweigh the negatives too. As a core solution, I think front-end editing is a bad idea. But as a modular option for those that want it and understand the tradeoffs, I think it's a great idea. I can think of cases I would use it myself too.

Great article. Nice to see Deane Barker from Gadgetopia (one of our forum members) quoted there too.

Great module, thanks Nik!