owzim

First you always want to get blue and then you don't want to always get blue. Can you please give more detail on what you actually want to achieve?

Thanks @diogo and @Soma, I'll fiddle around with the process module approach then. @pwFoo thanks but the method you're talking about is used in templates, even if it's callable in modules (perhaps it is) with $this->config->ajax, all modules other than process modules don't have a page/url per se, so neither do input fields, that's why I asked how to have some code logic that's callable via url.

Let's say I have an Inputfield module InputfieldAwesome, it has some custom JS as well and from there I want to execute some PHP via an ajax call. My question here is not how to implement the ajax and JS stuff, but where I would put the PHP that is called? I thought about creating a separate Process Module ProcessAwesome, which then resides as a page within /processwire (or custom admin url) (so /processwire/awesome would have the process of ProcessAwesome assigned to it) and has its execute methods (like executeDosomething()), so that I can then call it via ajax like /processwire/awesome/dosomething ... But it seems awkward to create extra process pages to have an input field execute some PHP via ajax, and it would clutter the admin page tree (although it would be hidden of course). Is that the way to go? I couldn't find any useful hints in existing modules.

Welcome! You are right, PW is more aimed at complex content structures but by no means limited to that. AFAIK most of Ryan's client sites are huge data behemoths (not meant in a negative way), so the core will never ship with built-in features you're talking about, and nor should they (keeps the core lean and fast), but that's not a disadvantage in any way. PW provides an amazingly flexible and powerful foundation, and that's where modules come in (in fact many of the core features are packed into modules themselves, core modules). Many of the PW users/devs here also use it for small sites, so I think there will always be an interest to serve those well too. There are couple of modules, that focus on small sites. Some that come to mind are those which provide dashboard like UIs, the Blog Profile, or the Blog Module and as you mentioned, Fredi. Also there is a very new InputfieldType, called InputfieldPageTable which essentially gives you huge amount of flexibility when constructing sites with content blocks, like for campaign sites or landing pages. Of course you are welcome to dig into Module development and enhance ProcessWire with those or contribute to existing modules. The API is incredible and you can hook into almost any functionality or process. Cheers!

You might want to check out Vagrant: https://processwire.com/talk/topic/5993-vagrant/ and http://www.vagrantup.com/ There are predefined server images with predefined configurations out there in the web, just search for it. It's a bit of a learning curve, but then it's great. The actual files/folders in the Apache are symlinks to folders on your host system, so no worries if you f*ck up the VM, just reinstall with the given config, piece of cake. Regarding your .dev domains, that's something you always manage on your host system, not the VM, so your hosts file must redirect your desired .dev domains to the IP of the VM (or you set up something like dnsmasq, where you can write wildcard rules and don't have to add every single .dev domain to the hosts file). The Apache on the VM then should handle the requests and map to the specific folders (via vhosts). But that's all pre-configurable with Vagrant, check out https://puphpet.com/, they have a guided image creator for Vagrant.

It's supposed to be fast, up to 7 times faster than Markdown PHP 1.3, see http://parsedown.org/speed https://github.com/owzim/TextformatterParsedown

That's exactly what I meant. I'm fed up with people treating webdev different than any other industry in terms of compatibility. Apple seemingly drops compatibility every two years, for areas of their OWN products. WTF ... I say you can't expect a b/w TV to display a color movie. I agree though, that sites should at least still provide access to the content, even if it's just a style-less one column thingy. PS: web apps are a very different horse. When they use JS for the front end application architecture, you can't expect it to work without JS. PS2: oh, and it's owzim, not Owzim

