gRegor

After more digging and experimenting, I found the functionality I was looking for is (a bit un-intuitively) in the PageRender module. There's methods in there that hook into Pages::save, get the CacheFile for the page, and clear it. Since the method clearCacheFile() is a hook call and not intended to be called directly, I ended up doing this in my module after saving fields: $PageRender = $this->wire('modules')->get('PageRender'); $cf = $PageRender->getCacheFile($page); if ( $cf->exists() ) { $cf->remove(); } Some of my earlier experimentation was calling $this->wire('cache')->maintenance(), but I realized that's WireCache which is different than the cached files created for pages.

Thanks, @kongondo! I'd not seen those new reference pages.

I was hoping for more explanation of quiet saving instead of just experimentation. I did just experiment though and it doesn't seem to clear the cache. It sounds like it's a bug based on that and Jan's report; I'll dig into core code.

Bumping in case this was missed during forum upgrade.

I'm using "quiet" saving in the Webmention module and was wondering if that prevents the page's cache from being cleared. I'm just using the built-in page caching with the option "Clear cache for saved page only (default)" If it matters, the page-save I'm calling is specifying the Webmention Field, rather than just $page->save(); For reference, the code is https://github.com/gRegorLove/ProcessWire-Webmention/blob/master/Webmention/Webmention.module#L840

I'd recommend using prepared statements. ProcessWire's database class extends mysqli, so you can do: $statement = $this->database->prepare('INSERT INTO tablename (Comments) VALUES (?)'); $result = $statement->execute(array($comment)); (This is written off the top of my head, not tested)

Version 1.1.2 is released: http://mods.pw/BC - Updated packaged php-mf2 library to version 0.3.0 - Added config option to automatically monitor a page for approved vouch domains (see below). - Better authorship algorithm support. One of the bottlenecks for the Vouch protocol is "how do you easily manage the list of domains you will accept a vouch from?" In the 1.1.0 release, it was just a text field that you had to manually enter each domain into. As of version 1.1.1, there is a new config field “Vouch whitelist URL.” You can enter the URL of your blogroll or other whitelist. It will be monitored once a day and new domains will be added to the list of approved vouch domains. Links must use the h-card microformat. No domains will be removed from the approved vouch domains. This should help automate the approved vouch domains list. I'm trying this out on my own site currently: http://gregorlove.com/following/ If you're using this plugin, I'd love to hear from you! Feel free to send webmentions to this post: http://gregorlove.com/2016/02/quite-pleased-to-officially-release/

Confirmed in current Chrome and Firefox that it's Content-Type: text/html; charset=UTF-8. Accept: header has application/xml in both.

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

The blog RSS feed is delivered as content-type text/html instead of text/xml. It would probably be worthwhile to add it as a link rel alternate on the blog page, too, for discovery. While on the topic, a full-text feed would be nice, and even better if there were h-entry microformats added.

As you develop this, you might consider adding a honeypot field as a first test. I've just set up a custom commenting system on my site and included an extra text input that's hidden with CSS. Most spambots will just fill in all fields and submit the form, so if the extra form field has any text in it, I log it as spam and don't add the comment. The extra text input has a placeholder of "You probably should not fill this in" just in case a human has CSS disabled and sees the field. This is only a first spam test, but it will block quite a few attempts before you need to test IP addresses, blocklists, Akismet, etc.

Yeah, it is probably pretty niche, but it can be very handy if you want to implement something like OAuth or OpenID without all the heavy lifting those entail. My immediate use case is that it's easier for me to log in to my site on mobile by just entering my domain now. On http://indiewebcamp.com it's used as the authentication mechanism for the wiki. It's worked great there to prevent spam accounts/wiki edits.

