LostKobrakai

https://processwire.com/talk/topic/5513-fieldtype-cache-please-elaborate/

You could just ask the template to give you all fields it does posses: $selector = "..." . $template->fields->implode("|", "name") . "*=$string"; If you can specify all field beforehand you could use FieldtypeCache and add all necessary fields to it. After that you can just search the cache field instead of all other fields.

Html does not care about which quotes are used and from the php standpoint it's more useful to go with double quotes to have the ability to insert variables directly. If that doesn't fit your style you can still use explicit concatination. Html 5 doesn't even need quote in lot's of arguments anymore and I really cannot remember the last time I actually looked at raw source code. All the dev tools automatically convert quotes to the double ones so I'm not sure why inconsistancy in the html result would matter. Edit: Not to mention, that this style guide is meant for the core development, where probably 80% of the code aren't related to html.

Any server side caches enabled, like opcache and others?

To add to Martijn answer. This sanitizer is meant to sanitize a single selector value, not even a whole selector string, e.g. $mytitlewithcomma = "Hamburg, the great harbour city"; // Will fail $pages->get("title=$mytitlewithcomma"); // Won't fail $sanitized = $sanitizer->selectorValue($mytitlewithcomma); $pages->get("title=$sanitized");

Exactly the opposite will be the case. Pages are build to scale almost infinitly, while each page does automatically retreive all it's fields' data at once, which doesn't scale nearly as well. So in you're case I'd suggest using a single page per document, as you most likely will always need all data associated to a document, but you're not always in the need to get all documents ad once.

Just use $(document).ready(function(){ … }); around your code, so it's not executed before the whole dom is loaded.

I doubt this every being meant to be used by devs, so I wouldn't expect another way. You could just copy the module to site/modules to save it from being automatically updated.

I'd just strip of the "Open Source CMS/CMF" part. If someone is really curious because of that line he'll surely be curious enough to google the name as well.

$page is of the admin template for everything you visit in the backend. But most of the time you're interested in the page your editing and not the "admin page" your on.

The $page variable is only available through the HookEvent, so you cannot dynamically add the hook, besides if you already have the exact instance of the class you want to hook.

You can always strip off additional pages using php, but that's certainly not the best user experience. For the ASM Select you could create a javascript, which does disable all options from the select box if a certain number of pages was selected (and reset if not).

I'm talking about the inputfield you choose the page field to use, e.g. Select, ASMSelect, PageListSelect and so on. These all work differently in terms of markup and javascript, so it's understandable that there's no central way to limit the number of selections beyond single / multiple. Single and Multiple pagefields are even mostly using different inputfields.

Facebook might seem nice from the outside, but it's actually a damn lot of work to get any reach without paying facebook to advertise the company. Without regular (daily at best) posts you'll hardly get visitors beyond the people who actually know you already. The agency vs. single dev argument might be true, but that's the case for every single freelancer no matter of the industry. I think the best way to get along with that is a strong portfolio and optionally a small high quality set of partners and fellow devs (of other strengths), which you can rely on in bigger projects. Especially if they have a strong portfolio as well you can certainly assure clients that they'll get the same quality as they can expect from an similarly sized agency. Surely you can't do the job a whole team of people is doing in an agency, especially in a similar timeframe. So to get the really big projects one needs to have a critical number of people on board.

This greatly depends on the inputfield you're using as it's javascript which would solve this. The only thing you could do from pw aka php is stripping additional pages when saving the page.

@kixe I think if modules should work under 2.7 and 3.0 without code changes they need to be without namespace.

This is on the list of additions for 3.0. https://github.com/ryancramerdesign/ProcessWire/issues/1508 Edit: I think your last example is what actually happens if you just change the parent of a page.

There's nothing more processwirey in it than in your code. It's more about clean code structure.

I've not much overview over the specifics, but it sounds like the way to go.

Why not create a copy and remove the encoding functionality from smartypants? As long as you make sure everything is encoded afterwards there shouldn't be any concerns with that.

Just the foreach loop: foreach ($page->children as $child){ $link = "<a href='#panel_$child->id'>$child->title</a>"; // Only one content div per accordion $body = "<div id='panel_$child->id' class='content'>"; foreach ($child->children as $childsub){ $body .= "<div>"; // div per content row $body .= " <img src='{$childsub->icon->url}'>"; $body .= " $childsub->title $childsub->uitleg"; $body .= "</div>"; } $body .= "</div>"; $content .= "<li class='accordion-navigation'>{$link}{$body}</li>"; }

The user class is just an more specific page class, so it shouldn't have any correlation with the password, as 'pass' is a field with the FieldtypePassword.

I think you should be able to read the hashed password to export them, e.g. with the PageActionExportCsv which comes with listerpro. I'm just not sure if those hashed passwords would be rehashed, when importing the csv.

Wheren't those hanna code snippets actually stored as files? So you should be able to edit those directly.

There's Pages::saved, which is called on every $pages->save() execution and there's Pages::savedField, which is called on every $pages->saveField() execution. You probably need to hook both, to cover all posibilities.