owzim

Are you assigning the return of the function to something? $results = selector(); foreach($results as $result) { echo "{$result->title} <br>"; }

Can one do that? Build custom access controls? That'd be awesome. For now: Let's say you have the following structure: Pages - Page 1 - PageField 'userGroupSelect' - user-group-1 - Page 2 - PageField 'userGroupSelect' - user-group-2 - Page 3 - PageField 'userGroupSelect' - user-group-3 User Groups (which are pages) - User Group 1 - PageField 'userSelect' - user1 - user3 - User Group 2 - PageField 'userSelect' - user2 - user3 - User Group 3 - PageField 'userSelect' - user2 - user3 the following code would get you the references: // the user you want to get references for $targetUser = $users->get("user3"); // find pages that reference users $userReferences = $pages->find("userSelect.count>0"); // create empty page array, which will contain the matching groups $groupsWithUser = new PageArray(); foreach ($userReferences as $userReference) { if($userReference->userSelect->has("id={$targetUser->id}")) { $groupsWithUser->push($userReference); } } // find pages that reference user groups $groupReferences = $pages->find("userGroupSelect.count>0"); // create empty page array, which will contain the matching pages $pagesWithGroups = new PageArray(); foreach ($groupReferences as $groupReference) { if($groupReference->userGroupSelect->has("id={$groupReference->id}")) { $pagesWithGroups->push($groupReference); } } foreach ($groupsWithUser as $groupWithUser) { echo "{$targetUser->name} is referenced in User Group '{$groupWithUser->name}'<br>"; } foreach ($pagesWithGroups as $pageWithGroups) { echo "{$targetUser->name} is referenced in Page '{$pageWithGroups->name}'<br>"; } Perhaps there is a more elegant way, dunno. But as I said, you would want to wrap that logic into a custom hook for users, like $user->isInGroup('user-group-1') or $user->isReferencedOnPage('some-page-name') or something similar.

Getting a reference chain is one thing and might come in handy in other situations too, but for your case you might be satisfied what PW provides out of the box. You have your User Roles, which are essentially your Groups. You also can define permissions on a template basis. if you want finer grained access per page you might wanna check out the "Page Edit Per User"-Module: http://modules.processwire.com/modules/page-edit-per-user/ There is also a Module by apeisa in the works for managing groups: https://processwire.com/talk/topic/5354-usergroups-module-in-development-groups-page-based-permissions/ You can even have permission per field: http://modules.processwire.com/modules/page-edit-field-permission/ Still, have you worked out a solution that works for you already? I am sure one could patch together the pseudo code I wrote in my previous post in a couple of minutes.

Interesting question, wanna know the answer too =) Why do you need it? Breadcrumbs-like thing? I doubt it's possible with one selector only (perhaps with the new nested selectors). I would select all categories/groups with "your-user-page-field-name-here"-value of your desired user and then select all pages with "your-category/group-page-field-name-here"-value of each previously selected groups/categories. To wrap it all nicely I would first of all create a new hook called something like $page->references('page-field-name'); which spits out a WireArray of all the referencing pages. You can go from there then ...

Just to clarify: When defining the "Selectable Pages" in the PageField's input tab, select the users from the page tree: Admin > Access > Users

Looks promising, so lets see how the modules participation goes. I like how you can create the UI with simple HTML instead of setting millions of options which then render the HTML UI via JS in other RTE solutions.

Great solution adrian, I'll try to explain why this is faster than leoric's method and how both work, for people who don't know: $pages->find("include=all"); ... will fetch ALL pages, which means PW is creating objects/instances for every single page that is fetched, which is very expensive. $pages->get("include=all, sort=-id"); ... on the other hand will only fetch ONE page and therefore only create only ONE Page instance for that query. The sort=-id will take care of an descending sort order by id, so the last added page will be returned. What I am wondering though is, why the API is not taking care of that with limit=1 in leoric's example. I am sure there is a reason, I am not familiar with the internals of that process.

@Soma, I just setup the whole thing, see: https://github.com/owzim/PWCaptainHookCLI Now the output of the array only has to be integrated into your html.

