Leaderboard

@adrianmak Firstly it takes alot of effort in terms of time bandwidth to document it all next to the documentation that is already provided in the source code. Then it is difficult to have the documentation that is not in the code to be in sync with the 'changing' documentation. Then keep in mind that most 'advanced' users will look in the source code to find 'documentation' or figure out what is going on right there anyway without searching decoupled documentation. Documentation should be written by 'advanced' users, on the other hand, those users are likely to use the source code to lookup methods and stuff, so they are not the 'real users' of that decoupled documentation. Then there is the NOT fun part of documenting. In a lively environment as ProcessWire, new methods are added other methods become deprecated. It's hard to keep track of all those. I think we all wish documentation stays in sync and is complete. On the other-hand, when looking in the source code of ProcessWire you will recognise the effort Ryan takes to document and comment. I have to say, that the documentation in the code base is good and keeps getting better over time.

Many ProcessWire 2 modules will work in ProcessWire 3, thanks to the compiler. So, you code as 'normal' If you want a PW3-only module, just add namespace ProcessWire at the top of the module class There's some stuff that will only be supported in ProcessWire 3. If you want to leverage those and don't care about PW2, then go for 3 directly. Otherwise, if you have the resources and can support both, then go for two separate PW2 and PW3 modules. PW2 will still be around for a while .....but to PW3 we'll 'all'(?) go..eventually...so.. https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/

You are calling $sanitizer in the scope of a custom function. There you need to call it with wire("sanitizer")->pageName(), or, if you need it multiple times in your function: $sanitizer = wire("sanitizer"); and afterwards you can use $sanitizer->pageName(). This behaves the same with all PW template vars, like: $config, $pages, $templates, $sanitizer, $session, ...

Just a sidenote: https://processwire.com/api/variables/user/ and: http://cheatsheet.processwire.com/user/user-properties/user-pass/ And thanks to kongondo: http://kongondo.github.io/ProcessWireAPIGen/devns/class-ProcessWire.Password.html

Just like you're comparing it for the login: hash the "current password" and compare it with the database entry. But pw does have you covered: $user->pass->matches($inputPass);

It's not about the rel, but the parenthesis: https://processwire.com/api/selectors/#or-groups I just chose rel for "relationship", which is what you're dealing with.

Add a "X-Requested-With: XMLHttpRequest" header to the ajax call and $config->ajax will work.

Update: OpenShift already accept the quickstart

parent is not a field in the traditional sense, but a native field and might therefore function a bit different. You could try: rel=(parent=$page), rel=(secondary_category=$page), …

@jploch, It sounds like you have the same needs as @Christophe. I have been meaning to take care of this but haven't managed to get to it just yet. I am currently traveling (mostly vacation), so can't guarantee when I will get to this, but it would be good to get this done shortly and tune this up for official release in the modules directory.

<aside> </aside>

When you hook after, your event->return is your form I guess . $this->addHookAfter('ProcessPageAdd::buildForm', $this, 'intervene'); public function intervene(HookEvent $event) { $form = $event->return; $name = $form->getChildByName('_pw_page_name'); $name->set('value', 'tralala-my-ding-ding-dong'); }

$session->redirect('./?nocache=1', false); Add that GET variable in your cache settings. Alternatively use one time csrf tokens for double submit prevention: // For your form $name = $session->CSRF->getgetTokenName('contact'); $value = $session->CSRF->getSingleUseToken('contact'); // On submission, will throw after the first validation try{ $session->CSRF->validate('contact'); } catch (WireCSRFException $e) { // Double or invalid submit }

Pocketgrid is neither a framework nor a library, it's an approach.

It does: $mail = wireMail(); $mail->attachment($filename); // string $filename or array $filenames what means: you can add any single file path as a string with the attachment() method, or you can add multiple files at once with its pathes stored in an array. Everything else, e.g. how you submit your form and / or upload the files, does not belong to WireMailSmtp. For this, you may find information and examples on php.net.

Here are some of my findings in case anyone need it: // hook to before page add render and prevent execution if necessary $this->addHookBefore('ProcessPageAdd::execute', $this, 'hookUserAdd'); // hide add button in the backend menu $this->addHookAfter('ProcessUser::executeNavJSON', $this, 'hideUserMenu'); public function hideUserMenu($event) { //we don't want to modify links for super user if ($this->user->isSuperuser()) return; //ajax only if($this->config->ajax){ $options = json_decode($event->return, true); unset($options['add']); foreach ($options['list'] as $key => $value) { //check and unset if necessary } $event->return = json_encode($options); } } public function hookUserAdd($event) { if (!$this->user->isSuperuser()) { $event->replace = true; $this->error('You do not have permission'); return; } } That is because I still want "staff" role to use page-lister permission. Hooking to ProcessPageLister is much harder and require regex to hide the "Add new" buttons. Also, to modify the result returned from the selector, you can add hook to getSelector function (this is undocumented in Captain Hook) $this->addHookAfter('ProcessPageLister::getSelector', $this, 'hookPageListerSelector'); For better security, add hook to Pages::save (similar to ProcessPageAdd) to deny saving new user.

