LostKobrakai

Only global fields will be displayed in the PageAdd form, even if you limit templates and parents down with family settings.

Hidden is just that: hidden. So it shouldn't be visible in neither the nav as well as searches. If you need other semantics create your own checkboxes / logic.

It certainly can do that. But you could also go with PageTables, which can have different types of pages added to it. The most difficult question for you is probably, that you need to settle on some kind of structures blocks (one or more), which will later be pieced together to your tutorials. If you know how this might look like then this'll determine whats the best field to choose for the job.

If you want to learn I'd highly suggest subscribing to laracasts. While the main focus is obviously laravel it does also have tons of general php videos from beginner to advanced levels. I've learned so much there – even from some of the laravel specific videos – even while never having run laravel once.

Take a look at page-tables, repeaters (both not installed by default, but part of the core) or the commercial matrix fieldtype.

$this->className() in the ModuleConfig will return the name of the config class not the module (as would get_class()). Just remove the …Config suffix. But as soon as you're passing it the correct module name it's going to work wherever you need it. Also I'm not really sure if this kind of functionality actually should be put in the config module in the first place. It's convenient, but a actual function of the module, triggered on init() if a specific config is set, might actually be the better structure.

$name = $this->className(); // Namespace aware $config = $this->modules->getModuleConfigData($name); // Before 3.0.16 $config['my_checkbox'] = ''; $config = $this->modules->setModuleConfigData($name, $config); // Before 3.0.16

How about not overwriting the value of the inputfield, but actually overwriting the thing you actually want to change: the module config.

You probably want to change the value as well.

You can do that, but not with ProCache, and it won't give you the big speed improvement of it. ProCache is so fast, because it's not even starting php, and neither processwire. What you are looking for is the $cache api: https://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades

I'm not sure if you'd actually save very much processing capabilities, as you'd still need to process one request per page (at least without CDN enabled). It's only faster by the time needed to render the actual page. I'd really suggest going with the right tool for the job, which is google analytics or something similar, if possible. But the actual implementation would not be difficult / different to other ajax stuff often explained in the forums. Just send the current url to the server, look for the page in that path and count the view field up.

<?php $shows = $pages->get('/shows/')->children; $currentTime = time(); $future = $shows->find("show_date>$currentTime"); $past = $shows->not("show_date>$currentTime");

The problem is not the template, but the parent for the page. There's no way of knowing where to put that page. But I understand your confusion. In the beginning this button was only visible if you had created the necessary parent/child setup for templates, so at least the one setting it up knew about it and it had a at least a "useful" option to show the user if the button was visible. Now that the "Bookmarks" thing is always available this intermediate step is no longer necessary for the button to show up. I'm also not sure if this is really the correct place for the bookmark creation in the first place.

If you've control over the server there's also mosh, which is a more stable alternative to ssh with mobile connections in mind.

Do you have ajax loading enabled? It might be the case, that the javascript required is not supporting ajax loaded fields.

It's exactly the same when you're using repeaters. They'll also create a page for each item. Even though it might only hold 2 or 3 fields.

It's in InputfieldTextarea::init()

I might repeat myself in parts, but we already have ways to handle similarly shaped recurring data. It's by using a dedicated Template and Pages. The only thing missing from my point of view is a nice way of creating and handling those pages, which is something present in repeaters as well as in pagetables. It's just not available for a one-to-one relationship, which it would be for example for seo settings. Imagine your page could have a single, automatically created repeater page without the wrapping fieldset around it. I doubt anyone would ever notice that it's another page. But it would still have all the abilities you have for all other pages and nothing would need to change in the core of ProcessWire.

That's some really nice work and certainly a nice showcase for processwire and it's abilities. I wonder if you can share something about how you managed to get a bigger company like EIZO to work with ProcessWire as cms, as actually selling a kinda niche software is often not an easy task.

Ah, thought there would be a setting: The textarea inputfield is limited to 8 * 1024 characters and 3 * 8 * 1024 bytes. There are already lot's of topics around in the forums about that limit, but I cannot give you an answer on how to circumvent this limit or why it's this low (a text row in mysql could hold 60k bytes).

Did you check your maxlength setting for the textarea field?

Maybe this is useful for you: http://cheatsheet.processwire.com/pagearray-wirearray/getting-items/a-eq-n/

Didn't it work without? The compiler should normally take care of this automatically.

There isn't one, other than passing the instance into the function as parameter. But really a class is way better in handling this kind of state. <?php namespace ProcessWire; class Helpers extends Wire{ public function getGlobalSeo() { return $this->wire('pages')->get('/')->seo; } } In the init.php $helpers = $this->wire(new Helpers); // Wire the instance into the helpers class $this->wire('helpers', $helpers); // Add as api variable In your templates $seo = $helpers->getGlobalSeo(); …

It's because all other options are aware of their instance (e.g. a page of instance1 will get the configs of instance1), whereas the global wire function does not have state and therefore does only ever return the "primary" instance, which is simply the first one ever instantiated. Edit: Maybe 'avoid' it to hard, but one needs to be aware that the function is not aware of additional instances. Especially in hooks or alike, where people are currently often using wire() one should rather use $event->wire() so the hook is not prone to using a different instance than intended.