LostKobrakai

@Mustafa Online There are modules, which add twig into processwire and you could also just install it yourself e.g. via composer. For the future please open your own forum thread instead of seemingly highjacking other peoples'. Also simply searching for twig in the forums/google would probably have brought up the information you're seeking.

As it does will all other services of that type and I've yet so see a website, which does create such chats on their own.

If only the homepage does work and no other ones look at this: https://processwire.com/docs/tutorials/troubleshooting-guide/page3

Yeah sure, you're right. I usually do not call class methods from within the hooks executed function, which made me miss that.

I think Ryan is the only one to answer this without pure guesswork. But he probably did implement what padlooper does on his own. I mean nobody says you need padlooper to build a shopping cart. It just might be faster not to implement and test everything on your own by using it.

https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire/modules/LanguageSupport/LanguageSupportPageNames.module#L395-L406 Here it's defined

https://github.com/ryancramerdesign/BlogProfile/issues/5

You cannot return things from hooks via the return statement. Instead pass the return value into $event->return like I did it in my example.

Nope. Maybe there was some change with the new persistently open page-tree and I haven't yet used one of those with it.

Update the max_nesting setting of xdebug. 300 should be enough.

What's the content of that file like? Anything strange in there?

Auto https does have the disadvantage, that as soon as there's some issue with the certificate the site is essentially down, even though it's running fine via http. As processwire.com is mostly running with guest users and mostly there to supply public information I'm not sure it that's worth the hassle to disallow http.

There's a partly free series on vue 1.0 on laracasts.com, this should get you started quite well. Just be aware that the soon to be released 2.0 version does change some parts on the inter-component communication.

I'd strongly suggest you to take a look vue.js instead of react. It's considerably more friendly to beginners, but does still have all the powers react does have (not judging advanced stuff like react native). I personally also feel, that react is more targeted to a "all or nothing" usage (at least in terms of tooling), whereas with vue you can start out just by implementing small components in your site, without the need to change everything from the get-go.

Using only a single field is not possible automatically, but as you put, quite easy to achieve manually. That's why I meant you should probably decide based on the needed workflow rather than if it's automatic or not.

I think it's mostly a workflow issue. Both depend on a "magic string" to match the language to the file, therefore I'd say do what does fit best.

Just a heads-up: the infophp.php is not accessable without login credentials.

It was for me, when I did lookup the whois data yesterday iirc.

A lot of registrars allow you to use/simply use a middleman service to anonymize the private name and address.

You should probably talk to their registrar instead of yours: abuse@enom.com.

Make sure you're setting the content-type header, otherwise jquery will handle it as plain text instead of json.

Just return json directly like so: http://stackoverflow.com/questions/4064444/returning-json-from-a-php-script

I think ditching template engines for what you're trying to do is probably not a good idea. You want to fill in html templates with various data. Static in the first place and dynamic in a second step. That's exactly what templating engines are made for and you'll probably not come far without at least implementing something like a small templating engine on your own. But a own implementation does also need own maintenance and documentation and so on and it's probably not as powerful as existing solutions. They may be a additional dependency, but really a own library is a dependency, too, which is just harder to maintain.

You should probably take a look at this one: https://medium.com/webdevs/living-styleguide-mit-fractal-und-processwire-e900f05e0b79#.vij9p35p8 (I know I should translate it some time, but I heard it's quite readable with google translate)

It's probably as simple as temporarily disabling this language inheritance for each field only for the request, where you're building the list. foreach($multiLangField as $f) { $f->langBlankInherit = LanguagesPageFieldValue::langBlankInheritNone; } // Check all your fields // Make sure non of the fields is saved before exiting