Soma

For 4K you get the logo.

Knollmat.ic

Oh rly?

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.

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.

Use "shift" + greenbutton to maximize window.

Uff, a though one without having this code and exact setup for testing out the code and trace. There's a lot that can go wrong when using cookies for storing settings while using server side... I mean it can get complicated and tricky. Looking at the code I don't really see obvious flaw, but that's from looking.

How are those links created? But then the links should be /es/nosotros-concepto/ and /en/about-us-concept/ no? I have no idea what you are doing, and why the links are like this. A PW url always looks like this format /pagename/childname/ When LanguageSupportPageNames is installed you can define the /en/ /es/ names on the home page settings. After that you get correct urls when in one of the languages or you can get a specific alternative language url with $page->localUrl($language).

Great work on the narration! Just for the record: Multiplier doesn't support language text fields.

Just want to mention that the shop module isn't a very complete solution and for anything special you will need to get your hands dirty. You won't get it working the way you need without modifying every shop module and make it your own completely. You could take it as a kickstart to your own shop. Just for clarification, using the repeater support currently in the shop module is meant for variations. Means the page the repeater is on is the product. If using this the saved item will have this format. PageTitle: RepeaterTitle There's no support for other fields than the title! But one could use the title field of a repeater to save more than just a title. Maybe a "title, date, location" that constructed on page save with hooks, or on runtime modifying the $page->title of a repeater. Note that also every repeater is a page in the back and this makes it easy for the shop to take a variation as a page with it's own ID. Repeaters can have they're own price field of not it will take the page price field. So as you might found out you can loop the repeater out and create a add to cart form for each. Since it is a repeater page, shop module recognizes it as a own product/variation. Currently you seem to use this system for events that require multiple tickets, so - EventPage - repeater: EventTickets - repeater: Event2Tickets So far so good, but it seems you even need variations for the price for each "ticket", but you already have used variations for the tickets for the event. This will get tricky as there's no support for multiple prices per item. So no way to get further with this approach unless you completely adapt the shop system. What you could try also is to add each ticket as a subpage instead of in the repeater of the event page. Then you can use repeaters to on those subpage's still to create variations for one ticket, member and nonmember. Each having their price. - EventPage - EventTicket1 (childpage) - repeater: member (item to add to cart) - repeater: nonmember - EventTicket2 (childpage) - repeater: member - repeater: nonmember This could work out better and you still can construct your event page just using childpages and their repeaters to have options (maybe as a select) Then, you "only" have to adapt cart, checkout and management module to have Productitle: repeatertitle do what you need.

Using strings for translation in templates __("Some Text") I have french translation which often contains a single quote ' like in "d'or". They will get converted to htmlentities. so ' becomes ' I can convert them back with something like html_entity_decode(__("Some Text"), ENT_QUOTES, "UTF-8") But I don't think this is practicable solution to do all over the code. I don't think it's really something solvable in the translation system? It seems ' single quote is not the typographic correct ones anyway and should be written using ´ that seems to not get converted.

All methods in PW usually return a string, it doesn't print anything by itself. echo $modules->get("ShoppingCart")->renderCart() ;

Regarding languages for these modules, I don't see language alternative fields (ie: text, text_fr, text_it) being avery usable option. Consider having 5 text inputs, I have to create one field for each language and put them all one after another, that will give me 3x5 inputs scattered over the page editor. For site editors this doesn't feel quite intuitive and is mixing approaches. So creating 5 textfields is still the best way to go and those profields aren't of much usage except for multiple inputs not needing languages like phone numbers, which is very seldom. EDIT: Regardless, I also wanted to say thanks for those amazing nice new tools! (just wish that "restriction" regarding languages wasn't there).