ryan

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.

You can also add this line to /site/config.php if you want to permanently or temporarily disable the CSRF protection that is causing that message: $config->protectCSRF = false;

You've got me confused here. PageArrays are numerically indexed, starting from 0. Try this: foreach($pages->find("id>0, limit=20, sort=random") as $index => $item) { echo "$index: $item<br />"; }

Thanks Lance! For people that want to donate, one good way might be to maintain a PPC campaign promoting ProcessWire, or to advertise on a site like cmscritic.com or others. In the past, we've also done PW feature-sponsorships, where a company can sponsor some or all of the cost of developing a new feature or module for ProcessWire (see Avoine). Ultimately, if there are donations I think it would be great to have them go directly towards growing ProcessWire's user base or capabilities.

The profile is setup with an "author" role that you can make use of to have non-superuser authors. Those templates that have access definitions are setup to be editable by the "author" role. In this way, the system is multi-author ready. Just users. Roles and permissions can accompany a profile.

Keep in mind that ProcessWire can run in shell scripts outside of Apache/http. But so long as you aren't dealing with timeout issues, it should also be fine to trigger it the way you are asking about too (whether curl or wget or something else). However, you'll want to make sure you've got some good security through obscurity (obscure URL), and/or a GET/POST variable pass key or something to ensure nobody else can trigger your script except you. This is always a concern with anything http accessible.

Seeded is a more accurate description I agree. But for me the concern is the term... how many people know what "seeded" means? I went back and forth on it a few times, but since the default behavior is to return a random result within a timed/daily period, I figured we'd let the function describe the default behavior. The advanced people will be able to figure out how to make it do something different, whereas the non-advanced people might completely miss the big value in this function otherwise. I could be wrong, but am guessing 99% of the time, people would be using this function in a timed fashion rather than some other kind of seed? At least, I haven't been able to think of other scenarios yet.

For me the biggest problem with no trailing slash is that the relative linking strategy isn't logical in a tree structure. No trailing slash is fine for bucket-based, non-hierarchal systems, but is problematic in a tree structure. Compare these relative linking strategies. When there is no trailing slash, you are always in the context of the parent rather than the current page: No trailing slash: <a href="./">Link to parent</a> <a href="this-page-name/child-page-name">Link to child</a> With trailing slash: <a href="../">Link to parent</a> <a href="child-page-name/">Link to child</a>

Not sure that I understand where it would return to. Can you provide more detail? Textformatter modules happen behind the scenes and manipulate the text directly, rather than returning anything. That's why I'm not sure I understand the question. ---Edit: Thinking more, it does have the video ID at one point in the module, so you could modify the module to make it insert thumbnails as part of the text formatting it does. This is probably the way I would approach it at least.

Not at present, but I do plan to add a 'website' field in 2.3, which is coming very soon.