https://github.com/gRegorLove/ProcessWire-IndieAuth This module allow users to sign in to your site using IndieAuth: IndieAuth is a way to use your own domain name to sign in to websites. It works by linking your website to one or more authentication providers such as Twitter or Google, then entering your domain name in the login form on websites that support IndieAuth. This module has two different functions: IndieAuth Authentication After a user enters their domain name and successfully authenticates, they will be redirected back to your site and the session variable indieauth_domain will be set. You can then use this session variable to customize your site for the user or offer additional functionality. Note: The user is not logged in to ProcessWire at this point. ProcessWire Authentication If you would like to allow users to log in to ProcessWire using IndieAuth, you will need to make a few changes to the user profile. Add a field named website Add that field to the user template Update the User Profile module to make the website field user-editable The user will need to set their domain name in their user profile before they can log in with IndieAuth. Setup After installing the module, copy the template file extra/templates/indieauth.php into your site/templates/ directory. In the admin area, add the new indieauth template. On the "URLs" tab for the template, check "HTTPS only." Create and publish a new ProcessWire page using this template, e.g. https://example.com/auth/ The included template is a minimal, sample template that covers both of the functionalities described above. You can expand the template or integrate it into your existing templates as needed. For more information about the sign-in form and how the verification works, please refer to https://indieauth.com/developers Notes This module does not create user records if they do not exist already.

Ah, did not realize that. Good to know. A shortcut findIDs() method in Pages.php seems like a good idea to add.

PageFinder has a findIDs() method that sets the returnVerbose attribute. It doesn't set loadPages attribute, but I presume when returnVerbose is off it automatically does not return pages. Untested, but this should work: (Oops. Doesn't work. See below.) $pages->findIDs($selector);

What's your use-case for passing a path to jQuery like that, or was it a made up example? base64 enc/de-coding shouldn't be necessary if you're using the get parameters. It might be easier to just pass in the script name "jquery-2.2.0.js" and use $config to build the URLs to the file, though.

Thanks for those links. I understand better now that getMatchQuery() is used for searching subfields in pages. That function in my fieldtype is adapted from the Comments module and is working as expected. I realized the find() method is for searching the webmention fields outside of a $page context, i.e. in the Webmentions Manager (also adapted from the Comments module). I ended up adding a find() method to my main Webmention module that finds the first FieldtypeWebmention and calls its find() method directly, so I can call $Webmention->find('author_email=user@example.com') and get the WebmentionArray I want.

If I'm understanding you correctly, I think you can use $this->input->urlSegment1 (2, 3, and so on). within your ___execute* method. I don't think you'd have to worry about any encoding or decoding.

Thanks, that is useful. I had not thought about WebmentionArray. I did some more testing last night and $page->Webmention->find('author_email=user@example.com') did actually work, for searching within the field on a specific page. I also got $pages->find('Webmentions.author_email=user@example.com') to work, regardless of the functions I mentioned. I guess I thought I had to implement some "find" functionality, but it's actually inherited from WireArray. I should be more clear with my desired use-case: I need a simple boolean check whether someone has sent a webmention previously or not. I was thinking I'd do that by searching, getting a WebmentionArray of results, then using the count() method to see if there's 0 or 1+. I could achieve the same results with the $pages->find selector above, but perhaps there is an even more direct way (short of writing a direct SQL query)?

Solved below I'm wondering how to properly implement a find() method for a Fieldtype so it can be used in an API-y way. When I set up the FieldtypeWebmentions I used FieldtypeComment as a basis. It includes a find() method, which I'm not entirely sure I understand, or is even what I need. What I want to do (from elsewhere in my code) is perform a search across the webmention field for a certain author email, like: $page->Webmention->find('author_email=user@example.com'); I've looked at http://processwire.com/api/modules/ and the Fieldtype Map Marker as an example, but it is still a bit opaque to me what the Right Way™ is. Is it actually the getMatchQuery() method I need to implement? Thanks for any help!

Fixed as of v1.1.1: I caught (and filed) a bug to be fixed: if you use the Webmentions Manager to try to manually process/delete a received webmention, it does not work currently. This doesn't affect the automatic processing, if you have that enabled, or manually processing from the page that received the webmention. Do feel free to try it out by sending a webmention to this post on my site: http://gregorlove.com/2016/02/quite-pleased-to-officially-release/

Officially in the module directory! http://modules.processwire.com/modules/webmention/

Version 1.1.0 is now released. It's been submitted to the module directory so should appear there soon. In the meantime, it's available on GitHub: https://github.com/gRegorLove/ProcessWire-Webmention. Please refer to the updated README there and let me know if you have any questions!

Excellent! Thanks.

I've set up a Process module that displays various views in the admin area. The contents of these views are built in the ___execute* functions, but I was wondering if anyone has any recommended practices for separating out the view "templates" into separate files. I suppose I could just put template files in the module's directory and require() them from the function calls, but wasn't sure if there's a better / more ProcessWire-y way to do it.