gRegor

I'm working on a PW 3.x version of the module in this branch: https://github.com/gRegorLove/ProcessWire-Webmention/tree/master-pw3. It's in beta currently; it should generally work, but if you run into any problems, let me know. Also, I realized it was not obvious that the webmention endpoint requires a template file in order for this plugin to work. Otherwise the endpoint would return 404 to any requests. I've added a sample template file here and info in the README: https://github.com/gRegorLove/ProcessWire-Webmention/blob/master/Webmention/extras/site/templates/webmention-endpoint.php I hope to release 1.1.4 soon along with an official PW3 version.

I'm running into this too, with my Webmentions module on a fresh install (the FieldTypeWebmention I based a lot on this comments module). Best I can tell, the issue seems to be that when you add a field, getDatabaseSchema is called for the first time. Since there is no $field->schemaVersion set at that point, it tries to run the first ALTER TABLE query before the field's table has been created. Update: I think I've found a solution. In getDatabaseSchema I first set a boolean: $table_exists = in_array($field->getTable(), $this->database->getTables()); Then any schema upgrades can be inside an if/else conditional: if ( $table_exists ) { # update to schema version 1 if ( $current_schema_version < 1 ) { # perform schema updates } } else { $field->schemaVersion = self::SCHEMA_VERSION; $field->save(); } I'm also tracking the current schema version in the class constant SCHEMA_VERSION. Hopefully this helps other developers. Feedback is welcome!

FYI: I noticed when I was updating my Webmention plugin in the directory last night that 2.8 wasn't an option under compatibility.

Version 1.1.3 is out: http://modules.processwire.com/modules/webmention/ Fixed fatal error on install (thanks @Jason Huck!) Improved validation of source, target, and vouch parameters Enabled sending webmentions to links that have been removed from a post Added hookable methods for image caching Fixed handling of HTTP 410 Gone responses This works on version 2.6, 2.7, and 2.8. It does not work on on 3.x yet. I'll make a branch with a 3.x compatible version soon, though. As usual, if you're using this plugin I'd love to hear from you. Feel free to send webmentions to this post: https://gregorlove.com/2017/03/webmention-for-processwire-update/

@Jason Huck So sorry for the delay in reply. I somehow missed the notifications for responses here. Are you still experiencing the problems on 2.7 or 2.8? I will try doing some fresh installs on those as well as 3.x. It's not explicitly set up for 3.x yet, but it should be easy for me to add the namespaces and have a 3.x-ready version.

Just wanted to share what I ended up doing. After a lot of digging and various attempts (see github), I gave up on having the documentation sub-pages show up in the sidebar. That means I was able to move the documentation pages elsewhere. I've been in the habit of having a page Backend Tools which doesn't have a template (so not available to the public) and store groups of pages there for things like Page-select options. I added a sub-page there Documentation Pages which allows children with template Documentation. The Documentation template just has a title and body field. Then in my ProcessDocumentation module, the ___execute() method shows a list of all the Documentation pages, linking to them with the format: ./view/[page-name]. Then the __executeView() method verifies the page-name is valid and if so, returns the documentation page's body field, so it shows up in the admin theme. There's still a link to the main documentation page in the sidebar, which I think is good enough. Voila.

I realized that's possible, but hadn't considered it much as an option. Since the documentation we're setting up is for doing specific tasks in the admin area, it seems a bit clunky to send them to a front-end page and then they have to return to the admin. I appreciate the idea, though!

Bump. Any ideas on this? I've now tried setting up the documentation.php template file with: $page->process = 'ProcessDocumentation'; require($config->paths->adminTemplates . 'controller.php'); Based on admin.php, I would expect this to display the page contents in the default admin theme (Reno), but alas, it displays it in the legacy frontend layout (edit: the "skyscrapers" demo, though the navigation is all of the admin links). I've tried setting $config->defaultAdminTheme = 'AdminThemeReno'; in config.php but still no dice. I'm baffled at this point. This is in PW 2.7.2 Edit edit: Alright after digging more, upgrading to 2.8.35, and digging even further, I feel pretty confident this is a bug, so I opened an issue.

Good suggestion. That works to make the collapsible sidebar work in Reno, but when I click on one of the documentation pages I get a blank page. I guess the documentation template doesn't execute the parent page's Process, so the execute method doesn't get called? Is there any way to achieve this without needing to assign a Process to each documentation page?

This is kind of a theme-related question (Reno), but also a Process module question, so posting it here. I have a Process module I use to display new menu items in the left sidebar (Reno theme) for documentation. I handle displaying the documentation content through the module's ___execute and ___executeView methods, so I don't have a template file. The problem I'm running into is that the theme checks viewable() (reference) on each child page, and since there's no template file, none of the child pages get listed in the sidebar. I'm wondering if there's some way to get around this "viewable" issue. I tried setting the documentation pages template to "admin" but as expected, viewing them gives me a "this page has no process assigned" error message. I think this might be a feature request for the Reno theme, really, but wanted to post first in case someone had a quick solution I'm overlooking. Thanks! Page structure: - Admin -- Documentation (template: admin, process: ProcessDocumentation) --- How to do x, y, z (template: documentation, no associated template file) --- How to do another thing (same) ...

Good news. PW 2.8.x and 3.x already support whitespace. I didn't realize those versions were in separate repos: https://github.com/ryancramerdesign/pw28 and https://github.com/processwire/processwire. Ryan said 2.8 repo is probably moving to the processwire org github shortly.

I was really surprised to run into this just today. I opened a github issue because there's really no reason I can see for it. https://github.com/processwire/processwire-requests/issues/4 Edit: changed the github link to new PW requests repo. Please vote/+1 there to express your interest.

I would recommend against that type of option naming. I think it would add to the confusion. We have allowRelative and requireScheme currently, neither of which do what I'm thinking. Adding onlyRelative to the mix is confusing. I'm OK with no changes to the core for now.

My main point is that when I give a string to the sanitizer with allowRelative=false, I expect it to return a blank value for "invalidurl", because it's not a valid, non-relative URL. Most versions of PW, including latest, use the validation filters. It's probably not easy to modify the behavior I'm expecting, so I'll just use filter_var().

I would generally agree, but url() is kind of a hybrid method. It's using PHP's validation filters, not just sanitizing filters.

Bumping this thread because I have a related question. I just discovered after a lot of testing that this: $sanitizer->url('invalidurl'); Will return "invalidurl" instead of blank, as I'd expected. Setting the allowRelative option to false prepends the string with "http://" and the resulting "http://invalidurl" passes validation. This does not seem like the behavior I expect. When I turn off allowRelative, I expect it to sanitize the string as-is, requiring a scheme, not adding one. This is on PW 2.6.0, but looking at later versions of Sanitizer.php it appears it functions the same. For now I'll just call filter_var() directly to get the stronger validation I need.

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.