If you want to use this module with PW3.x (and only PW3.x), please pull branch feature/devns. It needs a bit more testing before I'll release it. first backup your installation after upgrading the module, go to module settings, have a look at the settings – you may have to adapt something Whats new: messages will be saved as pages instead of repeater items you have to define a parent page, all messages created will live under this parent the page name starts with the current timestamp, you could add additional fields which should be appended field selection: you can existing fields or fill in field names, after the module are saved, for each name a field will be created manage settings like field type, required, additional error checks for each field after the module settings are saved, all existing repeater items will be converted to pages no more template creation, ProcessWire API renders the form (you can adapt the markup) you may have to translate error and success messages Have a look at the latest readme to get more information. I would love to get some feedback

What @horst said. As a btw, if in a module, you also have the option of $this->sanitizer

Thanks, that solved it. I remember seeing that header in the jQuery request but haven't try adding manually. That's the corresponding part if anyone needs: request.setRequestHeader('X-Requested-With', 'XMLHttpRequest');

Hi, Since you wrote: "my internet speed is not very good" I thought we are talking about an online server, not your localhost. Xampp is running on your machine, so why should internet speed matter too much? Anyway, suhosin cannot be an issue in the case of running on Xampp. "but sometimes it is not working while I am updating the content" Can you please explain it in a bit more detail? Referring to images made me think you cannot upload them, but I'm not so sure. Can you please clarify?

I just created a quickstart of Processwire to OpenShift here: https://hub.openshift.com/quickstarts/229-processwire This will helps you get up and running quickly with a Processwire installation on OpenShift. The database credential will automatically use upon installation and the hook script will check if you already completed the installation and remove it upon building.

Well you don't really need to have specific email domains unless you expect to have incoming emails through Mailgun. If your main domain has MX records you can just have SPF and DKIM in your TXT entries. You just need to make sure your outgoing email uses the same domain as the one which is set in your email's "from". When on gmail/gapps with a custom domain for example, it's good to test reception on another domain since Google doesn't like being sent email to an email address "owned" by its own servers but not originating from it and will usually display the originating server as a security measure. It won't generally show on addresses on other domains. The reason it is that way is to prevent address spoofing, since the way email is architected, you can send any email from any server using any email address and nobody would know. As you understand that could have pretty bad consequences in different scenarios, which is why Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) exist. It might feel annoying and troublesome but in reality it's just good practice. Email is complicated.

I think what @benbyf wants to say that it is good to really understand CSS so that you don't have to rely on a grid system. CSS looks simple, but because it loose nature, the inheritance and browsers issues it's quite difficult.

@AndZyk I don't think that's a good idea, at least not the first solution I would go for. There's a very good reason PW blocks execution of 'foreign' .php files in that folder. I don't know about the lcmini.php script but I would first consider the following: Convert it to a template file Use an include from within a template file

Ok thanks to the link from Kongondo I followed: http://www.outsidethebracket.com/responsive-web-design-fluid-background-images/ and found the solution there: use padding-bottom and give it the following percentage: (height/width x 100) In my case I have it now like this: div#top{ background-image:url(banner4.png); background-repeat: no-repeat; width:100%; padding-bottom: 26.2793%; background-size: cover; background-position:center; } Background picture is showing up correctly and all responsive now

I'm also on current chrome (mac). I just noticed that I had to reload once yesterday before the content was displayed as xml and not text. Not sure why that happened. Scrap that. Logged in I'm getting application/xml. Logged out I'm also getting text.

I think you can just recreate it. Add a new child to admin with the title "Login" and for Process, choose "ProcessLogin" and hen hide it in the setting. See if that works. Never done it myself

