owzim

You shall not objectify people, but you could objectify Textfields!!! Github: https://github.com/owzim/pw-fieldtype-yaml Module page: http://modules.processwire.com/modules/fieldtype-yaml/ Summary Field that stores YAML data and formats it as an object, when requested. Setup After installation create a new field, let's say called "people" and assign it to a template, or just edit an existing text-based field and choose Yaml for the type, save! In the Details-Tab you have an additional option, the Texformatter option is removed, because it does not make sense in this case. Parse as Default is WireArray/WireData, the data can also be parsed as Object or Associative Array. Associative Array is the fastest and the default output by the used Spyc parser, WireArray/WireData might be the slowest, but it's also the most feature rich. You can access properties like you are used to with pages or fields, like $page->person->get('title|name') or $page->people->find('age>30'). Usage Now, in your just created field you can put in some YAML like this: - name: Jane Doe occupation: Product Manager age: 33 hobbies: - running - movies - name: John Doe occupation: Service Worker age: 28 hobbies: - cycling - fishing In your template, or wherever you are accessing the page, you would use it like any other ProcesssWire data (if you set the parse option to either WireData or Object): $out = ''; foreach ($page->people as $person) { $out .= "Name: {$person->name} <br>"; $out .= "Occupation: {$person->occupation} <br>"; $out .= "Age: {$person->age} <br>"; $out .= "Hobbies: <br>"; foreach ($person->hobbies as $hobby) { $out .= "- {$hobby} <br>"; } $out .= "--- <br>"; } echo $out; More info about YAML: Complete idiot's introduction to YAML Specification Wikipedia Acknowledgements I've used a namespaced version of the Autoloader class from Template Data Providers The YAML parser is a namespaced version of Spyc Edit: updated the repo link

Why not write this: ob_start(); echo $form->render(); // draw form or process submitted form $this->formMarkup = ob_get_contents(); ob_end_clean(); Like this: $this->formMarkup = $form->render(); ? Why generate output, create an output buffer, to then assign the buffer to a variable, if you can assign the form output directly to the var?

Looks great, have to try it out soon. Thanks for your contribution.

I just revisited the issue and now I understand what you mean with the output thingy, found that too. This makes it work, but setting data directly to the fuel leaves a bad taste in my mouth. /** * Provides direct reference access to variables in $this->page->output * * Overwrites \WireData::__set * * @param string $key * @param mixed $value */ public function __set($key, $value) { $this->wire($key, $value); $this->page->output->$key = $value; } Just browsed through the core code to find info about the fuel, and found that in the docs of setFuel: The data sharing via output is great because all fuel data gets merged into the output, so a potential overwrite of fuel data is not possible. setting data to the fuel directly entails the risk of overwriting stuff, which can lead to very unwanted behavior, e.g. modules that hook into after page render (or something similar) might get a messed up fuel. Am I right? I might not be ... Sadly one cannot hook into that specific part of the page render process. Only via replacing the whole method via hook, which might lead to a crap fest as well Edit: I just tested it, you cannot set most of the fuel vars, like session, fields, or templates, they are locked and throw an Exception, great stuff. You can however overwrite say, page or db (I guess they are supposed to be dynamic, because they are set by the system itself and change). So the fuel way could work after all? I created a pull request: https://github.com/marcostoll/processwire-template-data-providers/pull/6

Thanks horst, but what I was looking for can be found in a blog post by Ryan, I just discovered it yesterday: https://processwire.com/blog/posts/august-2014-core-updates-1/

Why the not list the users without the region selector? $users->find("template=user, include=all"); Or if you want to display all users that have a region assigned (matching users with a non-empty user_region field): $users->find("template=user, user_region!='', include=all");

So your $inputregion can be multiple regions? If it's an array you can implode it with a pipe symbol: $inputregion = implode('|', $inputregion); // creates something like 'region1|region2|region3' So the selector looks something like this: $users->find("template=user, user_region=region1|region2|region3, include=all"); and it matches users with either of those regions

