bernhard

https://gitlab.com/baumrock/RockSqlFinder is already online. The datatables module is in the works but will need quite some time...

just added the renderTable() method: $form->onSuccess = function($form) { $form->linkedFields = [ 'pdf' => 'files' ]; $log = $form->createPage(123, 'rockforms_anfrage', date('d.m.Y H:i:s') . ', {forename} {surname} {email}'); $m = new WireMail(); $m->to('your@email.com') ->from('your@email.com') ->subject('Your great subject') ->bodyHTML($form->renderTable()); foreach($log->files as $file) $m->attachment($file->filename); $m->send(); // return success message return '<div class="uk-text-center uk-padding-large">'. '<h3>ENERGIEGURU bedankt sich für ihre Anfrage.</h3>'. '<div>Wir melden uns in Kürze bei Ihnen. Wenn Sie Ihre letzte Jahresrechnung hochgeladen '. 'haben erhalten Sie in den nächsten 24 Stunden Ihr individuelles Angebot!</div>'. $form->renderTable([ 'wrapper' => '<div class="uk-card uk-card-secondary uk-card-body uk-margin">{table}</div>', ]). '</div>'; }; I agree this could be automated, but at least until that is finished it is already REALLY simple to accomplish.

Sure, but that's the same for outputting fields in regular processwire templates... echo $page->myfield... You also need to remember the field's name here. I almost wanted to implement the feature right away but I started with the renderTable() method, because it is more important. Also I'm not sure how my idea will work with groups and containers... I have to think about that.

$form = $modules->get('RockForms')->form; //$form->addFromTemplate('mypwformtemplate'); // this would result in this initial form setup: $form->addText('forename', 'Vorname'); $form->addEmail('myemail', 'E-Mail-Adresse'); // either by using an email field in pw or by setting the title to email_myemail $form->addUpload('attachment', 'Anhang hochladen'); // using a pw file field with title upload_attachment --> upload_ will set the nette type and the rest will be used as the field's name // then you can adjust your form via nette and do whatever you need: $form->getComponent('myemail')->setRequired(); ... $form->addSubmit('submit', 'Subscribe'); $form->render(); Ok, I can imagine that this can make sense. I'll stick to my 1-file-setup since everybody can use include() whenever the need comes up

I don't think so. It would be easy to loop the fields defined in a processwire template and add the corresponding fields to the nette form (of course not with all settings like width, required etc. but that should be done 100% by nette imho). My idea was just to setup a pw template with the fields and then render the form in the template file like this: <?php $form = $modules->get('RockForms')->form; $form->addFromTemplate('mypwformtemplate'); $form->getComponent('email')->setRequired(); ... $form->addSubmit('submit', 'Subscribe'); $form->render(); The type of the nette field could be defined via the PW field's title: text_forename (regular textfield), password_mypassword (password field), mycustomnettefieldtype_demo (custom nette field). For more complex forms there would still be the option to define the form manually (no drawback). My setup needs only one php file to define the form and to process the input, not sure why you split that into two files?

As the topic title says I want to share an idea I came up today: Why not track my module installations via Google Analytics? Very simple one, but huge potential and maybe somebody else has not thought of this possibility yet. It can also be used to track sent emails, submitted forms, log errors, whatsoever... $http = new WireHttp(); $http->post('http://www.google-analytics.com/collect', [ // Make sure to use HTTP, not HTTPS! 'v' => 1, // Version 'tid' => 'your-tracking-id', // Tracking ID / Property ID. 'cid' => 555, // Anonymous Client ID. 't' => 'event', // hit type 'ec' => 'myEventCategory', // category 'ea' => 'myEventAction', // action 'el' => 'myEventLabel', // label ]); You can test your setup here: https://ga-dev-tools.appspot.com/hit-builder/ Happy tracking

As I said, I used the PW internal one https://gitlab.com/baumrock/RockForms/blob/master/RockForms.module.php#L68-75 Sorry, I don't understand your first post. Do you mean you setup an admin page and then you can render this page directly as form on the frontend? Interesting idea. This way one could use the processwire admin to build forms. Then on the frontend we could to $form->loadFromPwTemplate('myrequestform'); I think that would make a lot of sense since the page is needed for logging anyhow. Ajax: I guess you implemented a vanilla js solution? datepicker, autocomplete, autogrow, character counter Pff, no need for this at the moment. where/how do you define those settings? Add css classes Good point. I'm sure this will be useful. date/ip/lang Mhm, might make sense as well. Ok, so as soon as we start adding all those things it might also make sense to have a custom process module to handle the forms. And also install the necessary fields on installation. Should not be a big deal. The problem is, that I need to work on my Datatables module now (will be a perfect companion for this module for listing all form submissions). Then finish some client work and then I might find time for such additions. If anybody else thinks he can find time earlier feel free to take over. I think the module is already usable as is, I just wanted to share it early to start a discussion (which appearently worked out).

I think I don't get your point - it is already exactly what you are suggesting. And yes I plan to maintain it, since I need forms often and it was always a pain to get them running properly. Though I will 100% stick to uikit, so if anybody needs support for any other frameworks just open a PR and add code here: https://gitlab.com/baumrock/RockForms/blob/master/RockForms.module.php#L144 Not really, but forms always bothered me for a long time (you know it), I was not really happy with my nette implementations, I knew you had one implementation lying around somewhere but then I decided to implement it on my own It was fun Your screencast looks nice, but I'm not sure if we should go this direction... I don't want to build a replacement for FormBuilder. The intention is to make it really really easy and fast (and secure) to get up and running with simple forms (like contact forms and newsletter subscriptions). This always seems to be a little request for my clients but it actually meant a lot of work for me. I've purchased and tried FormBuilder but somehow didn't like it. Maybe because I find it easier and more fun to program my own version than learning to use otherone's software What you are doing in your screenshot can already be done easily with my module: Just setup the template and fields you need and then put the code in the onSuccess() callback, for example: $form->onSuccess = function($form) { // send mail ... $mail->body = $pages->get(123)->mailBody; // multilanguage email response text field ... // redirect to any page $this->wire->session->redirect('yourpageurl'); } I don't want to define a GUI for this module since I don't think it is necessary. It would mean a lot of work and not a lot of benefits. Or even worse, it would cost flexibility. If you need a GUI for your clients it's easy to build one on your own. And it would be totally customised and not packed with features nobody needs (thats the beauty of PW imho). Having said all that, I'm happy to hear feature suggestions that you think would make sense for such a module. For example a method to render the form into a HTML table to send via mail is on my mind but not implemented yet.

Finally I built a module for creating FrontendForms easily:

Deprecation note (06/2022): This module has been deprecated in favour of a new RockForms module that does not only use NetteForms but also comes with a GUI. You can still use this module if you want, but I will not provide any fixes or updates or support! https://gitlab.com/baumrock/RockForms It uses the great NetteForms from Nette Framework (docs: https://doc.nette.org/en/2.4/forms ) Features: Client AND Server-side validation in one go (you only need to code your rules ONCE) CSRF protection (by processwire) Honepot spam protection (custom) Helper to create PW pages from submitted forms ($form->createPage($parent, $template, $title)) Add ?success=yourform tag to url ONLY after successful submission (for analytics) Recover fields after unsuccessful submission (server side validation error) Define custom actions + message on successful submission UiKit form renderer (more can be accepted by pull requests) Sample Form Setup: <?php namespace ProcessWire; $form = $modules->get('RockForms')->form; $form->addRadioList('salut', 'Anrede', ['m' => ' Herr', 'w' => ' Frau']); $form->addText('forename', 'Vorname'); $form->addText('surname', 'Nachname'); $form->addText('email', 'E-Mail-Adresse') ->setRequired('Bitte geben Sie Ihre Mailadresse an') ->addRule(Form::EMAIL) ; $form->addSubmit('submit', 'Anfrage senden'); $form->onSuccess = function($form) { $form->createPage(1017, 'mailitem', date('d.m.Y H:i:s') . ', {forename} {surname} {email}'); // send email // do whatever you want // return success message return 'thank you for your subscription'; }; echo $form->render(); For all available fields you can look here: https://doc.nette.org/en/2.4/form-fields Validation: https://doc.nette.org/en/2.4/form-validation Rendering: https://doc.nette.org/en/2.4/form-rendering More complex form example of the screencast: Module is alpha and not well tested yet. It should be save to use, but there might be breaking changes in the future. Also I'm quite sure that not all possible situations are covered. There are some switch() statements that check for the fieldtype and I only implemented the ones I needed so far. All others are easy to add - please make pull requests if you find any unsupported fields. Thank you. LIMITATIONS: Multiform support limited Changelog: 6.8.18 add multiform support 8.4.18 v2 little bugfix + load assets automatically 19.3.18 alpha release

thank you. Totally makes sense, I'll install the plugins manually

Hey @tpr would it be possible to apply the AOS tweaks for ckeditor also to the frontend editor? Here for example I have the lightwire skin + justify plugin and that does not show up on frontend:

A friend of mine is very happy with this one: http://amzn.to/2Dz2zRB I think it's an interesting concept and I'll give it a try

Sure it's nice I think this was lost in translation I meant if you are using the IDE you don't need ACE, but of course it's nice to have it in the backend. The Tracy Console is a perfect example. I'm using ACE myself in several projects

But still I think using your IDE is the best option for larger code snippets... No need for ACE then. I'm still unsing my render replacement hook

Really, really nice! What do you think of packing this into a fieldtype? Would be nice to have all the logic, files and fields packed into a module and to only have to add your field in the template editor I'm also working on a site with matrix content builder and using field rendering makes the code very clean: My matrix field is called "content" and all my items are included via WireRenderfile(). Then it's as easy as placing a file with the markup in /templates/matrix (here 2columnlayout.php).

Not to forget the memory drop from 20.63MB to 0.15MB

hi federico, sorry for you that you didn't get any answers so far. the community is usually really fast and helpful Unfortunately I cannot help you with your question, but maybe it's worth looking at the AdminOnSteroids module. tpr does a lot of adjustments there - so it should be definitely possible to adopt the themes to your needs. Maybe you can elaborate your case more in detail and get better answers

UPDATE 2022 Simple and powerful - put this at the end of your config.php file: $localConfig = __DIR__ . "/config-local.php"; if (is_file($localConfig)) include $localConfig; Then put all local settings into config-local.php (same concept for DEV/STAGING/PRODUCTION): <?php namespace ProcessWire; /** @var Config $config */ $config->debug = true; $config->advanced = true; $config->dbName = 'db'; $config->dbUser = 'db'; $config->dbPass = 'db'; $config->dbHost = 'db'; $config->userAuthSalt = '1234'; $config->tableSalt = '1234'; $config->httpHosts = ['xyz.ddev.site']; // this prevents logout when switching between // desktop and mobile in chrome devtools $config->sessionFingerprint = false; // RockFrontend $config->livereload = 1; // RockMigrations // $config->filesOnDemand = 'https://your-live.site/'; $config->rockmigrations = [ 'syncSnippets' => true, ]; // tracy config for ddev development $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => '/Users/xyz/code/yourproject/', 'numLogEntries' => 100, // for RockMigrations ]; $config->rockpagebuilder = [ "createView" => "latte", ]; -------------------- OLD POST from 2018: Have you ever come across the situation where you needed to change your config.php file for local development? Have you ever come across this warning? Say goodbye to this little annoying tasks Some of you might know that you can have a separate config-dev.php file for local development. This is nice, but also needs some setup (for example excluding this file for git upload) and there is still some danger of uploading this file to a place where it should not be... The other option was to keep the database settings for your live and dev server in sync - also not easy and maybe not the best... My solution is as simple, fast and I think it should be even safer than the other options. Just put these lines at the end of your config.php file: if(strpos($config->paths->root, 'C:/www/') === 0) { $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER[HTTP_HOST]]; $config->debug = true; } elseif(strpos($config->paths->root, '/var/www/vhosts/') === 0) { $config->httpHosts = []; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->debug = false; /** * Redirect to HTTPS * ATTENTION: This will NOT work with ProCache enabled! Use .htaccess instead */ if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "off"){ $redirect = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']; header('HTTP/1.1 301 Moved Permanently'); header('Location: ' . $redirect); exit(); } } else die('wrong config.php'); Having a separate config-dev.php file also makes it necessary to keep both files in sync. That was my first idea: To include the original config and then overwrite settings. But it's just simpler the other way round: Using the default config.php file and overwriting settings there.

I'm wondering what you guys think of caching? I can think of two situations: A query without closures and without custom SQL Here we could do caching based on the selector via adding a $pages->findOne(... sort=-modified) and check if that date has changed. If the date is greater than from the cached one we create a new result, otherwise we can return the cached one. I think it should even be safe to do this by default?! A query with closures or custom SQL In this situation the data could also change in a referenced field or in a cell queried by sql. Here we would need to specify our own logic for caching. Maybe we could provide an option to specify a page selector to query for the last changed timestamp? For example when listing all clients and the related invoices, the data would need to change whenever an invoice or a client changed: 'cache' => "template=client|invoice" (adding sort=-modified automatically) Alltogether it would be something like this: $pages->findObjects([ 'selector' => 'template=client', 'columns' => [ 'title', 'invoice_sums' => function($page) { return implode(',', $page->invoices->each('gross')); }, ], 'cache' => 'template=client|invoice', ]); And the output would be something like: And it would reset whenever a client or an invoice is changed.

Thanks adrian, I also noticed that but it seems it was too late yesterday... forgot to check if there are any closures to execute so it loaded all the page objects even if there were no closures please check the update: https://gitlab.com/baumrock/RockSqlFinder/blob/master/RockSqlFinder.module.php#L59 Very interesting (and great imho) is also this test using closures: So, of course with closures it is a LOT slower (because we load the page objects in memory), but the additional costs for each closure are less than for the first one. Thats because the page is already available in memory after the first closure: https://gitlab.com/baumrock/RockSqlFinder/blob/master/RockSqlFinder.module.php#L62-63 And finally one with "images:description" syntax: And insanely fast without the closure @all Any ideas wich character to use for image field descriptions (and maybe other fields)? At the moment I'm using the pipe, but that would lead to problems when a user uses the pipe for descriptions (see the above screenshot) For file- and page fields the pipe should be fine because we could use it directly for further selectors and files should not contain any pipes.

made huge progress on this Example query with all the features: $pages->findObjects('template=item, limit=100', [ 'title', // page title field 'field1', // regular textfield '(SELECT #data# FROM field_field1 WHERE pages_id = pages.id) AS `sql`', // custom sql query (multilanguage) 'images:description', // imagefield + description 'pagetest:status:created:templates_id', // pagefield + page status + created time + template id 'pagetitle' => function($page) { return $page->title; // example of a closure }, ]); Explanation: regular textfields can easily be queried just by defining their name as string any custom sql query is possible, even multilanguage when using #data# keyword images:description syntax works for all file fields page:status:created works for all pagefields and last but not least a very nice helper for fast and easy queries and small amounts of data: closures Output (default language): And the same query as datasource for a datatables field: This will be really, really awesome @theo I plan to add a lot of other stuff to my datatables module and that will take some time. I put the new pageFinder in a separate module. You can have a look here: https://gitlab.com/baumrock/RockSqlFinder Maybe you want to test it? Also @adrian might be interested? Currently it supports FieldtypeText, FieldtypePage and FieldtypeFile - but it should be easy to add others... Like Repeaters for example. Any other fields could be queried via custom SQL queries... And for really complex joins there will be another module

thanks for pointing me to the github issue. how do you guys keep track of those issues on github? I subscribed once but it was just too much to follow. Is there a way to search pw issues on github properly? or do you use google to search? btw: it is not fixed for me with ajax loaded fields. I added a comment on github.

Very strange one... I have 2 Fields set to 50% in template context (here a screenshot of the default profile). In the default admin it works as expected (headline + summary side by side), but in the uikit theme they are not the width that they should be Any ideas? I thought this might be AOS but I tried it on a fresh DEV installation and same result.

almost missed that post. thanks, adrian, #360