Hi folks, I read some posts where people seem to struggle with setting up config values for their modules. Since I am currently working on some boilerplate code for modules I created a helper class that makes handling of config values a peace of cake. on Github: https://github.com/owzim/PWModuleConfigHelper from the README.md Define a default array in your module: protected static $defaultConfig = array( // example with just one option 'prettySetting' => array( // the label for the form 'label' => 'Pretty Setting', // the default value 'value' => 'I am pretty', // optional, defaults to 'InputfieldText' 'inputfieldType' => 'InputfieldText' ), // example with multiple options 'awesomeSetting' => array( // the label for the form 'label' => 'Awesome Setting', // the default value 'value' => 2, // optional, defaults to 'InputfieldRadios' 'inputfieldType' => 'InputfieldRadios', // each key is for the input label, each value will be saved if selected 'options' => array( 'Option 1' => 1, 'Option 2' => 2, 'Option 3' => 3 ), // set any additional attribute to the input field 'attributes' => array( 'optionColumns' => 1 ) ) ); Apply the defaults to your module: public function __construct() { PWModuleConfigHelper::apply($this, self::$defaultConfig); } Render out the form: public static function getPWModuleConfigInputfields(array $data) { return PWModuleConfigHelper::renderForm($data, self::$defaultConfig); } Result: Access any of the config settings from your module: $this->awesomeSetting; Stuff to be aware of If you're using this in your module and you don't want it to clash with other modules using this, you have the following options to include it: use spl_autoload_register to autoload it, so it only gets loaded once only include the class if it has not been loaded yet, via class_exists('PWModuleConfigHelper') Option 1 and 2 require the class not to change (updates etc.) so the following options are more stable: Namespace to class via renaming it, prefixing it with you module's name Namespace it with PHP namespaces I could make a module out of this but this might be overkill Cheers!

The average Joe/Jane who still uses XP with ie8 will not even know how to "hack" the update thingy, so who cares? Yeah, me too! I am even planning on stating in my TOS, that I only support the last two browser versions of any browser. If the client wants support for older browsers, it has to be in the contract and would add a certain percentage to the overall costs.

Thanks @apeisa and @Wanze for the suggestions. I know, thanks, but that's what I meant. I have to handle permissions manually, which I think is not that desirable. I ended up creating a base class: class MyModuleBaseProcess extends Process { // useful shared process methods here } And then have the both individual ProcessModules extend from it: class ProcessMyModuleSetup extends MyModuleBaseProcess implements Module { // individual methods here } // and class ProcessMyModuleUI extends MyModuleBaseProcess implements Module { // individual methods here }

Ha it's always the same with me. Right after I asked a question the light bulb pops up over my head. I can simple have ONE ProcessModule, install it in /Admin/Setup and then create a new Page under /Admin and assign the same Process (edit/Process -> select) to it. Or of course do that in the install method. PW is awesome, have I mentioned that already? Edit: Then again, is it even wise to have two admin pages handled by one process? What I come across now is that since the two pages are aimed at different user roles I would have to manage both differently in one module. The handling of URLs is also nasty since I have to check under which parent the current process runs, for each executeSomething method. Perhaps not such a good idea? The "need' stemmed from the idea to have both pages share methods and objects.

I want a settings page under /Admin/Setup for admins and an interface for the CMS user under Admin/ directly. Would I have to have two ProcessModules for that, or is it somehow possible to manage that logic in only one ProcessModule? Thanks.

There are no words, really.

@teppo, good points I haven't yet considered, perhaps partly because I don't know jack about that Hana Code Insert WP Plugin. I don't use WP @Marcura, @Soma great one!

