-
Posts
6,808 -
Joined
-
Last visited
-
Days Won
159
Everything posted by Soma
-
Thanks for the reminder. But there was an issue report some time ago. I just commited an update for the deprecated .live
-
There is no solution. I simply don't use named dates for input.
-
adrian is right. But you'll also need jQuery Core and jQuery UI library included in your website or that pages where you have datepicker, since datepicker the one from there I thought. Small side note. Instead of writing $field->datepicker = 1; You should use the constant $field->datepicker = InputfieldDatetime::datepickerClick; More readable too. But that depends on how he's implemented the scripts in his templates. Not everybody is using $config->scripts $config->styles array?
-
Module with many include files always default language
Soma replied to Raymond Geerts's topic in Multi-Language Support
This won't work anyway. You can't set the textdomain in a include to be the one it is included from. Usually you would only do this to get a translation from the module inside the included file using its textdomain as context. So if you would have $this->_("Male") already defined in your module you could get the translation without translating the include from the module. Just use __("Male") and you're fine. -
Module with many include files always default language
Soma replied to Raymond Geerts's topic in Multi-Language Support
There's couple things to consider. Using __("Male") in the inc will work as the include itself is translated "before?" it's included, so if you translate the .inc the textdomain is the inc not the module. Second if you include the inc in the init you'll get the language the user has set in admin! On the front-end he would always have that language regardless of what language he is. SO you have to include the translation in the ready() as suggested by horst, this will make it respect the current language you are on the website. This is because the language is determined by the url requested ( /de/, /en/) and this is done via LanguageSupportPageNames. This module hooks into many things to accomplish this... and the language is determined in the ready(). So it's not possible to get a front-end language the current user is in the init() of a module. That's why you'll always get the user language (as set in admin) if you include it in the init(), no matter what front-end language he is on. -
Great first post! Just quickly looking and reading. I think instead of creating new class with extending Pagefile you could add a method via hook to Pagefile $this->addHook("Pagefile::thumbnail", $this, "thumbnail"); public function thumbnail($width, $height) {} Not sure if that's better at all. Looks all ok, and may better extend with new Class... but just wanted to mention.
-
There's a function for that in core echo wireRelativeTimeStr($page->modified); You're welcome. Just a note: Doesn't work well with when caching.
-
Just wanted to add that in a autoload module the init() method doesn't yet know the current page. But instead there's ready() where the current requested page is set. public function ready(){ $page = wire("page"); if($page->id == 1002){ .... } } This can also be handy.
-
There's no single or recommended way to what you're after. You can build anything any system with your templates and or modules. So I guess there's no general answer and one right way to do it. Modules extending Process are meant for admin pages and only work for logged in users. They have a url mapping to method. /processwire/myadminpage/ -> execute() /processwire/myadminpage/edit/ -> executeEdit() etc But as far as I understand it's not for what you're after. ProcessWire doesn't work like other frameworks. There's no routing and mapping to controllers and methods. ProcessWire's template are not "views" in the traditional MVC sense, but rather can be what you make out of it. I see them also as controllers, or can be used as such. Further ProcessWire has url segments (enabled on template setting) that can be used to extend a page's url with url segments, which then can be used to control actions. If /user/ is a real page with a template /users/edit can be catched with something like: if($input->urlSegment1 == "edit"){ .... } Modules (WireData) are usually used for hooks or similar stuff in front-end or backend. They can be autoload so they get loaded and init()'d on reach request. The init() method in such a module could be used to catch what's the current page or any request or url segment is set, you don't even need to hook into Page::render. public function init(){ if($input->post->userlogin) { $this->userLogin(); } } or also the ready() method is called when ALL the API with the current page going to render is ready. What I don't see is how you deal with the connection of your module with the template, how would the processing of a form in a template be done and return the populated form with error messages. Remember it's not like you think of other system with MVC, your module isn't a controller and your template a view. But certainly possible to make a setup that works that way. I for example simply use templates for each page of /user /user/login user/profile user/profile/edit etc containing all code to deal with them. So every url maps to a "template" or "controller". The output is done by another template that is simply included at the end. But it would still be possible to put all this code and the generation of the form via API in a module but the code stays the same and I don't see much benefit. What you could try is having a front-end-user module that has methods to do stuff, it doesn't have to be autoload. And use that in your template. So in your template you could do // just some pseudocode // load module $usersModule = $modules->get("UsersModule"); $urlSegment = $input->urlSegment1; if(!count($input->urlSegments)) { $out = $usersModule->renderLogin(): } else { if($urlSegment == "profile") { $out = $usersModule->renderProfile(); } } echo $out; Or have that logic in your module or whatever. Since you load the module on demand, there's no need for a hook or anything, and use urlsSegments to add urls // user template that is a real page $usersModule = $modules->get("UsersModule"); echo $usersModule->render(); And in the init() of you module test for url segments or requests. And the render() just outputs your result. By no means this is THE only way to go and just something to show there's nothing set in stone.
-
Knollmat.ic
-
RT @processwire: All ProFields are now available in the ProcessWire store: https://t.co/c4aV5Ru7r6 –coupon PWPFBETA gives you $20 discount …
-
Best approach forcing https for certain pages
Soma replied to Raymond Geerts's topic in General Support
Templaze setting url https only. -
I'm not very convident the other responses are really what you need. What module are you talking about, and what POST are you talking about? I'm assuming from your posts you talking about front-end forms and you ask how to handle the form processing?
-
Oh and field name would be a attr $f->attr("name", "myname"); Something like this works perfectly. $f = $modules->InputfieldDatetime; $f->label = "MyDate"; $f->attr("name+id", "mydate"); $f->dateInputFormat = "Y-m-d"; $f->timeInputFormat = "H:i:s"; $f->attr("value", time()); echo $f->render();
-
Just only need $f->dateInputFormat = "Y-m-d"; $f->timeInputFormat = "H:i:s"; the attr(key,value) is for html attributes and data-dateformat will get written by the inputfield automaticly.
-
RT @teppokoivula: Wanted to try something new. Here’s my take on latest events in and around ProcessWire community: http://t.co/qbTjFhKrWC
-
Repeaters are also pages in the back. But for such a thing like variations its perfect fit as it's a page with an actual id. That makes the system handling variations easier as its just like a product. I always handled simple variations by making a single product also be a variation. So products would always be a repeater. But you can also have both mixed with the shop module.
-
First off I don't think loaded is the right place to hook. Page::loaded is (I think) when a page is loaded but not have to be a rendered/viewed. It will in a autoload module also execute in the admin. Second is you with addHook("Page::loaded" you add a new method, but it seems it would also work but better is addHookBefore addHookAfter Next would be the exit() in such a hook is most of the time not a very good idea, it will just stop any code that may come after your hook. I tried your hook and get a similar error. Not looking further into why. To hook into after a page was viewed/rendered you should hook into ProcessPageView::execute or Page::render public function init() { $this->addHookAfter('ProcessPageView::execute', $this, 'pageViewed'); } public function pageViewed(HookEvent $event){ $page = wire("page"); if ($page->template == 'basic-page') { $page->headline = 'Something'; $page->save(); } } ProcessPageView.module handles the viewing of a page on front-end Since the ProcessPageView modifies/sets the current $page before rendering, you can get the current viewed page with wire("page"); So since you get the page this way you also don't need to set output formatting false. public function init() { $this->addHookAfter('Page::render', $this, 'pageRendered'); } public function pageRendered(HookEvent $event){ $page = $event->object; if ($page->template == 'basic-page') { $page->of(false); $page->headline = 'Something2'; $page->save(); } } This does the same just with a hook after page being rendered. The current page can also be get through the hook event object. And since it is rendered there's output formatting on. So we set it to false here $page->of(false); NOte the Page::render() isn't found in Page.php but wire/modules/PageRender.module and it's added by a method hook in that module.
-
Email is responsive by default.
-
I removed a field on template for 40k pages. It took 4 seconds. This was on new dev as willi mention. Before it took 10 + minutes.
-
In afunction you have to use wire("config")->urls ...
-
Uhm, I'm using this since years in macos to maximize the window. The only tool I have and can't live without is TotalFinder.