I want the module installation process to ask for user input before installing anything, how to implement that? Any modules that use such a thing, so that I can look into it? Thanks.

Three days at Beyond Tellerand made @marcus and me spawn some great ideas for this. One of which is that we will maintain a text-based repo of recipes, so that they are decoupled of any database, are properly version controlled and anyone with a GitHub account can contribute easily. This may be great opportunity for those of you who have not yet been using something like git to finally dive into it. I wrote an importer module, which already works pretty well. The rough structure is decided upon as well. Let's get it on! PS: we also met nico one day, what a very nice fella he is .. I had too much to drink that night though

Hi Ryan, is there any update on that? Is it going to be implemented?

I am not 100% sure but I guess a change in the .htaccess should do it: Find the line where RewriteBase is commented out, remove the comment and change it to: RewriteBase /projects/ProcessWire/ Edit: nope, that's not it. I am answering too fast today, sorry.

Just to summarize what I got from you question: On your PageEdit page in admin you have a couple of fields, and you want to show a list that automatically updates, when you change values of the fields? Is that list only for visual assistance or do also want to select one of the companies that are contained in the resulting list? Either way, as far as I know, that's not possible out of the box. I don't know of any Inputfield that handles such a thing, but it's definitely possible do code one.

I don't understand why you want to put the output in one field and not rather just put you logic in the themplate file. Anyway, you can define fields via hook properties (code not tested): // add a hook in you init or any other file that is included by template files $pages->addHookProperty("Page::deliveryCompanies", null, function($event) { $page = $event->object; // limit to the template 'product' if ($page->template->name === 'product') { $out = '<ul>'; // find the companies that deliver with a selector (just an example, pseudo code if you will) $companies = $pages->find("company.someField={$page->someOtherField}"); foreach ($companies as $company) { $out. = "<li>{$company->name}</li>"; } $out .= '</ul>'; // return the list $event->return = $out; } }); // echo out the list in your template files echo $page->deliveryCompanies; read more on hooks here: https://processwire.com/api/hooks/ Edit: might have misunderstood the question completely Oo

I just had to fiddle around with that. It might be important to note that if you apply ANY field setting via $fields->saveFieldgroupContext all other field settings are copied over to the contextual settings as well. So if you only set columnWidth the title (and all others) is copied over too. If you change the original non-contextual title, the old title stays in the fieldgroup context. I wish the behavior would be like merging values, so when I change columnWidth only, all other values are taken on the fly from the non-contextual field settings when requested.

I'd give the second one 34% then it's at least symmetrical

Nooooo that steals away some very convenient flexibility from me, I just thought I had. But it makes sense, thanks for the insight. What immediately comes to mind is that selecting pages with say a limit of 10 and a nice pagination would be messed up if the filter does not spit out any pages before the first 10 results. Are there any good practices dealing with this kind of situations?

I found something I'd consider a bug. Let's say we have this very useless hook: $pages->addHookProperty("Page::foo", null, function($event) { $page = $event->object; if ($page->title === "About") { $event->return = "About foo"; } }); When I search for pages with a non empty foo property: $pages->find("foo!=''"); I get an exception: Error: Exception: Field does not exist: foo (in /wire/core/PageFinder.php line 494) Which I consider very IN YOUR FACE to begin with, even if the hooked property foo would not exist. If none of the pages have a field called foo, then just get me ZERO pages. BUT since this property is created via hook, PW should not tell me the field does not exist. However, If I use the same search with a filter it works as expected, I get a PageArray with one result (bc there is one page with the title About): $pages->find("*")->filter("foo!=''"); Please don't tell me this is expected behavior

