Martijn Geerts

@Christophe, I'm more woried about the margin-right: -.25em they are using on columns. They use it to eliminate the white-space between the columns. But when you properly minify the source, there's no white-space, so little gaps will show up.

Tracy is FANTASTIC, thanks Adrian !

Maybe it's possible with Javascript to disable the inspector. Or with some hacky script the disables the rendering of the rendered source. Maybe you could disable the context click to the inspector. All the things you try, would be hacky. But you can't insure the the user can't see the source. Then there's always the raw source that you can get from the browser. This is just the nature of webbrowsers and has nothing to do with CMS. You can prevent hotlinking on the other side.

Can you explain a little more? Do you need your assets to be hidden for guest users?

@Robin S, that one is not compatible with auto complete. (wishlist @ryan, please make that one compatible) Normal selects can work with it.

It is hard to manage time theses days, so haven't tried this yet. Your module can help enormous with debugging so probably will be a real time saver. Big thanks for the module and the extended blog post. I will look into this soon. Thanks again Adrian!

Thanks Ferdi !

As those don't need custom content you probably can go for urlSegments instead of real pages.

@szabesz, those kinda things happen 'all the time'.

@SteveB, can you drop the whole module. So we can test it out.

Had you refreshed the modules cache ?

When you hook after, your event->return is your form I guess . $this->addHookAfter('ProcessPageAdd::buildForm', $this, 'intervene'); public function intervene(HookEvent $event) { $form = $event->return; $name = $form->getChildByName('_pw_page_name'); $name->set('value', 'tralala-my-ding-ding-dong'); }

@adrianmak Firstly it takes alot of effort in terms of time bandwidth to document it all next to the documentation that is already provided in the source code. Then it is difficult to have the documentation that is not in the code to be in sync with the 'changing' documentation. Then keep in mind that most 'advanced' users will look in the source code to find 'documentation' or figure out what is going on right there anyway without searching decoupled documentation. Documentation should be written by 'advanced' users, on the other hand, those users are likely to use the source code to lookup methods and stuff, so they are not the 'real users' of that decoupled documentation. Then there is the NOT fun part of documenting. In a lively environment as ProcessWire, new methods are added other methods become deprecated. It's hard to keep track of all those. I think we all wish documentation stays in sync and is complete. On the other-hand, when looking in the source code of ProcessWire you will recognise the effort Ryan takes to document and comment. I have to say, that the documentation in the code base is good and keeps getting better over time.

I think what @benbyf wants to say that it is good to really understand CSS so that you don't have to rely on a grid system. CSS looks simple, but because it loose nature, the inheritance and browsers issues it's quite difficult.

Ok, 2.7.2 is older then say November last year, as a normal update doesn't alter the data base, and thus doesn't clean your settings it is still there, you can ignore it or remove it from the JSON object for import purposes.

What version of ProcessWire are you using? That setting should not be in the field settings, and has been/should has been fixed end last year (removed). You could safely ignore send_templates as it's not used in import context.

Maybe when you add page-view permission to the info array of that module?

ขอบคุณมาก

@tpr, actually it is. I love the new Job but moved away from Agrio with very good feelings. I realy like the guys/girls over there. There were multiple parts to that project, one part was the content management in ProcessWire. It works quite nice and I feel good about it.

A project that I started at Agrio. (Now have an other Job) They nice folks over there are continuing that project so that makes me happy . I guess they have to do mainly front-end work now. Probably they make it a JSON API... Thats the way I would have gone.

BTW, good to see you guys are busy with the front-end of my Market Tool . I do guess you guys use a delegate approach?

<?php /** * Do this before outputting the scripts array (before a 'view' file) * */ // Cache outputformatting to a variable $of = $page->of(); // Put it off, as Hannacode works with outputformatting isn't it? $page->of(false); $schlaghecke = array( '[[chart item=a period=month]]' => '/file/to/add/month.js', '[[chart item=a period=3months]]' => '/file/to/add/3months.js', ) foreach ($schlaghecke as $hanna => $file) { if (strpos($page->body, $hanna) !== false) { // is always unique $config->scripts->append($file); } } // Restore to previous state of outputformatting $page->of($of);

There's no 'correct' way, something like this might also work. <?php // Cache outputformatting to a variable $of = $page->of(); // Put it off, as Hannacode relies on outputformatting isn't it? $page->of(false); // Search if we have a hanna tag like thingy if (strpos($page->body, '[[') !== false) { // Yay, we have [[, so at least a Hanna tag like thingy. // You could search for a specific hanna tag if wanted // Do Script injection.... what ever } // Restore to previous state of outputformatting $page->of($of);

You want something like this?: http://codepen.io/Da-Fecto/pen/aNppXr

Not a bug, it just how it is. The 1 page is forced by the Inputfield, not the Fieldtype.