You could use the email verification plugin (https://bitbucket.org/pwFoo/frontenduser/wiki/Documentation#markdown-header-register) or use PW hooks to add your own features (that's the way FrontendUser is built). https://bitbucket.org/pwFoo/frontenduser/wiki/Register%20extensions%20and%20plugins https://bitbucket.org/pwFoo/frontenduser/wiki/Login%20extensions%20and%20plugins Send an email after user registration just use the PW addHookAfter (PW hooks) the method FrontendUser::save to send an email with WireMail. All FrontendUser module messages should be translatable. For example ("$this->_()"): /** * Save the temp User object * @param User $user Temp User object to save * @return boolean Sucessful (true) saved or not (false) */ protected function ___save($user) { if (empty($user->name) || empty($user->email) || $user->pass->hash == '') { return $this->_('Register process unexpected failed!'); } if ($user->save()) { return true; } return $this->_('User registration failed!'); } Registered user won't logged in automatically, but you could add a hook to do it. addHookAfter FrontendUser::save and execute $this->session->login() or the FrontendUser method auth()

This module allows you and your site editors to protect a page (and optionally its children, grandchildren etc) from guest access directly from the page's Settings tab. You can also limit access to certain roles. http://modules.processwire.com/modules/page-protector/ https://github.com/adrianbj/PageProtector It makes it very easy for editors to set up various password protected areas on their site, or to simply protect a new page or section while they are still working on it. Ability for your site editors to control the user access to pages directly from Settings tab of each page Include whether to protect all children of this page or not Optionally allow access to only specified roles Option to protect all hidden pages (and optionally their children) Ability to change the message on the login page to make it specific to this page Option to have login form and prohibited message injected into a custom template Access to the "Protect this Page" settings panel is controlled by the "page-edit-protected" permission Table in the module config settings that lists the details all of the protected pages Shortcut to protect entire site with one click In addition to the admin interface, you can also set protection settings via the API: // all optional, except "page_protected", which must be set to true/false // if setting it to false, the other options are not relevant $options = array( "page_protected" => true, "children_protected" => true, "allowed_roles" => array("role1", "role2"), "message_override" => "My custom login message", "prohibited_message" => "My custom prohibited access message" ); $page->protect($options); As alway, I would love any feedback / suggestions for improvements. Hope you find it useful! Page Protection Settings (settings tab for each page) Module Config Settings

Thanks for the report @tpr and for the solution @LostKobrakai. Sorry, I am on the road at the moment (mostly vacation) and so my response time could be several days. It sounds like you have everything working as needed at the moment, but let me know if you think that perhaps Tracy needs to handle this better. Not the same thing I know, but the latest version of Tracy (the core project) now provides details on ajax requests - might be coming soon to this module, but there is a PHP 5.4.4 requirement, so might have to wait until PW drops 5.3 support.

Hmm, not sure why the module might not be loading. Did Martijn's suggestion help? If not, does it start working if you manually force your module to be loaded by adding a site/init.php file to your site and putting something like this in it... <?php $my_module = wire('modules')->get('HookPageAdd'); ..?

Netcarver, Good idea to put die() in init. Made no difference. So now the question is why did my module not get loaded? But you're off track in the other comment. The buildForm() method is called. Aside from messages in the log from ProcessPageAdd before and after calling it (see last of the code snippets), the next thing I see on the screen is the form.

If that test works, it could be that you are trying to add a child to a page who's template only allows children with a fixed template and for which a child naming policy is defined. If that is the case, the initial add form you are hooking is not even called (and, therefore, your hook won't get called) as PW will do a 'quick add' and use the only permitted template for the child and the defined naming policy. (PW source code) Hope that helps! Edited to add: From your OP it sounds like the build form is being shown, so this is probably not the case.

I could not make use of $this->wire('variableName', $obj); in my template files either, because as bernhard has pointed out, it is not possible to modify the variable. So I ended up using this: use ArrayObject; $sbs_globalData = array( 'block_counter' => 1, ); $sbs_globalArrayObject = new ArrayObject($sbs_globalData, ArrayObject::ARRAY_AS_PROPS); $config->sbs_globals = $sbs_globalArrayObject; However, I am also interested in utilizing WireArray instead.

CSRF doesn't work with a cached form. The PRG post rdirect get is the best design pattern to prevent double submission in case of a refresh or going back in browser.

OK thanks Horst. I did start to use it this way, but was unsure about the other aspects and if more was included. I don't have a problem with the validation/sanitising routines per se. So thank you.

Hello, Looking to start making modules (and then writing about the adventure) but I just wanted to check whether there were many differences between PW2 and PW3 module creation and whether I'll have to pick a camp to start with? Thanks

What exactly is the problem? If you may do a redirect after form processing, the post var is lost.

Thanks both - this now works sweetly.

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP/1.1 200 OK Date: Thu, 24 Mar 2016 01:50:48 GMT Content-Type: text/html; charset=UTF-8

Thanks for pointing it out gRegor! I could say it was late, but it wasn't. On topic: Content-Type: text/html for me as well.

