Soma

No there is no official topic, though there was one started long time ago but can't find. Also it's pretty much a "beta" WIP. Anyway you may consider also adding an issue on github since there's an official repository.. https://github.com/apeisa/Shop-for-ProcessWire/issues?page=1&state=open Looks like you have a problem with Payment module, have you any installed? The error does indicate there's not payment module.

Yes agree. It's a lot easier to pull off with pages. I'm not sure about best practice here. Pages of course seems like a good option.

It doesn't have to be a db table. Modules have already a config interface you could use. No problem if you don't.

Also as long as a template or field is in use you can't delete it anyway.

I know what it does. Just is it really required to to use template and fields for such a config?

@pierre-luc, there's no reason/need to make fields and template system flag. Edit: Technically you don't need to "Process implements Module", abstract Process already implements Module.

Try maybe $pages->of(false) Although I would have guessed in a module usually output formatting isn't on at all, only in templates.

Maybe some hooks could be around fields or forms, Inputfield::render() Fieldtype::wakeupValue() ProcessPageEdit::buildForm() I'm not sure.

I may responded too soon without reading carefully on mobile (not seeing screenshot). But there's a template setting only when the children template in family setting is selected. http://processwire.com/api/modules/process-template/ I'm not sure how to archive something you outlined for fields or what the exact need here for this is. But then I'm not sure there's already similar modules, though maybe not on different fields for different templates.

This is in core. You can skip add page process and have name given automatic.

I don't know how much it matter, I do a redirect 301 and it works fine.

One way is to well redirect to another page that is only a text page instead after sending email... // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Contact Form", $message, "From: $form[email]"); $session->redirect("/some/thankyoupage/"); // populate body with success message, or pull it from another PW field // $page->body = "<h2>Thank you, your message has been sent.</h2>"; // $sent = true; }

It's called PRG design pattern: http://en.wikipedia.org/wiki/Post/Redirect/Get You could for example redirect to another "Thank you" page after success.

Just found how to reproduce it. When I enter some special chars like "éààéé" as the username... I think I need some more validation/sanitizing for that.

Page: https://sev-online.ch/de/members/login/ User: guest Error: Exception: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (ascii_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' (in /xxxx/wire/core/DatabaseQuery.php line 86) The first and only time I get this error on this site. It's on the login/register. I'm not sure what exactly causing it, but I'm sure there's some special char getting submitted? It's hard to tell just from the vaque error message. Any ideas how to reproduce it?

Once again I have to ask: Why is this a Process module? There's nothing in there that makes this should be a Process module. All it will do is clutter the process select list on admin pages for no reason. The version, as Ryan mentioned, should be 10 not 010. Leading zero's will make it read as octal, and octal 010 is 8.

Maybe activate the hidden formbuilder page for all languages. Not that if you use option c you'll have to add styles and scripts manually to your site.

If you use others finds on same page with limit, you need to add start=0 to the conflicting find.

I'm not positive you can have multiple pagination on one page

In my test PW needs 0.001s to load config and 0.1s to the point right before rendering a page.

@owzim, don't want to discourage you in any way, your doing great work here. Really enjoy seeing many others finally get more serious with module development, I know Ryan is, and I'm maybe just nit picking here. Yeah some good throughout documentation is a lot of work and I don't think I could pull it off. I did my contribution with the cheatsheet and that's already some work to keep it up to date, luckly enough it's now a ProcessWire site and can be managed some. With your module here while I don't understand all fully (haven't studied all nor installed yet), for example why you have config to the process module and on the textarea field (inputfield)? As per hook https://github.com/owzim/ProcessTextareaPreview/blob/dev/ProcessTextareaPreview.module#L120 Meanwhile you seem to have another config set in your process module too: public static function getModuleConfigInputfields(array $data) { return TextareaPreviewConfigHelper::renderForm($data, self::$defaultConfig); } But anyway, I think could that you're missing that the config is stored with the Field and not Inputfield? There's no storage for Inputfields, they're only for interface input and not DB. So like this you should get the custom data. $customFieldSettings = wire("fields")->get($inputfield->name)->customCssPath;

If there is a AutoPargraph textformatter you could also remotely use its function to convert it.

You could add a hook to FieldtypeTextarea::wakepValue() that is when loaded from db before rendered. Or convert it before you save with sleepValue(). Or in when youre processing the form and store it to a page.

I agree that there could be more documentation on that subject, but I doubt there will be very soon or never at all. These are quite advanced things you're trying to do, without maybe understanding it completely. I know how you feel and I recommend starting very small and experiment step by step try to understand what you're doing or what PW or PHP does. For some of these things , there's not always a "one" correct way. But one may lead to the wrong conclusions, as I had to recognize myself quite a lot. First understand PW modules and what they're for, like a Process module, a Wire or WireData module. How configs and local properties and PW data is handled and they're scope. I only now began to understand some of them. So don't ask me, and I doubt you'll get the right answer from anyone here except Ryan. Just and example, you can check if you're on a certain admin page using if($this->page->process == "ProcessPageEdit") but $this->process will return "ProcessPageView" Also things like in your Process module in the init first line there's: public function init() { parent::init(); // required parent::init(), isn't required at all here! Do you know what it does? It loads the styles and script using the same name as the Process module. Nothing else. SInce you don't have any styles or script associated there's no need to call this. No harm here either, just an example. I just think the module system in PW can be very simple or very hard, depending on what you want to achieve. I find it kinda worrying that so many modules get released, copied and looked at and things done wrong or misleading will not help others as they study your module and learn something wrong or not really correct. I'm no exception here. I know there's no way around that but also wish there should be a quality control (Ryan does some of it as I see) or a comprehensive documentation really. Butas I said this will take a long time seeing how long it takes to get on with documentation of PW and the API.