I just played around with with PageTableField, which alone is a great addition. The TextAreas module seems like a very clever solution for grouping fields. Will fiddle around with it soon. What interest me though is, how the Modules will be licensed. I'd prefer a per site license and a free dev license. Since it will be part of the core and a great show case on whats possible with PW, people would be wanting to try it out, also newbies. If you you have to pay for it just to play with it it might be a hurdle. I can see these modules as being an essential part of site building with PW. I am having trouble articulating my point, but the gist is, that I think a per site license should be enough. TextField Module: As far as I understand you will define the labels of the fields on that one TextArea definition field. How would I go about and have that multi language ready? Perhaps it would be better if one could define each fields name, title and description each in their own input field, so it can be multilang.

I've heard quite a bit about it in the last couple of months, but tried it out myself just yesterday. It's great. I think I'm gonna switch to vagrant instead of my local env. If you're using your local env. for all projects you might as well just use one vagrant box for all projects. You'd still have the advantage of not messing up your local env. with crazy configurations. It'd be interesting to know if those issues are windows only. To all who are using vagrant currently: What are your workflows regarding mysql dumps? I tend to config a pre commit hook in my projects which dumps the database of the current PW install before committing. Since the db is in the vagrant box, are there any issues getting a dump of a db from it? I haven't tried it out myself yet, I think it should be possible to just connect to the vagrant mysql server instead of the local one and dump the db from there.

I just patched together some simple PHP code to scan for hooks: https://gist.github.com/owzim/6f7c2ef6394f25e04269 I think we could go from there and build a shell script that clones/pulls the PW repo checks out master and generates html > captain-hook-master.html checks out dev and generates html > captain-hook-dev.html updates the github page What do you think?

The current Captain Hook's line numbers are not in sync with the dev branch. Perhaps there should be a stable Captain Hook which points to the master branch and a version for the dev branch, which suggests that line numbers could be out of sync because of Ryan adding stuff in the core, obviously. An example I just saw: #843: public function ___saveModuleConfigData($className, array $configData) { I'm sure there are more. OR: Ryan runs the generator before every commit =) There is a generator, right?

Funny, just yesterday I startet looking into yeoman, because I wanted to automate initializations of my projects in a more stable manner. Sure I have some shell scripts, aliases and functions set up to help me with that but, shell scripting is hell (at least for me, althoug I use zsh). Especially when it comes stuff other than copying and renaming files. Working with strings, numbers or templating ... yuk. I have not yet looked at Larry's generator in detail, but sure we can lear from it. I have yet to create my first real generator but I'd love to participate. I suggest that we collect ideas, what and how things should be done by the generator, and you @gebeer collect them in your original post. Off the top of my head I think it would be cool if module installations/or at least module downloading could be integrated somehow. Either by asking for the module name, and the generator then searches through the modules repo, or via config file. Can we event put that info in the package.json? I do think so. module installations renaming of the example files like htaccess and so on modifiying the htaccess via questions, that would require the htacces file to be in template form, so that directives can be included or excluded downloading of pw, asking for dev or master

Good point, have not thought of that. There should be an extra flag for the module info to specifiy the versions of the required modules. That would imply that modules should be provided in different versions, handled by ModulesManger perhaps. I think I might open an extra thread for that in the feature requests forum. Still, don't you see issues when another module uses Twig too? The only way to avoid issues would be to namespace the Twig classes. but thats extra work after each Twig update, right? I saw that a couple of minutes after my post and wanted to edit it today, you beat me to it. I'll look into that, looks promising.

