LostKobrakai

I think there's no real specialized documentation about saving files from the api, but it's the same api as for pages and images. They all inherit their functions from WireArray / WireData which are kinda key components of most processwire fieldtypes. OutputFormating is exactly what it tells you to be. It changes the way output is presented to you. If it's off you'll get raw database data. E.g. for a page field this would be the id. If it's on you'll get not only the id but the whole page object of this page. Regarding this "harsh" error. Yeah it has to be this way, as you cannot save anything with outputformatting on. Not being able to save is pretty important stuff for a cms, which requires a hefty error.

I just viewed the video of the mentioned drupal module and I can see, that this would be useful for the client, because his workflow doesn't have to change. Also using only a single database instead of some kind of mirroring is nice, too. If you want to do this the most flexible way, you could do a set of extended Fieldtypes (text/date/image, what filemaker offers) based on the core ones. But you'll change the methods which interact with the database, like sleep- and wakeupValue and so on. I don't know how complex this would be, but you would get kinda nativ processwire objects out of it. The less elaborate version would be just 3 new fieldtypes, Fieldgroup, Field and Portal. If I understand it the right way, there's really not more about this databases.

You do get the page object right away from the field. So this is enough. echo $page->author->title;

It's not really in the dev branch. It's still an extra module to install by now even though it looks like it would be in the core if one just reads over the first lines. That's what confused me about it, because I thought I would have noticed it sometimes as a core module.

Oh, that's where I read about it. Somehow I thought this would become part of the core and therefore I thought it would be not ready yet.

The just isn't a global configuration gui in ProcessWire right now. (Read below) But it shouldn't be hard to just pack all those $config variables in a module with some forms. I think to remember that Ryan some time ago said it's this way so /site/config.php doesn't have to be writeable or something like that.

I've a feature request. As I can assign users of ProcessWire the right to view/list hanna codes it would be nice to be able to incorporate a description field, where I can add small explanations for each code. This way the list/view permission would be more useful on it's own. This could maybe later be incorporated in something like a small dropdown underneath hanna code textfields.

I've guessed for that reason, but it's still a bit cluncy and with all of those great redirecting modules out here, it shouldn't be a great issue. Even after some time of using ProcessWire I'm still using the api sites on a daily basis. Only with my recent dive into module developement for pw I switched more and more to just look at the code on github / locally. But until you've interalised the modularity and oop priciples I think it's impossible to find answers there.

Yeah, that's what it's meant for. Or at least for single instances of using append / prepend.

/** * Prepend template file * * PHP file in /site/templates/ that will be loaded before each page's template file. * * #notes Example: _init.php * @var string * */ $config->prependTemplateFile = ''; /** * Append template file * * PHP file in /site/templates/ that will be loaded after each page's template file. * * #notes Example: _main.php * @var string * */ $config->appendTemplateFile = ''; Additionally there are settings about changing / preventing these configs in the template edit section.

I can relate to that. What bugs me often are the arbitrary jumps from http://processwire.com/docs/ to http://processwire.com/api/. The sidebar is so similar I don't think anyone even noticing these the first time. And in /api/ are so many hidden informations, which serve for a great baseline understanding of processwire, it's a pity they are so hidden. About your FieldtypePage issue: $pagefield = $page->related; // Objects are passed as reference // so this is the same as $page->related->add() $pagefield->add( $pages->get("id=1234") ); $page->of(false); $page->save();

I've a small question, too. Does FormBuilder include client-side validation? Edit: Another one came up. Is there any kind of field interaction, like showIf or multiple select boxes, which depend on the respective predecessor.

Updated the module to incorporate an icon and settings to enable system templates, which are now hidden by default.

Do you mean output in general or outputting infos from repeaters and/or pagetables?

I did think about this, but wanted to avoid confusion with Permissions itself. This would be more about "template access" but it would be kinda long with "overview" appended to it. You can change the visible roles in the modules settings. The guest user was not so useful for me, as only the viewable tab would be from use. All the others can't be assigned to the guest role. I did this, too, because I have used roles before to differ between different frontend-only user groups, so these roles could be excluded as well. Edit: Added the info about the settings in the intro post as well.

