gebeer

You are welcome. Formbuilder is a great tool and makes the task of building frontend forms quite convenient. It covers most of the use cases for forms on websites. Building Forms is always a somewhat complex topic in every CMS/framework and I think Ryan has done a great job, both with Formbuilder and with the form API, to make this task easier for developers. If you need total control over the HTML of your form, coding it from scratch and then processing it manually seems to be the way to go.

I have to say that the form API works pretty well in the frontend. I have several sites where I use it without issues. Once you get the hang of it, it is actually quite nice to interact with. Only thing I am missing is a more easy way than the current to get more control over the rendered markup. Formbuilder comes to the rescue here. If I remember correctly, when UI framework support was introduced to formbuilder, Ryan stated that the core functionality was altered to easier support UI frameworks. But I never found any hints on how to easily alter rendering of form markup (especially field wrapper's markup and attributes) other than through hooks. Nevertheless, I agree that it would be nice to have a docs section dedicated to this topic. Or at least have a link collection to relevant forum posts that deal with frontend forms, processing and saving of input values. Links I can come up with quickly: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ and, of course, Soma's great gists (big kudos) https://gist.github.com/somatonic/5011926 (build and process generic forms from page templates) https://gist.github.com/somatonic/4027908 (build and process forms manually with API) https://gist.github.com/somatonic/4150974 (upload images) https://gist.github.com/somatonic/5415646 (form with fields in table) https://gist.github.com/somatonic/5233338 (manual form markup with file upload handling)

If you take a look at the html that is rendered for every form, you will see, that the fields are wrapped in li elements which are inside an ul container with class Inputfields. <ul class="Inputfields"> <li id="some_id" class="Inputfield ...">The form inputfield html</li> </ul> 'list' => "<div {attrs}>{out}</div>" refers to the ul container. So in this example ul would become div 'item' => "<div {attrs}>{out}</div>" refers to the li elements inside the ul. So in this example the li elements would become div elements. {attr} refers to the ids and classes and {out} to the inputfield markup. You can change id, name and class of an inputfield with $field->attr("class" , "myclass"); $field->attr(id+name , "myname"); But you cannot change the ids and classes of the inputfield wrappers in this way. You'd need custom hooks for that. EDIT: yes you can, see Pete's post below Or you get formbuilder which makes it really easy to generate forms for uikit and other frameworks.

@Gurumeditation regarding UI frameworks, you can set your desired classes to the inputfield wrapper with $form->setMarkup(array( 'list' => "<div {attrs}>{out}</div>", 'item' => "<div {attrs}>{out}</div>" )); and set classes to fields with $field->attr("class" , "myclass"); That is the only way that I know of how you can get to use your framework's classes in the form. Sanitizing: you just need to run the $input->post values through PW's $sanitizer methods before they actually get saved. It depends very much on the data your handling with your form, which methods to use. This legendary thread about building forms with the PW API is worth reading and should answer most of the questions.

You should take a look at Soma's great gist about building frontend forms from fields of a template (or page). This code also pulls in all the dependencies you need for asm page fields, image fields etc. It also takes care of server side form validation. Only thing you need to add is sanitation of the form values. I have used this code as a base for several frontend forms (even complex ones) and it is working great.

You should set dutch as the default language in the backend to avoid those kind of problems. Or you can use a hook before page save to automatically populate the default language (english) fields with the value from the dutch fields.

You have a $searchdate of format January-2016 and the date that is saved in your page in field date is 12-January-2016? PHP doesn't know by default that 12-January-2016 is a day within the month January of year 2016. So you need to do some date calculations with PHP. Try this to find out if "12-January-2016" lies within January 2016 // example code // convert the saved date of the page to a timestamp // $date = strtotime($page->date); // I assume the date is saved on the page in field date $date = strtotime("12-January-2016"); // convert the $searchdate to a timestamp $searchdate = strtotime("January-2016") + 1000; // get first and last timestamp of the given month and year $getdate = getdate($searchdate); // get the month number (e.g. 1 for January) $month = $getdate["mon"]; // get the year (e.g. 2016 $year = $getdate["year"]; // get first timestamp of that month in that year $first = mktime(0,0,0,$month,1,$year); // echo date('r', $first); // get last timestamp of that month in that year $last = mktime(23,59,00,$month+1,0,$year); // echo date('r', $last); // now check if $date is in the range between $first and $last function check_in_range($first, $last, $date) { // returns true if $date is in month January of year 2016 - else returns false return (($date >= $first) && ($date <= $last)); } var_dump(check_in_range($first, $last, $date)); // either true or false Now you can use check_in_range($first, $last, $date) in your if - elaseif statements. Try the code live here. PS: I don't know what it is, I just like to fiddle around with date calculations...

Thank you for taking the time to look into this. Unfortunatley this doesn't apply to my situation because I already switch off output formatting right before the foreach loop $editpage->setOutputFormatting(false); foreach($form as $field) { // here is where I need to get the multi language values $editpage->set($field->name, $field->value); }

I think the problem is with $form->processInput($this->input->post) not taking into account multilanguage values. get_class($editpage->title) returns: LanguagesPageFieldValue But inside the foreach($form as $field) {...} a var_dump(get_class($field)) for the title field returns: InputfieldPageTitle These are 2 different types of objects. I would expect to get a LanguagesPageFieldValue object where I can access multi language values. But sadly this is not the case. Would be nice to have a method like processInputLanguage(). I have searched the code and the forum but cannot find a clue how to deal with multiliangugae fields in form processing. Any help would be much appreciated.

Hello, I am building a dynamic frontend form from fields of a page, following Soma's great gist example. The form is working fine, except for multi language values. After this part of the code $form->processInput($this->input->post) when I loop over the form fields, I don't know how to access the multi language values of a field foreach($form as $field) { // how to get multi lang values here } What I tried is not working foreach($form as $field) { if($field->type instanceof FieldtypeLanguageInterface) { foreach ($languages as $lang) { $langval = $editpage->$field->getLanguageValue($lang); $editpage->$field->setLanguageValue($lang, $langval); } } else { $editpage->set($field->name, $field->value); } } Actually the $field->type returns just "text" for a PageTitleLanguage field. var_dumping the $field reveals that the language values are stored deep inside the object like 'value1023' => string 'Testworkshop2' (length=13) 'value1032' => string 'Testworkshop2 Englisch' (length=22) So how would I access those other than pulling them directly from $this->input->post?

@Mats thank you, but that does not quite apply to my situation. But I just found the solution: In the single image field settings in Details tab, I needed to switch from "Single item (null if empty)" to "Array of items" Now I can use the single image min my frontend form Somehow the processInput method can only handle arrays for file fields

Hello, I am building a frontend form following Soma's great example on a PW 2.7.2 stable install. The pages that I edit with the form already exist. My form includes a single image field, CKEditor fields and some normal text fields. The form renders fine, all CSS and JS is in place. I can even use the pwImage plugin on the CKEditor field and it loads the image from that page. When there already is an image present in the image field and I submit the form, I get this error: Fatal error: Exception: Method Pageimage::path does not exist or is not callable in this context (in /var/www/utgpwnew/wire/core/Wire.php line 358) #0 [internal function]: Wire->___callUnknown('path', Array) #1 /var/www/utgpwnew/wire/core/Wire.php(398): call_user_func_array(Array, Array) #2 /var/www/utgpwnew/wire/core/Wire.php(333): Wire->runHooks('callUnknown', Array) #3 /var/www/utgpwnew/wire/core/Wire.php(337): Wire->__call('callUnknown', Array) #4 /var/www/utgpwnew/wire/core/Wire.php(337): Pageimage->callUnknown('path', Array) #5 /var/www/utgpwnew/wire/modules/Fieldtype/FieldtypeFile.module(119): Wire->__call('path', Array) #6 /var/www/utgpwnew/wire/modules/Fieldtype/FieldtypeFile.module(119): Pageimage->path() #7 /var/www/utgpwnew/wire/core/Wire.php(459): FieldtypeFile->hookProcessInput(Object(HookEvent)) #8 /var/www/utgpwnew/wire/core/Wire.php(333): Wire->runHooks('processInput', Array) #9 /var/www/utgpwnew/wire/core/InputfieldWrapper.php(636): Wire->__call('processInput', Array) #10 /var/www/utgpwnew/wire/core/Inp in /var/www/utgpwnew/index.php on line 248 If the image field is empty, I get this error on submit Fatal error: Call to a member function path() on a non-object in /var/www/utgpwnew/wire/modules/Fieldtype/FieldtypeFile.module on line 119 If I change the image field to hold more than one image, I don't get the error and the form submits fine with and without one or more images in the field From debugging I see that the error is triggered from $form->processInput($this->input->post); So the code does not work on single image fields. Is there a way to fix this? Any help would be much appreciated.

If you really want to compile the sass files on the server via PHP, there is http://leafo.net/scssphp/. Only works for scss syntax, though. When you start working with sass/scss, I'd encourage you to follow the already proposed workflow: compile locally -> upload compiled css to server.

@dragan, I tested it with the multilang profile that ships with PW and it worked. Would be happy to hear how it goes for you.

How would you do that? I'd be curious to know I don't mean to offend you here. Its just that my OP and the whole thread is about finding a way how to easily - or like you put it - "just" change the default language. This can get quite complex when you already have contents for your different languages. I really tried to find everything in the forum related to this task. And the solution I came up with is the script I posted above. I'd be happy to find an easier way. Your suggestion with one site profile per language can work. But then initially setting up 1 profile per language is quite a time consuming task. I used my script to switch the default language like described in #14. And it works. But still, and I second ivanr here, it would be fabulous to have a switch in the backend that "just" changes the default language in an easy manner

Truncate text and preserve html tags: http://www.the-art-of-web.com/php/truncate/ see number 6. In Joomla they have a class to deal with this: http://www.phoca.cz/joomla/api/class-JHtmlString.html

As LostKobrakei mentioned, you should remove the second include call for jquery and see if it is working then. So remove this line from your code: <script src="<?php echo $config->urls->templates?>bower_components/jquery/dist/jquery.js"></script> which is down towards the bottom. Try this first and see if the fancybox is working. Then I also see this error in the console: "NetworkError: 404 Page Not Found - http://olikehrli.ch/galerie/lib/jquery.mousewheel-3.0.6.pack.js" There seems to be a wrong path in your code where you include the jquery.mousewheel-3.0.6.pack.js script: <!-- Add mousewheel plugin (this is optional) --> <script type="text/javascript" src="lib/jquery.mousewheel-3.0.6.pack.js"></script> //the path lib/jquery... is wrong Try to find the file "jquery.mousewheel-3.0.6.pack.js" in your templates folder. Maybe it is in folder bower_components. Then type in the correct path, for example: <script type="text/javascript" src="<?php echo $config->urls->templates?>bower_components/jquery_mousewheel/lib/jquery.mousewheel-3.0.6.pack.js"></script> This is just an example and assumes that your file is in folder site/templates/bower_components/jquery_mousewheel/lib/jquery.mousewheel-3.0.6.pack.js.

@ryan Thank you for taking the time to comment on this. There are no custom hooks running on that site. Installed modules: -ProFields: Table -ListerPro -Database Backups -Upgrades As performance is fine on my vagrant dev box, I think the problem is related to the godaddy VPS. It was very slow 2 days ago. Now it is much better again. I saw that more than 1.5 of the 2 GB RAM of the VPS are in use and have to investigate where this originates from. The second PW install that is running on the same VPS has some quite complex code running and I am about to profile that site and then go on from there. For the long run my client will eventually move away from godaddy as we are expecting quite some traffic on the project.

Update on performance: I copied the install to my local vagrant development box where it is working smoothly. No long page loads and Lister Pro is fast even with 5000 logs. So the performance issues are related to the godaddy server - who would have thought that

Helo, I have a site running on PW 2.7.2 stable that is solely used for data logging. No frontend code at all. Every log entry is saved as a page. The template for the log pages has 5 fields: The channels field is a Pro Tables field with 4 columns: The data stored for the logs looks like this: Apart from that there are only about 10 more pages and about 12 templates sharing 12 fields amongst them. The logs are coming in from another PW site via REST API and are stored every minute. So no big overhead there. ATM there is only one log coming in every minute. But for the future there will be 100 or even 1000 logs per minute. The logs will be stored in the DB for 1 month, then stored away to csv and deleted from the DB. I am experiencing quite slow page loading already for the login screen and in the backend once there are more than 1500 log pages. Also loading the listing for the logs with Lister Pro takes quite some time (about 15 seconds for loading of approx 2000 logs and paginating them). The site is hosted on a godaddy 2GB VPS at the moment which hosts only one more site with no heavy traffic. What I can see from the server side there is not much average CPU load but quite some memory usage. I wonder how performance will be once there are 10000s of log pages in the DB (will know in about 2 weeks). Only 1 log per minute already amounts to over 40.000 log pages a month. Do you think PW can scale well with about 400.000 - 1 million pages (then on a better server, of course) ?

Thank you all for your input. @LostKobrakai Would be great if this could be implemented into 3.0

Just wanted to report my findings. session_name($config->sessionName); session_write_close(); does not have the desired effect. Sessions remain open. session_name($config->sessionName); session_write_close(); session_destroy(); throws a Warning: "Warning: session_destroy(): Trying to destroy uninitialized session" What I think happens, is that "session_name($config->sessionName);" does not capture the original PW session. If I do $_SESSION = array(); session_destroy(); the Sessions get destroyed and are not recorded in the DB anymore. I s there a way how I can get the PW session other than with $_SESSION? EDIT: looking at var_dump($session), it is all protected properties.

Thank you Horst, I will try those hooks. Do I then have to set the timezone with $config->timezone = $user->timezone or with date_default_timezone_set($user->timezone) Just asking because I'm not sure whether PW will override the date_default_timezone_set($user->timezone) with $config->timezone value from config.php.

Thanks for making the video but I'm sorry, from what I see, I cannot explain the behaviour.

Have you tried doing a var_dump("hello"); instead of the echo? Depending on your template setup sometimes things that you echo are hidden under some elements and do not show.