I'm sure this is a great module, I haven't tested it but thanks for your work. I have two concerns with the module's approach though: 1. The Twig templating engine should be stand alone/a seperate module, which is not autoloaded. The TemplateTwigReplace module then should load the Engine and work with it, this way other modules can use the Twig Engine by loading the stand alone module as well without running into any issues. 2. warning: extensive use of the word "logic" =) I think the whole purpose of Twig is to sperate presentation from logic, so it should only be used for simple logic. Replacing the whole template system with Twig makes it necessary to write all logic (e.g. selecting data, merging data et al) in Twig templates which make them almost equally ugly as php templates with much logic in them. I think a better way would be to use regular php templates as controllers, have them do some heavy logic lifting and then pass data to Twig views which should only be concerned with outputting/formatting strings and iterate through loops and so on. PS: oh, and thanks, I was having problems with passed PW data to Twig so I looked at your code and discovered Page::$issetHas = true;. I then found out that Ryan implemented that feature after @porl had the same problems while coding his Twig module, so thanks to Ryan too =)

Thanks everfreecreative for that convenient function, I was fiddling around with that myself atm. Is is save to delete the template, fieldgroup and field to delete the whole thing or will there be any unused relational pairings left in the database?

Multilanguage is a great (and widely used, I guess) feature, Profile Export is a great (and widely used, I guess) feature, too bad we can't use both together. When will multilang export be supported?

I was trying to prevent a new creation of the role via: if(!$role = $this->roles->get('some-role')) { $role = new Role(); $role->name = 'some-role'; $role->save(); } But $this->roles->get returns a NullPage instead of null. $this->fieldgroups->get, $this->templates->get and $this->fields->get return null when not present. So in this case: $role = $this->roles->get('some-role'); if(!$role || $role instanceof NullPage) { $role = new Role(); $role->name = 'some-role'; $role->save(); } fixed it. I think all collection like classes should either return null or NullPage and not mixed results, right?

I successfully created a role with the API: $role = new Role(); $role->name = 'some-role'; $role->save(); It's now there under access/roles/ But when I want to get the role via API, I get a NullPage: $roles->get('some-role'); // or $this->roles->get('some-role'); Please help!

Perhaps this has come up already in this thread, haven't read it all, and I don't want to be a nay-sayer, but if it's primarily aimed at super users i.e. us devs, why have a GUI at all? Why not leave out the whole visual stuff and have HannaCode parse the text and search for template files (or template file in a subdir like templates/hanna) with the HannaCode name. [[my-hanna foo=bar]] looks for templates/hanna/my-hanna.php and passes the params like with any other regular template. This way we can edit our hanna-codes in our IDE or text editor of choice with all the highlighting and we can push it into version control, no need to fiddle around with exports or imports between installations. Am I missing something?

I had the same question last year =) https://processwire.com/talk/topic/3044-why-is-there-no-user-title/

Awesome, that fixed it, thanks!

Hi, I've just set up my AMP stack on my own rather than using MAMP and such, this is not as easy as I thought. Some obstacles I've overcome already but now this is biting me when trying to access a PW installation: Request exceeded the limit of 10 internal redirects due to probable configuration error. I've researched a bit but did not come to any conclusion other that it has to do something with rewrites. httpd.conf <Directory "/my-web-root/"> Options -Indexes +FollowSymLinks AllowOverride All DirectoryIndex index.php index.html Order allow,deny Allow from all </Directory> httpd-vhosts.conf example I am actually using dnsmasq to map my domains to directories like so: <VirtualHost *:80> VirtualDocumentRoot "/my-web-root/%1" ServerAlias *.dev UseCanonicalName Off </VirtualHost> But using this standard approach has the same issues: <VirtualHost *:80> VirtualDocumentRoot "/my-web-root/some-client" ServerName some-client.dev ServerAlias *.dev UseCanonicalName Off </VirtualHost> Any suggestions? Thanks!

Thanks for the reply ryan. I now use the new default theme with futura colors anyway.

When you want to help your clients to use the fields within a template, your descriptions might get quite extensive. I don't like the descriptions to clutter the whole edit page, it's confusing. So this little module adds buttons to all headers of fields that have descriptions, hides them by default and only shows them, if the questionmark is clicked. GitHub: https://github.com/owzim/PWPageEditDescriptionToggle Shots: Collapsed state: http://d.pr/i/EETH Expanded state, questionmark appears: http://d.pr/i/RBxr Expanded description state: http://d.pr/i/4fKw Let me know what you think. Cheers Christian