ryan

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.

This is where it's usually set: /site/config.php - most of these options are meant for system/core development (some not that safe for everyday), so remember to turn it back off when done. For the most part I prefer to extend Page via autoload modules or delegation rather than by inheritance, but the pageClass option is there when you need to enforce a type derived from Page. Examples are User, Role, Permission types.

It should all be in /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module

Ah you beat me to it. I'm on a cell phone, about to cook dinner so have to come back a bit later. But sounds like we're thinking the same thing here

Okay, I must be confusing with a PW1 behavior, which I still do when I don't have the code in front of me. But I can say it's definitely feasible. Probably need to assign a random name on first save, before changing it to id since id wouldn't be known prior to save. Name is a unique key (when combined with parent id) so don't think it can be undefined.

I think it'd be feasible to make such an option available. I'm not at a place where I can check the code, but I think this may be how we have the API set (default to the 'id' as name when no name set). So it'll most likely be fairly simple front-end stuff to make it support that. I'll experiment on the dev branch here to see what we could implement.

ProcessWire considers the 'name' a very important component of a page (perhaps the most important). This is what people see in the URL and how the page is represented to the outside world. The reason you have to create a page before you start populating it is because we don't really know what fields we'll be dealing with in the page editor. Some fieldtypes require that a page has a dedicated place to store files, especially with ajax uploads, for instance. Some fieldtypes like repeaters need to know the page's ID. We want to keep things predictable for Fieldtype/Inputfield module developers, so want to make sure they've got a tangible page to work with. The page "name" is all that we really need to know in order to create a page. A page's name (and thereby URL) play a big role in ProcessWire. It's the primary means of a page's identification, as well as source of the path/URL. In order to ensure uniqueness in any path, the 'name' (under a given parent) is enforced as unique at the DB schema level. For all these reasons, you have to choose a name to create a page, and it's supposed to be a good thing. This is a different approach than I've seen before, but can't think of any reason why it wouldn't work. However, I do think life might be simpler just to re-purpose it since PW lets you change field context by template. If you are building a company directory, and don't want to have a "full name" field, something like "job title" might be a good one (it even has the word 'title' in it).