LostKobrakai

Sadly there's no documentation about the progression of functions there's only this http://processwire.com/api/hooks/captain-hook/ to find hookable functions. But often the hooks are quite declarative. You want your error handling to happen when a page is saved => Page::save. Another example, when a new Page is added to the tree => Pages::add and so on. Your example of Page::render or InputfieldTextarea::render does not make sense for error handling, as this functions only generate markup. Also it's called if someone opens the page, to late for useful error handling, as the user has to reopen the page, before getting the errors.

I've to add a few things here. In your other thread we where talking about denying the page creating and your idea now is hiding the button upfront. Both ways to solve your problem should be not that different to implement, as both need just hooks to work. Now, after writing the post, came this to my mind: InputfieldPageTable::render is only called on, big surprise, page render. So in your usecase, this wouldn't be great, because the limit of pages in your pagetable has to work even if the user doesn't leave the page. So I still think that my suggestion of using Pages::add would be more useful, even if it's a little bit less userfriendly, because the add button will throw an error, instead of simply disappearing. An addition to adrians post: You put your hook in the init.php in the template folder? If so, it can't work because this file is only called if your browsing the frontend. You need your hook to work in the backend. While you can use hooks in template files, we don't change the core admin template files. So the best way to get your hook into the backend is via a small module, like the one adrian posted. This example code with the docs about hooks and modules here on processwire.com should get you at least somewhere. What's missing in the code of adrian, is a condition, when to remove the "add" button. I would limit the check for players / positions to the right template or the right field in the hook and only then do the checkup.

If you change the stored value of the textfield, it is of course loaded this way the next time in the backend. Dynamic transformation is done by textformatters. To accomplish your needs you could implement the evaluation and the replacement seperately. The textformatter for replacement and a hook into page::save() to check for missing / trashed IDs.

Thanks for you inputs, I'll see how detailed / typographically perfect their invoice should be and then decide further.

This will be super useful for me, to easily double-check things while answering stuff on the forums.

This should be doable, but you need to hook into the pagecreation and if it's the "lineup" template, check if there are players/positions left for the current parent page. I don't know how much you know about hooks, but this should provide a good introduction: http://processwire.com/api/hooks/. This should be the needed function to hook: https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/Pages.php#L428

@ netcarver What I actually meant is that I would prefere a way, where a external created base pdf is altered by the code instead of recreating the whole file.

Thanks for your input, but I don't see how these should help me generating a pdf?

Hi there, a client of me asked, if it would be possible to automatically generate a pdf invoice after someone ordered something on their simple online shop (no online payment). Does someone know a simple way to accomplish this. The best would be to have some kind of pattern file where just some variables get changed.

With you declaring yourself as pw noob I would strongly suggest, to give pagetables another try as this would be the far easier solution. From your post I assume that you're using the FieldtypeSelect module right now. This is a easy to begin fieldtype, but not very flexible. In your case you've to use the Page fieldtype. This is a type where you save a reference to the choosen page. This fieldtype can also be displayed as a select box, but also provides other input solutions. The setup I would suggest would be: Page Setup: - Positions - … - Players - … - Games - Game 1 (game) - Line-Up Player 1 (lineup) - Line-Up Player 2 Template: lineup This template holds at least the first two fields below. With a custom naming convention you can define, you prevent the need of defining a custom name each time you add a page of this template. Fields: player PageField Here you can use the "custom php code for selectable pages" which is a option for that fieldtype: $players = $pages->find("template=PLAYERTEMPLATE"); // All Players $other_lineups = $page->parent->children; // All other Subpages, where Players are already choosen // $page is one of the subpages, therefore the parent selector part foreach($other_lineups as $lineup){ $players->remove($lineup->player); // Remove unavailable Players } return $players; // Return the adjusted selection position PageField Also use the custom php code, and just adapt my previous example for positions. lineup PageTable This pagetable is viewed in the game-template and let's you generate the lineup template, which should be used for the subpages of a game. The PageTable can show player.title and position.title in it's shown table, so you do have an overview in the game template, without the need to look into every subpage. With this setup everytime you add a new lineup subpage to a game, it removes already used positions and players from the fields.

I would still describe this as manual updating. Git hooks provide a fully automated way to get the lastest commited files from git to your server.

To take diogos thought further. Replacing the repeater with a pageTable and using a page fieldtype with the "custom php code for selectable pages" option on the subpages should work.

You need to read the installation instructions provided with the module. More exactly this isn't a module but a site-profile. These can't be installed and uninstalled like normal modules. They have to be present before the processwire installation process. See here: http://modules.processwire.com/modules/process-wire-bootstrap3/

Then you most likely need to write a own inputfield and/or whole fieldtype, as the only dependency current fieldtypes provide against other fields are dynamic required state and dynamic visibility. Edit: Another, less sophisticated, answer could also be to hook into page-save, check there if the requirements are met and just error if there are duplicate entries.

Do you need this to work on the frontend or in the admin part of processwire. On the frontend you can just use javascript to disable already selected players / positions and check on the backend, if nothing has gone wrong, before saving it. If you want to use the backend of processwire I think you've to build a custom InputfieldPage module, which does the job of disabling parts of the selectboxes to make positions / players unique to one game.

Either throttle by IP or not. There's no intelligent filter, which can determine, if the current IP want to harm your site. If you still want to deny a mass bombing you could maybe duplicate/fork the SessionLoginThrottle module and only use this second module to filter by IP, but set the limit higher. It won't block some false remembered passwords from company clerks that way, but blocks mass spam attacks.

@Juergen You can change this behavior in the module's settings.

Yeah, it's certainly more error prove. Most of my sites have to be filled with the final content, before they go live and that's not my job to do that. So the subdomain options is quite convenient.

Which version of processwire do you run? If you use the 2.4.x dev version instead of the stable version you could replace the Repeater field with a PageTable field, which produces real pages, instead of the hidden ones that repeaters use. There would also be the option to buy the ProFields package in the store and use the ProTable field or the Multiplier Field. While this shouldn't be necessary, I've added these just for the completeness. Regarding the save issue, I can't help you, but I think that 150 is a quite odd number, this should be able to handle more. But I'm no expert, just wait for an more experienced answer about that.

@Martijn Geerts Ok, the Markup generated by WYSIWYG fields wasn't on my radar, but at least all images and urls added with the processwire specific plugins produce relative urls. Stylesheets also do work with relative urls. For javascript just add this line to make it work, if you really need a full url. <script ...> var host = <?php echo $config->httpHost; ?>; </script>

You can customize the wrapper code for the whole form, which is described here: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/?p=39436 To add a class to one field use this: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/?p=39375 To learn a lot more about the form api, read the whole thread What I want to know, if there's a way to only change the wrapper for a single field instead of the whole form.

Git Hooks and a php file on the server that inits the git pull on calling. So it always stays in sync with your git server version. The database has to be updated manually, at least if you want to keep it simple, but that has to be done with a ftp server as well.

I don't know the module, but 'selector' => '', 'selector_field' => 'nav_selector' should be your friend in setting the parent, if I understand it right.

That's correct, the full syntax would be: data: { country: $("#country").val(), province: $("#province").val() }

This would be: $subpages = $page->children;