I was just curios about how fast PHP handles the different types of string concatenation/parsing with variables, because I saw Ryan's style is double quotes and I was thinking, isn't that slower than single quote concatenation? I was surprised because I remember to have learned that the additional parsing of double quote strings make the whole thing slower. I was wrong, here is my benchmark. Thought it'd be interesting to know. 1000000 times per test // initial object creation, only once $fooObject = new stdClass; $fooObject->foo = "Lorem ipsum dolor sit amet."; $fooObject->bar = "Consectetur adipisicing elit."; $fooObject->baz = "Sed do eiusmod tempor incididunt."; double quotes "foo: {$fooObject->foo}, bar: {$fooObject->bar}, baz: {$fooObject->baz}" 0.55859899520874 s single quotes concat 'foo: ' . $fooObject->foo . ', bar: ' . $fooObject->bar . ', baz: ' . $fooObject->baz 0.61702013015747 s sprintf sprintf("foo: %s, bar: %s, baz: %s", $fooObject->foo, $fooObject->bar, $fooObject->baz) 1.6139810085297 s array implode implode('', array('foo: ', $fooObject->foo, ', bar: ', $fooObject->bar, 'baz: ', $fooObject->baz)) 2.0107381343842 s Code: <?php $times = 1000000; ?> <h1>PHP string concat benchmark</h1> <p><?=$times?> times per test</p> <code><pre> $fooObject = new stdClass; $fooObject->foo = "Lorem ipsum dolor sit amet."; $fooObject->bar = "Consectetur adipisicing elit."; $fooObject->baz = "Sed do eiusmod tempor incididunt."; </pre></code><br> <hr> <?php function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); } $fooObject = new stdClass; $fooObject->foo = "Lorem ipsum dolor sit amet."; $fooObject->bar = "Consectetur adipisicing elit."; $fooObject->baz = "Sed do eiusmod tempor incididunt."; $time_start = microtime_float(); for ($i=0; $i < $times; $i++) { $someString = "foo: {$fooObject->foo}, bar: {$fooObject->bar}, baz: {$fooObject->baz}"; } $time_end = microtime_float(); $time = $time_end - $time_start; ?> <h2>double quote</h2> <code>"foo: {$fooObject->foo}, bar: {$fooObject->bar}, baz: {$fooObject->baz}"</code><br><br> <?=$time?> s<br><br> <hr> <?php $time_start = microtime_float(); $someString = ''; for ($i=0; $i < $times; $i++) { $someString = 'foo: ' . $fooObject->foo . ', bar: ' . $fooObject->bar . ', baz: ' . $fooObject->baz; } $time_end = microtime_float(); $time = $time_end - $time_start; ?> <h2>single quote concat</h2> <code>'foo: ' . $fooObject->foo . ', bar: ' . $fooObject->bar . ', baz: ' . $fooObject->baz</code><br><br> <?=$time?> s<br><br> <hr> <?php $time_start = microtime_float(); for ($i=0; $i < $times; $i++) { $someString = sprintf("foo: %s, bar: %s, baz: %s", $fooObject->foo, $fooObject->bar, $fooObject->baz); } $time_end = microtime_float(); $time = $time_end - $time_start; ?> <h2>sprintf</h2> <code>sprintf("foo: %s, bar: %s, baz: %s", $fooObject->foo, $fooObject->bar, $fooObject->baz)</code><br><br> <?=$time?> s<br><br> <hr> <?php $time_start = microtime_float(); for ($i=0; $i < $times; $i++) { $someString = implode('', array('foo: ', $fooObject->foo, ', bar: ', $fooObject->bar, 'baz: ', $fooObject->baz)); } $time_end = microtime_float(); $time = $time_end - $time_start; ?> <h2>array implode</h2> <code>implode('', array('foo: ', $fooObject->foo, ', bar: ', $fooObject->bar, 'baz: ', $fooObject->baz))</code><br><br> <?=$time?> s<br><br>

I very frequently see people not finding stuff in the forums, I don't blame them, the forum search sucks bit time Then many times forum members suggest to use {searchterm} site:processwire.com/talk on Google. It's true, nine times out of ten I DON'T find what I am looking for using the standard forum search. Nine times out of ten I DO find what I am looking for using Google search. So perhaps there should be a hint on the search dialog/page to use Google instead (if that's even possible). New users would find stuff quicker, saves time for all.

Hey people, look LOOK LOOOOOK at the latest commit on dev https://github.com/ryancramerdesign/ProcessWire/commit/36ec37d171672a1b786a554539cb5123b09117bc InputfieldPageTable now supports multiple templates for child items, so this is (at least for me) solving this issue. Hack away with you flexible page designs! :biggrin: CHEERS

Why are you always making fun of WillyC? I don't see any issues with his way of expressing himself.

Thanks guys, ProcessPageList is exactly what I was looking/asking for. I didn't find it in core/module/markup so I was just looking in the wrong place. And I could not find it being used in the admin theme, so I thought it was somehow baked into the admin theme itself. And Soma, I meant in the back end only of course. In the front end it would not make much sense, agreed.

AFAIK it's not a standalone right now, is it? Would be cool to have it as a markup module so that other modules could use it as well, the core would use it this way then too. It should be definable what the root page of the tree is, so that it can be used very flexibly. whaddayathink?

Soma, why are you not in the channel anymore?

Ah, but Diogo you are not from Berlin are you?

lol, the title should definitely stay English

I am not following. Some inside info I am not aware of? I think a pub and a casual context makes a good start. but I am not sure if it all even makes sense if we're just three people The location should be somewhat central, like F-Hain, P-Berg, Mitte, X-Berg or even Neukölln

Soma, I am with you on the part that devs should know English and Modules that are solely used by devs should probably not be translated. But there are modules or parts of modules that are used by the actual CMS user so that should be in the same language as the rest of the UI. Are you suggesting that even the users should have an English UI? That's what I meant. Have one repo for German translate files for modules maintained by one German and contributed to by other Germans. Is there one already?