Leaderboard

These last few weeks I've been working on integrating a ProcessWire installation with the Fareharbor API for a client. Other than the authentication part (which is as simple as it gets), I've found this API to be one of the more time consuming ones to work with. It's not so much that the API is difficult to use, as much as it is just a time sink, taking a long time to reorganize the info it provides into something useful for our needs. And likewise taking a long time to prepare information to put back into it in the format it requires. My best guess is that it is an echo of an existing back-end API, projecting internals rather than tailoring a simpler public API to them. Perhaps it's an interface optimized for the some internal legacy system rather than the external consumers of it. Or perhaps it already is a lot simpler than what's behind it, and its interface has been carefully considered (even if it doesn't feel that way), who knows. To be fair, no API is perfect, and this particular API does provide a working and reliable interface to some pretty complex data, and an immense amount of power. It's good to work with lots of different APIs, from easy-to-painful, as it helps to clarify paths to take (and to avoid) when authoring new APIs. I ended up building an adaptor module in ProcessWire just to give this particular API a simpler interface that was more useful to the needs we had, and that is now saving us a lot of time. It reminded me of one reason why ProcessWire was built in the first place, to create a simple interface to things that are not-so-simple behind the scenes, and I think we've been pretty successful with that. We'll keep doing that as ProcessWire continues to mature, evolve and grow, as we always have. In terms of core updates, commits this week were similar to those from the last couple of weeks: a combination of issue fixes, a PR, feature requests and minor improvements. We are now 17 commits past 3.0.211, but I'm going to wait till next week before bumping the version to 3.0.212, as there's a little more I'd like to add first. Thanks for reading this update and I hope that you have a great weekend!

Haven’t tested but isn’t this just $page->prevAll('limit=5') and $page->nextAll('limit=5')? https://processwire.com/api/ref/page/prev-all/

Basically reiterating @wbmnfktr a Table is semantic while the DIVs are not. There a quite a few google search results for css div tables dating back to '08 where others have attempted replicating the html table using div elements. The main issue nowadays is the device screen sizes. Tables don't scale well at different resolutions. That being said, css has display:table, display:table-row, and display:table-cell type attributes, as well as using pseudo selectors like :last-child to reference specific elements. You could also hide specific table columns at different resolutions. I know this isn't the answer you were looking for, but maybe it helps with segregating large datasets into manageable chunks.

Also, you should never ignore the SSH warning you got. After all, turned out the warning was right and you didn't connect to the right place anymore ?

So the number of items isn't fixed. Didn't think about that. Then your version with negative margins would be the best solution* here. You could play around with padding and positioning those items a bit to remove that extra space but to be honest I wouldn't care that much. If it's about aliging you always can reposition the parent container a bit. * in case it's a real table, I'd recommened to use a real table markup

Hi @MateThemes Usually, If I need something simple I use Repeater field with depth option, if something more advanced I use Repeater Matrix field with depth.

So ... we're ditching Google Analytics for one of our sites (hooray) and switching it over to Fathom. Because we wanted to be able to make a comparison between the old stats and the new ones we've had both installed on the site for a couple of months. On top of that the site is behind Cloudflare so we also have stats directly from them. I've just pulled together the stats for the last 30 days: So thats: 37K visitors according to Google, 42K for Fathom 80K for Cloudflare My guess is that a Google is both fussiest about tying requests to real people (cos hey that's what they're after), but also most likely to be blocked by ad blockers and privacy tools. Fathom is probably less likely to be blocked by privacy tools; we use a bespoke domain which hopefully isn't blocked that often. Cloudways isn't is going to be blocked by anything (it's gathering stats at sever level) but maybe is more lenient about what constitures a 'visitor'. I'm not really sure about that but it is a big jump from Google. Anyway - I thought it was an interesting comparison and handy for when you need to explain to clients that analytics are useful for trends but not much cop if you're after real numbers.

Hi, With the deprecation of Instagram's API and therefore the end of the Instagram Feed module, I've developed a replacement module which uses the Instagram Basic Display API: https://github.com/nbcommunication/InstagramBasicDisplayApi To use this module you'll need: ProcessWire >= 2.7 A Facebook Developer account Access to the Instagram user account you wish to use Prior to installation, you'll need to create a Facebook app. The app you will create uses the User Token Generator for authentication - it does not need to be submitted for App Review (and therefore stays in Development mode). The README contains full instructions on how to create and set up the app and also how to use the module. The primary reason for this module's development was to retain functionality on existing websites that use the Instagram Feed module. To assist with upgrading, this module replicates some methods provided by Instagram Feed. I've already upgraded a couple of sites and it was quick and painless ? Cheers, Chris

