gebeer

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.

@tpr not that I'm aware of. There is nothing special going on after login. User stays on the login page and gets presented with a logout button. In the meantime I made a fresh 2.7.2 stable install, added the custom user template/parent and role just as on the problem-site. I copied over the login logic to the new test install and can login fine. So the problem must be somewhere within other code on that site. I spent hours on debugging and can't seem to find the reason. In Xdebug panel I see that the site hangs for a while at line 61 of wire/core/Fieldgroup.php and then throws the fatal error. My Xdebug call stack is then filled with 10000 lines. Would it help if I made a pastebin with the xdebug call stack, could anyone see from that where the problem lies? EDIT: my member user template has about 20 fields. I tried removing all but the required ones. But the error still persisted. So it is not related to the user fields either. EDIT2: Into the clean install of PW 2.7.2 I imported all fields/templates from the affected site. Created a testuser with the custom member template and can login fine. Something seems screwed with the site that has the problem. Before wasting more hours on debugging the problematic install, I will rather import the content to the new blank install that now has all fields/templates that I need.

I catch the login throttle messages and pass them to a session variable which is displayed on the login page: // login user try { $u = $session->login($username, $pass); } catch(Exception $e) { $session->logout(); // without this line the user will be logged in although the exception is thrown $session->login_error = $e->getMessage(); $session->redirect($pages->get('/login/')->url); } Strange thing is that without the $session->logout(), my login page will show the error message that is thrown by the login throttle but still login the user. Is this intended behaviour?

Hello, my site has users from different timezones logging in to the backend. I have a "timezone" field for each user where I store their timezone string. Now I need to show dates in the backend in the user's timezone. I know I can set timezone for php date calculations with: date_default_timezone_set("Europe/Berlin") for example. In config.php I have $config->timezone = 'America/Phoenix'; as a general setting for that site. Now when a user logs on I want to set the timezone for his session to date_default_timezone_set($user->timezone). Where would be the best place to set this?

Yeah, I never had to raise it above 200 before. When xdebugging the login template it seems like it is going in loops. Makes my head spin. Meanwhile I found that even with the $session->redirect part commented out I get the error (see my EDIT in the OP) while reloading the login page. Then it ppoints to /wire/core/Fieldgroup.php on line 61. EDIT: Now I commented everything out in the login template. When I load the page while the user is still logged in, I get the error again.

Hello, I have a site with users that have a custom user template setup on PW 2.7.2 stable. Custom user template is "member" and role for those users also "member". The site has a frontend dashboard where users can edit their profile, events etc. I can login with this user type to the backend fine and the permission settings are all working. When I login to the frontend, I get this error: "Fatal error: Maximum function nesting level of '10000' reached, aborting! in .../wire/core/Wire.php on line 333"; I already raised the xdebug.max_nesting_level from 1000 to 10000. When I set it to 100000, the server disconnects. I can see that the user gets logged in with $session->login($uname, $pass) before the error is thrown. EDIT: When I reload the login page after the error shows with the now logged in user, I get this error: "Fatal error: Maximum function nesting level of '10000' reached, aborting! in /var/www/utgpw/wire/core/Fieldgroup.php on line 61" But a $session->redirect($dashboard->url) seems to cause the error. If I logon with a test user that has role "member" but the regular user template, I don't get the error and get redirected to the dashboard fine. All the code in my dashboard template is working. Actually, the whole login and dashboard logic for the frontend is copied from another site where it has been working fine for over a year now. So I guess the problem is related to how the custom user templates are handled in the core. My setup for the custom user template has also proven to work without issues in 2 other sites. I have spent hours on debugging already and now I'm lost. Any ideas that point to the cause of this would be much appreciated.