I just wanted to start a discussion about issues and pull request in the github repo of ProcessWire. I know that Ryan is the one really responsible about this, but I wanted to know if others think like me, before approaching him. So to the topic. The repo has currently ~250 open issues and ~35 pull requests. For someone checking out on ProcessWire this could lead to the assumption, that there's lots of stuff broken and there are even people trying to fix stuff, but the pull requests are just abandoned. Now I know that Ryan is really trying to keep stuff structured with extensive tagging, but I think it would be great to have some kind of settled timeline in which issues/pr's will be closed. E.g. fixed issues after one or two weeks, discussions after four weeks after the last activity. I would think, it could improve the image of this stable cms, while keeping the issues directory clean and current. With Ryans tags even closed issues are still quite nicely to sort out and these can be reopened at anytime anyways.

I did another quick module, which plugs something I always kinda missed in ProcessWire. It's just a raw overview over the access management from the templates. Nothing fancy, but useful. The visible roles and the visibility of system templats can be setup in the modules settings. I'll add this to the modules directory later. But for now it would be great to hear if anyone is missing anything or if someone does have a better idea how to name the module. 12.03.15: Renamed the module and fixed wrong information for superusers and inherited rights from the required guest role. GitHub: https://github.com/LostKobrakai/ProcessAccessOverview

The module part I mentioned would onyl be there to add your extra javascript automatically, but that's kinda unimportant in the beginning. For the php part you could leverage the processInput() function of CommentForm.php. I'm currently just not sure how to correctly call it, so that it's adding to the right page / comments field. Maybe someone else could help you there. But mostly you'd need to take care of the AJAX stuff by yourself.

So it seems the culpit is somewhere in the foreach loop, which is not what I expected Did you try the ultra failsave of using concatination instead of curly braces and single quotes for the class? I really don't see an error, but just to try it. Maybe var_dump $teams / $team inside of the loop, so check if something is messing with them.

Just take a look a the form. cite, email, website, text & submit are the visible fields. Maybe there are some hidden ones, too. To submit a comment just send all those datapoints back to the current site as POST data. The easiest way to have this done by default would be a hooking module with a new javascript file. The hook would then append this js file on something like CommentForm::render(). But you would need to include $config->scripts, in your frontend templates. But keep in mind, that it's not only about submiting a comment. Normally this also includes displaying the new comment, which may in itself have consequences for some kind of pagination. So there's a little bit to think about.

Does it show "It' s 1 teams." ? Or does it even show this line? I'm just curious if the culpit is somehow in the foreach loop or earlier in loading $teams.

There shouldn't be a need to change $event->return, as you're hooking before the function not after it. Also you don't want to replace the returned markup of InputfieldSelector::render. The option is correctly set, but it's not working for me, too.

One thing I noticed, I think there should be a space after "echo". Also I'm personally not keen on multiline strings. I don't trust them to work. I've also added a test for how much teams are really found, which is what I would check first. If there are multiple teams found, but only one is displayed you can say for sure somethings wrong with your snippet. <?php $teams = $pages->find("template=team_member,limit=10"); // Just for debug purposes echo "It's ".count($teams)." teams."; $out = ""; foreach ($teams as $team) { $out .= "<div class=\"team-wrapper\">"; $out .= "<h2>{$team->title}</h2>"; $out .= "<h3>{$team->team_role}</h3>"; $out .= $team->body; $out .= "</div>"; } echo $out; ?>

I'm currently finalising a site for a local architecture agency. Not really fancy from the backend point, but it's the first time I did templating with mustache in the backend and on the client side. There is also a site for a former college lecturer of me, who works mainly as a coach. But it's currently on hold, as she's busy with projects.

As written a few posts above: In contrast to the new croppableimage module, thumbnails' getThumb() does not return a new image object, but only the url, so there's no need to call ->url on it. Enabling debug mode should even throw an error on this one.