Found the solution ? /** * Modify submit button on doc-import pages */ $wire->addHookAfter('ProcessPageEdit::getSubmitActions', function(HookEvent $event) { $page = $this->pages->get($this->input->get('id')); if(!$page->id OR !$page->template == 'docimport') return; $event->return = []; }); $wire->addHookAfter("ProcessPageEdit::buildForm", function(HookEvent $event) { $form = $event->arguments(0); $page = $this->pages->get($this->input->get('id')); if(!$page->id OR !$page->template == 'docimport') return; $s = $form->getChildByName('submit_save'); $s->value = 'Import starten'; $s->icon = 'download'; }); ? Does anybody know how I can remove the dropdown items from the page edit submit_save button? As I didn't find a solution quickly I wanted to replace the button entirely, but this results in the following markup: $wire->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { $form = $event->arguments(0); /** @var InputfieldForm $form */ $s = $form->getChildByName('submit_save'); /** @var InputfieldSubmit $s */ $form->remove($s); }); This hook results in this output: I could hide this markup via CSS but I'd prefer a clean solution ? Thx!

I don't know of a built in way but I'm happy to learn ? Not sure if that's the best way to do it but it works: $i = 0; $prev = new PageArray(); $next = new PageArray(); $p = $n = $page; while($i++ < 5) { if($p and $p = $p->prev and $p->id) $prev->add($p); if($n and $n = $n->next and $n->id) $next->add($n); } db($prev, "prev"); db($next, "next");

v2.15.1 ignores module migrate files if the corresponding module is not installed ? And it will trigger the migratefile right after the module has been installed! Thx for your input and feedback guys! Keep up bringing good suggestions ?

Sorry of course it's not ?field... on page edit, because you have ?id=... there, so you need to append that url parameter via &field[s]=...

Found out, I had a typo in renderViewURL (no caps URL). Nice to have those debug messages present ?

If the customer only wants to control the first level, then a page reference field should be enough. If the customer wants to control everything, then maybe a repeater with depth and page reference field should do the trick: https://processwire.com/blog/posts/pw-3.0.44-repeaters/ But I never had this case. Most clients want just rarely changes, which you can update in your code.

Thanks Bernhard - I had to remove the Save button when adding a new page with a particular template today for a specific reason, so here was my solution which I arrived at thanks to your code above: $this->addHookAfter("ProcessPageEdit::buildForm", function($event) { $page_id = (int)$this->input->get->id; $page = $this->pages->get($page_id); if ($page->template->name == 'my_template_which_only_needs_publish_but_not_save') { $form = $event->arguments(0); // We want to check the publish button is actually visible first - usually there is "isNew=1" at the end of the URL but that can be removed // manually so best to use a more thorough check $publish_button = $form->getChildByName('submit_publish'); if ($publish_button) { $save_button = $form->getChildByName('submit_save'); $form->remove($save_button); } } } }); This will of course revert to just showing the Save button once the page has been saved. Hope that helps someone in future (probably me in about 6 months time when I forget all about it - that's usually the case ? ).

Was this tackled in the 1.1.1 update? I can see it's still an open issue on github

Hi @DV-JF, It happens because Instagram/Facebook invalidates the (authorised) access token if the user changes their password. I guess from the error message (Facebook has changed the session for security reasons) other security issues can lead to it happening too. It isn't in the scope of the module to notify admins, but it should be pretty easy to implement. Try something like: <?php $instagram = $modules->get('InstagramBasicDisplayApi'); $items = $instagram->getMedia(); if(!($items instanceof WireArray) || !$items->count) { $cache->getFor($instagram, 'errorNotifyAdmin', 'daily', function() use ($config, $instagram, $log, $mail) { return $mail->new() ->to($config->adminEmail) ->subject("$instagram error") ->bodyHTML('<p>' . implode('<br>', $log->getLines( $instagram->className(['lowercase' => true]), ['limit' => 10] )) . '</p>') ->send(); }); } This would send the admin an email every day if no media is being returned, with the email being the last 10 log messages. Cheers, Chris

Hi @DV-JF, Is there anything in Setup -> Logs? Cheers, Chris

Yes, that would be what I expect too

Appending ?field=yourfieldname to the URL should be enough. ?fields=foo,bar would also work.

I'd probably do it this way. .cards { display: flex; width: 150px; flex-wrap: wrap; /* border */ border-left: 1px solid black; border-top: 1px solid black; /* taking care of the box model */ box-sizing: border-box; } .cards__item { flex: 0 1 33%; width: 50px; height: 50px; /* border */ border-bottom: 1px solid black; border-right: 1px solid black; /* taking care of the box model */ box-sizing: border-box; }

I think what you are looking for is "outline: 1px solid black;" instead of "border" ?

I totally agree and would have expected RM to work like that. No use for a module-related migration if the module is not installed.

I didn't have anything in the migrate file to install the module, but I did have code to create a lot of fields and templates and create some pages which all got created. I wanted these to be under the control of migrations, but assumed (incorrectly) migrations would only run on installed modules, ie once the module is installed I do want the migrations file watched and run if there are any changes, but if the module isn't yet installed it doesn't make sense to run its migrations. An easy way to get it to work the way I want is to do a conditional check at the start of the migrations file to see if the module is installed or not, and only run the actual migration code to create fields and templates if the module is installed. That way I won't get a bunch of fields and templates installed for an inactive module.

Came to get an ETA on TinyMCE frontend editing compatibility and found you've already pushed it! Amazing work as usual @ryan ?