owzim

I can't find the post. I remember that we talked about having a Github repo for all german translation files for all modules, so I am not aware of the current state of discussion there. Does anyone know where that post is? Edit: found it https://processwire.com/talk/topic/2583-delivering-module-translations/?p=41767 I think that discussion also belongs here? Were can we even find module translations?

Well I mean the kin of setup. Is it a causal get-together? Will there be talks or short stories about who's working on what currently? ... something like that.

In many cases it's just the RewriteBase directive in the .htaccess. The first thing I do after every PW installation is to comment it in: From this: # RewriteBase / to this: RewriteBase /

Great news Ryan. Would it then not be possible to make even the static calls like wire('var') aware of their contexts? I mean at the moment a wire('page') call is ware of it's page context, it knows on which pare we are currently on. In classes, couldn't we apply that also to some kind of DB context awareness then? How would a module know on which PW instance it's currently working on? I assume that the instance properties, like $this->input or $this->page are somehow set in the background and the access of them code wise would not change for a module dev, right? So why wouldn't it be possible to have a static call also have a context (PW instance)?

Not sure what you mean. Of course you can only call methods statically if they're static. Wire::input(); ... would be a static call, yes. Did I misunderstand?

For me it's not clear yet. I stumbled upon that in Soma's module: InputfieldDimension.module Line 103 So $this corresponds to the Inputfield but when I look at CaptainHook there is no change hook for Inputfield, what am I not getting here?

Yeah and it says it in the title too ;D So for now we are three, perhaps four. I don't think that's enough for a regular meetup for now. Perhaps we could talk a bout a format beforehand?

Currently we have those to access for example 'pages': // in templates $pages->find('something'); // in functions or classes not extending WireData wire('pages')->find('something'); // in classes extending WireData $this->pages->find('something'); // or even a deprecated old way $this->fuel('pages')->find('something'); I propose to implement yet another way: Wire::pages()->find('something'); // or Wire::config()->debug; // or Wire::input()->urlSegements; It would just be a matter of adding those in the Wire class: public static function input() { return self::getFuel('input'); } public static function pages() { return self::getFuel('pages'); } public static function page() { return self::getFuel('page'); } // and so on ... Perhaps it's just aesthetics, ... for my eyes it's definitely way more pleasing. What do you think?

Great little nifty module diogo, I see some use cases for this.

Hi Berlin people, is there some general interest? Let me know! I see there are 3 Members who reveal their location as Berlin, but there have to be more, c'mon! =)

Sublime Text 3 before that: Sublime Text 2 before that: Komodo Edit Tried Atom short after invite beta launch, was too laggy for me. Perhaps that has changed but I also don't want to invest in migrating all my routines/workflows to a new environment right now.

Hehe my weekend has been occupied by contributing to this module =) I'd suggest to have a separate repo for the JSON setups and only leave those in the actual repo which show all the different features.

We should celebrate =)

Great tutorial Martijn, thanks. I also recently reinstalled my mac and I started to go through all this hassle of installing all components manually. Someone on twitter pointed me to homebrew, which I had heard of but had not used until then (http://brew.sh/). It's a packet manager, I am sure most of you mac users have heard of it. It makes installing these components and their dependencies almost headache-free, and they are easily updatable. Still, the configuration can be a pain in the butt, so your tips are very valuable. At the moment I am eyeballing with Vagrant but haven't had the time yet to grasp the whole beast to make it fit my needs.

bwakad, the function wire('some-key') returns the respective instance of the object you are looking for. I am not sure if the instances are created on call, or just once, but if you are looking for performance you can at least save multiple function calls by assigning the returned object to a variable. Especially when in large loops the function calls can be expensive. so instead of this: wire('page')->someVal; wire('page')->someOtherVal; wire('page')->someMethod(); wire('pages')->find('selector'); wire('pages')->get('selector'); // and so on you would use it like this: // save page into variable $page = wire('page'); // call methods and properties from variable $page->someVal; $page->someOtherVal; $page->someMethod(); // save pages into variable $pages = wire('pages'); // call methods and properties from variable $pages->find('selector'); $pages->get('selector'); // and so on Edit: Side note, just looked into the core code, looks like the instances of pages, page and so on are not created on each wire() call but merely accessed, but each wire() call also triggers multiple function and variable calls internally, so you would save those too, when saving into a var just once.

First of all: Welcome to the world of PW =) Second: no worries about spelling and grammar. There so many people on here who are not native English speakers and a lot of posts full of broken English ;D We still understand each other. Regarding your question: I can't help you with that, because I am not proficient enough with Twig yet. What my opinion on your way of wanting to do things is that you rather should exclude as much logic from the Twig templates as possible. I would not recommend implementing search logic into a Twig template. As far as I know the TwigReplace module alone might not be optimal, use the DataProviders module by the same author to seperate the concerns of logic and rendering. Or use Twig separately to just render out the data you prepared with PHP beforehand. Only use some conditional statements, loops, variables and string modifiers. Well, that's how I see things =)

Seems like an excellent module. I had some problems though, see https://github.com/weworkweplay/ProcessJSONInstaller/issues/3 https://github.com/weworkweplay/ProcessJSONInstaller/issues/4

I know three members of this forum who will be there. Not sure if I am allowed to tell, so I leave it to them =) Unfortunately I will not be there =( Have fun!

Well said, Charles!

Great point, I agree. Though, I don't think it's an invalid answer suggesting to maybe go back a few steps so that your current problem becomes more clear. What I see in your situation is that you're trying to optimise in areas which might not be the source of the problem. I don't know your setup, but in most cases the frontend is the bottleneck. Look at the profiler in chrome dev tools and find out if it's actually the site rendering (of the HTML via PHP, not the visual rendering) which is taking so long, or if it's the scripts, perhaps external sources and so on.

Nice shortcut, did not know it existed. But I think it's less expressive =)

either you modify the links while creating the menu, like in this approach: https://processwire.com/talk/topic/4261-parent-pages-and-their-behavior/ or you put this in the template which wraps the child pages: $session->redirect($page->children->first()->url);

whoops, that's the one I intended to link to =)

There is one (http://community.invisionpower.com/files/file/6253-mentions/), though I don't know if there is a more recent or better one. I think it would be cool, what do you think? This would require users to use it. I often times see users mentioning other users by their real name, I sometimes don't know who they are talking to/about =) Edit: replaced wrong link

Ryan, have you thought about making the store something that module authors can publish their commercial modules at? You then take 10% or so. This would make it the goto-store for commercial modules, and authors would not have to come up with custom solutions selling their modules.