ryan

Good idea. What's the best way to do that? Of course, I can always change the order of them in the markup and that would probably solve it as well.

WireArray types may be associative and are designed to support direct access via indexes. So you could have a collision with a WireArray that has a index of "count" (or one of the other suggested direct access properties). While it's certainly feasible to support that for numerically indexed WireArrays, I'm reluctant to introduce conventions that can't stay consistent across WireArrays.

Thanks for posting this. I've thought a few times that we should have a five-start type voting module at some point and this looks like a good start on that. One thing I want to mention is that you might want to add validation for your $input->post->rating, because it looks like it should be limited to 1-5 and it appears that someone could manipulate the post variable to have any number in it, whether "-500" or "99999", etc. So I'd suggest adding some validation, perhaps something like this: $r = (int) $input->post->rating; if($r > 0 && $r <= 5) $new_rating = $page->vote_score + $r; else $new_rating = $page->vote_score;

Here's an example of a site with [some] subscriber-only content that's running on ProcessWire: http://www.di.net/ Example of subscriber article: http://www.di.net/ar...king_long_view/ Nice job to the guys that made it! (was not me)

Nice job yesjoar. I am always adding template/page classes to my body tag manually and think it's always helpful when it comes to targeting stuff with CSS, especially in specific cases. So this module seems like a good idea. I also like the thinking behind the browser identification, though should mention this would not be compatible with page caching. Many (most?) sites don't need page caching, so not an issue for most I'm guessing, but just something to mention.

That's correct, when you add new permissions (via Admin > Access > Permissions) you are adding it for your own use so that you could check if a user has it. You would edit any user roles that you want to have the permission and check the box so they have the permission. Then in your template code, you would check if the current user has that permission via a check like in Diogo's example. You can also just specify the permission name, which is more common to do: if($user->hasPermission('spam-nico')) { for($n=0; $n<999; $n++) mail('hi@nico.is', 'Hi Nico!', 'Would you like some spam?'); }

We should probably setup a separate Module development forum, perhaps as a subforum of the Modules/Plugins forum. I will plan to do this as soon as there's time to go through and organize all the threads into the right place.

As for JqueryWireTabs, I'm willing to, though reluctant to put CSS framework-specific classes in the code for these modules. I'm thinking what might be better here is for the theme's JS to populate those framework-specific classes, like this: $("ul.WireTabs").addClass("nav-tabs").find(".on").addClass("active"); An even better option may be to update the CSS framework class names to include alternate versions. This is the approach I've taken on some other projects. I thought this was better than modifying other kind of code because stylesheets are supposed to be kind of the last stop and we use them to style output rather than the other way around. For instance: .nav-tabs .on <!-- add this line --> .nav-tabs .active { ... }

You might be able to avoid a core modification here, because the markup already has identification for children (which is how the PageList js knows it has children). The presence of a span.PageListNumChildren as a child of any .PageListItem indicates that a page has children. Lets say you wanted to add that "hasChildren" class to all items that had children: $(".PageListNumChildren").each(function() { $(this).parent(".PageListItem").addClass("hasChildren"); }); You can also target the .PageListNumChildren span directly with CSS, as this is what contains the numbered quantity of children in its text. Let me know if this doesn't solve it, I don't mind adding another class here if it helps.

I never expected we could complete on votes with projects like Concrete5 and the others that were above us. In terms of size/age, I thought it very likely that we would come in last, despite [iMO] being the best product with the best community. So I'm very proud of how well we did, with somewhere between 110-120 "thumbs up" votes in both categories, last I checked. Despite being the smallest (in project age and user base), we were far from last in votes. I think we did great. The fact that we came in above both ModX and ExpressionEngine in "Best Budget CMS" was also great I thought. Though all it would have taken is 1 tweet from EE or ModX, and I'm sure they would have gone to 1st, based purely on size of user base... so I'm glad they never participated in that way. Thanks to everyone who voted! Also want to thank Mike for running this. I feel like we've gained a lot of new users here since these awards started, and I think that may have something to do with the exposure ProcessWire has been getting there.