GitHub: https://github.com/owzim/FieldnameUnprefixer From the README.md: Makes it possible to access prefixed field names without the prefix. Usage Create some prefixed fields and add it to you desired template, for example prefix_myField and otherPrefix_myOtherField. Configure the prefixes, that should be removed in your /site/config.php, like so: $config->FieldnameUnprefixer = array( 'basic-page' => array('prefix_', 'otherPrefix_'), 'home' => array('prefix_', 'otherPrefix_') ); The first array keys are the template names. The Prefixes also can be assigned as a string if it's just a single one: $config->FieldnameUnprefixer = array( 'basic-page' => 'prefix_', 'home' => 'otherPrefix_' ); Now you can access the fields without the prefix, like so: echo $page->myField; echo $page->myOtherField; The unprefixed field names are now also accessible via selectors, but only for already fetched data, since the field is not really in the database: // not $pages->find('myField=something'); // but $pages->find('template.name=basic-page')->filter('myField=something'); Use case Prefixes are sometimes necessary to have fields that behave specific to the template, so you need to create a specific field and namespace it with a prefix, but don't want to access the fields differently on each template. // eeew! $client->client_address; $something->something_address; // yay! $client->address; $something->address; Might be not the ProcessWire-way because data access is abstracted, but I use it, and perhaps some of you find it useful too.

Thanks guys, I was hoping for ONE selector, then I was thinking about the new nested selectors but those only work with pages. It should be unified in my opinion. That should do it for now though.

$pages->get("process=ProcessHome, include=all"); // returns NullPage I also tried adding check_access=0 and other Process-names $pages->get("process=ProcessPageEdit, include=all, check_access=0"); // returns NullPage Why is it not working? It should, shouldn't it?

Just have a plain text field, put in your code and let the front end handle the highlighting. Two of the more popular solutions out there: http://prismjs.com/ or https://highlightjs.org/

@netcarver sorry I did not get any email notification, because I disabled them while I was in deep deadline madness. This class is obsolete anyway because Ryan implemented similar stuff in the core, see http://processwire.com/blog/posts/new-module-configuration-options/ Thanks Ryan for hearing us out (there was also a discussion about this somewhere, don't know where)!

If you go the route of importing your data with the API and an install script it's worth mentioning that you can restore your system easily while developing you install script. So make a backup before, via $database->backups()->backup(); An in your script at the beginning, add a $database->backups()->restore("filename"); So each time it runs, you have a fresh version you can hack on, without having to clean up manually each time you mess up something. More details here: https://processwire.com/blog/posts/august-2014-core-updates-4/ I think it's very convenient =) Of course you have to remove the restore call when you're finished with your script. Additionally since PW 2.5.4 (yesterday) you can pass arrays to InputfieldWrapper, InputfieldForm, or InputfieldFieldset which makes creating the necessary templates and respective fields for your imported data very easy and fast. See at the bottom: https://processwire.com/blog/posts/new-module-configuration-options/ https://processwire.com/blog/posts/august-2014-core-updates-4/

I don't but any of the PW hackers here should. What irritated me, is that with the Twig replace module everything works as expected, for which a reason should exist, so I looked into the code, and not only is the Twig replace module hooking into PageRender::renderPage instead of Page::render (as suggested in my GitHub issue) but also the vars are explicitly collected and passed, see https://github.com/marcostoll/processwire-template-twig-replace/blob/master/TemplateTwigReplace.module#L216 $twigVars = $this->collectVariables($page->output); $output = $this->getTwig()->render($page->template->name . '.' . wire('config')->templateExtension, $twigVars); So perhaps the right path would be to actually replace the render method with the same hook as above and load the respective template file and the TemplateFile class. The downside of it (and I think it's the same with Twig replace module) that the render method must be held in sync with the core version (appending, and prepending files like _init.php and such, and also the new template specific append/prepend functionality since 2.5). I am not too much into the topic so I might just be guessing here. Dear PW hackers come one, come all. PS/OT: this forum should support MarkDown, post authoring/editing in here is a bloody mess.

For me this Module is the best approach for organizing logic and views without being too much in your face with restrictions. I tested it yesterday, and like it very much and discovered the same problem as @marcus without knowing it has been posted here. I created an issue: https://github.com/marcostoll/processwire-template-data-providers/issues/2 What's the status of this module? Will it be maintained further?