Thanks, arjen. I'm referring to the processwire.com blog, not my own install.

admin.php works just fine as well if the hook should really only run on admin pages.

@netcarver You're right, I'll tidy up my code and post it along with more detail.

Ah, you're using MAMP (Pro?). Try the following: * Main window › MySQL, tick checkbox "Allow network access" (I got the German version of MAMP, don't know the proper translation), restart. * In ProcessWire's /site/config.php, replace localhost with 127.0.0.1 This is also an issue I found while working on wireshell with that particular MAMP set up.

It occurred to me that a good addition to the forums would be some way for PW users to indicate support for a module idea. Similar to the Wishlist subforum but for functionality that belongs in a module rather than in the core. I'm thinking mainly of commercial modules, although if someone wanted to take up a module request and release it freely that would be cool. So users could propose a module idea, then others would vote for it (using likes or some special voting option) so that a vote means "I'd buy that", with the expectation of pricing in the general ballpark of Ryan's pro modules and Apeisa's PadLoper. As a beginner-intermediate developer I'm really enjoying working with PW and learning as I go - the API is so intuitive that I've been able to build my own solutions to things that in another CMS I would have been reliant on someone else's module to achieve. But there are things that I know are beyond my current skills, and for those things I look to third-party modules. My clients are non-profits and small businesses so I'm never likely to have the budget to commission a custom module alone. But there might be other PW users out there with similar needs and maybe that demand would make it worthwhile for an experienced developer to take on a proposal and release it as a commercial module. Currently there isn't a way to measure the demand for modules apart from occasional forum posts like "Is there a module that...?" Any thoughts on this? Here's a module request to start off with: I would be happy to buy a full-featured event calendar module. I've searched the module directory and the forums and Lindquist's module is the most feature-rich I've seen, but it's in an alpha proof-of-concept state and some important functions aren't implemented. Features I would be looking for are: Calendar grid interface in admin, allowing for easy addition and editing of events. (Nice but non-essential) Week and day views in admin, in addition to month view, with drag editing for event date and duration (I'm dreaming of something awesome like the dhtmlxScheduler interface or Fullcalendar interface). Although drag operations would really need an undo to correct accidental edits, so this may be more trouble than it's worth. Events are edited in a modal window, to avoid losing one's place in the calendar. Recurring events, with user-friendly selection of recurrence options. The ability to individually edit or remove an event that is a child of a recurring event (i.e. make an exception for that individual event). (Nice but non-essential) A couple of out-of-the-box minimal rendering options for the frontend (read-only calendar view, list view). This is the kind of module I need frequently. I've been lucky that I haven't had a client request a full event calendar since I've been using PW, but it's only a matter of time. I'm sure there are other PW users who need this and who would, like me, be happy to pay for such a module.

outputformatting is always off when bootstrapping pw so your file-fields will always return arrays no matter what the setting in the admin is ps: yeah - the once in a lifetime moment when adrian has already posted a reply and i added (little) additional value with my answer. i will print that post and hang it up in my living room

I hate bumping really old topics, but since I've recently been looking at responsive images with regard to a central focal point, and this was the only topic that came up in a search (that I could tell was directly related), I thought I'd chime in and mention that there's a jQuery resource for defining a focal point when using various dimension based images in a responsive image layout. https://github.com/jonom/jquery-focuspoint I haven't looked closely enough (yet) on how best to possibly integrate this without requiring custom code in the templates, but it looks like a similar solution to the PHP-based solution offered here (and possibly more efficient overall). Below is an example of the script in action: http://jonom.github.io/jquery-focuspoint/demos/grid/lizard.html My buddy, the developer behind Statamic, built this (but customized) in to his CMS' control panel and his demo of it was awesome. It made me jealous that PW didn't have it, so the first step I did was to figure out which script he based it off of. So far I've only completed Step 1.

Steve, is there a special reason for making the directory hidden? DOH! Guessing this is 'cos it hides it from HTTP

While the data import may be the hardest part of this, it's probably also going to be a lot simpler than you think. If you can get the data you need to import into some standard format (like CSV, JSON, XML, etc.) then you'll have no problem getting it into PW. Here's a really simple example of importing a CSV that has has fields for 'title' and 'body': <?php $fp = fopen("data.csv", "r"); $parent = $pages->get("/path/to/parent/"); $template = $templates->get("some-template"); while(($data = fgetcsv($fp)) !== false) { $page = new Page(); $page->parent = $parent; $page->template = $template; $page->title = $data[0]; $page->name = $data[0]; $page->body = $data[1]; $page->save(); } When the time comes, just post some details about what you are doing and we can get you started.