I would agree that structurally every page in ProcessWire is (or can be) a directory. Something like /products/ is basically meant to be the equivalent of whatever the DirectoryIndex is (/products/index.html for example, but of course an actual DirectoryIndex file isn't necessary). If you literally wanted to have a /products.html, you certainly could do that by disabling the trailing slash for that page's template and just name the page "products.html". The only time I do that is when I need to duplicate an existing URL from an oldschool site or setup something like a /sitemap.xml that maps to a PW page.

Thanks Soma, I saw you posted a couple of GitHub issues and looks like you are on to something here. I will get into this and fix later this week.

Technically the only module groups built-in are those that start from a base class: Process, Inputfield, Fieldtype, Textformatter, ModuleJS. The headlines you see in the Modules list are runtime grouping of the first word in a modules' class name. Conveniently, this works with our our base-class module groups, but it does also extend to other modules with similar naming conventions. For the most part, I think it's better not to use one of the base class names for your module unless it extends that class. In the future, we may want to offer other types of runtime grouping options like: modules related by dependency, autoload modules, etc. Related modules in a group may have different naming conventions by need (like a related module set that has it's own Process module, Fieldtype and perhaps others) -- these aren't expected to appear together in the modules list.

It just depends how many 'ready' items you have set. If you have 3 ready items, then you hit "add item" 3 times and start populating them right there before hitting save. But once you click "add item" a 4th time (before saving) it would tell you "you need to save before this item will be editable.".

You can currently do this by modifying or extending the CommentForm class. Copy /wire/modules/Fieldtype/FieldtypeComments/CommentForm.php to your own location, like in /site/templates/includes/ or something like that. Then rename the class to be something else, like "CommentFormMichael" or whatever you'd like it to be named. Modify the class to suit your needs. Then when you output your comments, use your class rather than the one that comes with PW: echo $page->comments->render(); require("./includes/CommentFormMichael.php"); $form = new CommentFormMichael($page, $page->comments); echo $form->render(); This same approach can be taken with the comments list rendering too, except that you would copy or extend the CommentList class rather than the CommentForm class.

Good question. Here's how you can do it. Rather than doing this: $form = $page->comments->getCommentForm(); $out = $page->comments->render() . $form->render(); $comment = $form->getPostedComment(); if($comment) { $session->redirect($page->url . "#Comment" . $comment->id); // jump to the new comment when page reloads } else { echo $out; } I don't recall if this all needs to be done before any output is sent or not. But if you find that's the case, then you would just have this code before any output starts and save the "echo $out"; for the part where you are outputting comments in your site.

ProcessWire is happy to run in a subdirectory or further. But it is not designed to share databases with any other product. While you may be able to do it (assuming no table name conflicts) I don't recommend it for ProcessWire or any other software... just as a matter of good security.

Couldn't be consolidated to the second page because you can't have things like Ajax file fields or repeaters (for example) unless a page already exists. The page does not actually exist until you get to that full page editor. Also, "weirdness"? this is the first time I've heard any dislike of the way it works. It all seems pretty natural and logical to me, so I'm confused. But I'm too close to it to comment really.

I would be fine with this. But then we'd be left again with the relative URL problem where on some pages relative parent path is "../" and others it is "./", depending on whether they allow children. Same would go for relative sibling links. Even if a page doesn't allow children, we also have URL segments and page numbers to factor into the equation. I guess I think configuring the setting on the URLs tab of the template settings (where it is now) gives us the most predictable control over the slash setting. I do sometimes use this for end-point pages and omit the slash. Ultimately I totally understand the desire to get rid of the trailing slash, but kind of feel like this is something that should be done where specifically intended. I also think use of trailing slash does lead to less confusion in a tree-based system, but for advanced users it's not as much of an issue.

I think it sounds good in theory. But it also might be problematic in reality. DB schema changes are often the result of other things going on in the system that have some other representation whether by modules, template files, page files, etc. We couldn't just record DB schema changes and then play them back somewhere else because the source of those DB schema changes might not exist on the other system. I will keep thinking about this though, as it's definitely interesting.

I'm not looking to change the behavior here. I'm with you, I like the way it works. But if there are ways we can make it more hookable and customizable for specific needs like those in this thread, I think it's a good thing. If it were a one-step process, that page would need to be created behind-the-scenes as soon as you hit "new". That's certainly possible, but also doesn't seem right. I may be old school, but have always tried to follow the best practice not creating things or committing big changes to something without a proper submission… meaning an intentional and confirmed POST request in this case (not a GET request). Our screen is probably best termed the "pick a name" screen, or the "confirm you want to create a page" screen. If you are using family settings in ProcessWire, the "type" will not be applicable on this screen as it's already set and not changeable at this point. Though without family settings, then you would be selecting the type too. I'm always happy to add new hooks where needed. Just let me know where. Also wanted to mention another alternative. ProcessPageAdd is just a plugin that can be replaced. You could copy those files into /site/modules/ProcessPageAddBetter/ (or start anew if you preferred) and change /processwire/page/add/ to point to your replacement. You could do this by editing the page directly and selecting your new module, or if you could have your new module automate it from its install() method: public function ___install(); $page = $this->pages->get(6); // 6=id of /page/add/ in all PW installs $page->process = $this; $page->save(); } These we do have: Pages::saveReady is a hook called immediately before database insert. Pages::saved is called immediately after.

Take out the "Inputfield" part, and it describes what the field is. For instance "Form" is a <form> and "Text" is an <input type="text"> You want to use the InputfieldSelect included with ProcessWire: $select = $modules->get('InputfieldSelect'); $select->name = 'my-select-field'; $select->addOption('A', 'Option A'); $select->addOption('B', 'Option B'); $select->addOption('C', 'Option C'); $select->value = 'B'; // if you want to set a predefined value $form->add($select);

Not possible, at least not in a way that would be compatible with all fieldtypes. Not all fieldtypes are ajax compatible. Take TinyMCE for instance, which would need a totally different approach to being dynamically instantiated on a page like that, if it's even possible. I wouldn't want to place this burden on Inputfield module developers. It would always be a question of "is this Inputfield repeater compatible?". For instance, any Inputfield that initializes with it's own $(document).ready() wouldn't be compatible. The whole idea of "ready pages" are a compromise to provide a way around this.

Looking great! Love what you are doing with this. The dev branch (targeted as the upcoming v2.3) currently has jQuery 1.8.3 and the latest jQuery UI, so this issue will resolve itself shortly. If you'd like to switch to it on your dev server, I could definitely use help testing. If you can tell me more specifically what you need changed, I can update the core to support it, or can suggest an alternative. I'm not totally sure I understand the request. You mentioned workflow, but sounds like you are mainly interested in just changing some text? Either way, I'm sure I can make it hookable if it's not already. For really major changes, another option is you can always add another Page Add process of your own (under a different name) and update the 'process' variable of /processwire/page/add/ to point to your process rather than the default one. Several things are hookable here, and if we don't have what you need now, I'm happy to modify it to make it more hookable. Tell me more specifically what you are trying to do here and I should be able to find a way. Technically there's only 1 save button in the markup. The second one is created by the javascript in /wire/templates-admin/scripts/main.js. As a result, this is admin-theme specific, and getting rid of it would just mean deleting some JS out of your /site/templates-admin/scripts/main.js

What do you mean that it's not pretty? Is there anything wrong with this method? Looks pretty darn elegant to me (nice job!), especially after I was mucking about trying to do this same thing in Javascript.