Leaderboard

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

You could use a hook... $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); /* @var Page $page */ $page = $event->arguments(1); if($page->template == 'your_parent_template') { $selector .= ", sort=date, sort=title"; $event->arguments(0, $selector); } }); ...or this module: https://modules.processwire.com/modules/process-page-list-multiple-sorting/

In the past I've worked with a few translation platforms (Launchpad, Twitter translation center, translate.wordpress.org, etc. — there are plenty of good examples) and one of the projects on my "things I want to do as soon as I find the time" list is a similar platform for ProcessWire. The way I envision this working would be a shared service (website, essentially) where translators can register and do pretty much the same thing they would do in the translations screen in Admin, and then share those projects with others who can both use them and contribute (obviously after an approval process). This would likely be split into "projects" (core, individual core or third party modules, site profiles, etc.) For the site you'd still need a module to install these translations, but the main concept here is a common library of translation files that would do most of the heavy lifting and provide an API for the module. I've been struggling a lot trying to keep up with who manages which translation for what language and where and how (and which version is the recommended, when there are many competing translations), and that's really the biggest thing I'd like to solve with this. In a multi-language environment I feel that this is almost a must-have feature in the long term... and, should it gain some momentum, I could really see that being a valuable addition to our "official site bundle" (translate.processwire.com or something along those lines), though obviously that part depends on how Ryan sees this ? Anyway, just wanted to let you know that you're not along with this need. The problem for me is that I've got a pretty good idea of what I need to do, but I still need the time to do that. I hope to find just that (unless someone nails something similar down first, that is) in a few months, but that's not a certainty yet ?

Sounds like the effects of a shortcut key combination. Maybe you have the Admin Hot Keys module (or something like it) installed?

Hi, The module is now ready for use in production. It is still in Beta as I need to test token renewal, but cannot do this yet due to how token renewal works. Cheers, Chris

Hi @teppo yeah, that would be awesome! Carbon has a great translation tool: https://carbon.nesbot.com/contribute/translate/ I've recently suggested an improvement for de_AT and it's already in the package, available for everybody. I just opened a new ticket right now - see here how this looks like: https://github.com/briannesbitt/Carbon/issues/2036

We've all been there ? Thanks for your perseverence on this! ?

Fortunately it was more complicated than just me being silly so I can stop kicking myself now ?

Thx @dragan that are really some old threads! ? That doesn't make me feel very confident that such a feature finds its way into the core soon. I could also think of a module that copies over translation files from modules folders to the assets folder of the language. The translation module could also lock the translation screen of the json file to prevent unwanted overwrites (or show a warning). And the module could make the necessary links between the sites language names and the standardized translation directories in the module, eg a site having language "german" could link to the module's translation folder DE. On another site the superuser could make the link deutsch-->DE instead of german-->DE We could also ship some common translations directly in that module (eg for ListerPro)...

The FB board is here. Often, a module is v3-compatible even though it's not officially marked as such. Try to install it and see if it works. Sometimes all you (maybe) need to add, is PW namespace in the .module file(s). There's also this module that might do what you want: http://modules.processwire.com/modules/guid-generator/

I once asked Ryan if he plans to add language files to his Pro modules. He doesn't plan to do so. His reply was (more or less) that most people using these modules were developers, not authors (clients), and a developer surely understands English. Fact is, many of the Pro modules are not only being used by superusers, so that's kind of a weak excuse. It's a lot of work translating e.g. a Lister Pro language file. Of course, for German, I only did it once, and then copy files over. Other eco-systems have solved this way better imho... On a side-note: Ryan is maybe missing out on marketing arguments here... it would be easy for him to aggregate at least a dozen translations for his modules from existing developers / agencies who bought a license and translated everything on their own. In return, he could give away licenses or free access to the VIP support boards to those ppl who translate Pro module JSON files ( A classical win-win situation ?). For some ppl, it makes a difference if a module is already translated in x languages or just English. That's a robust sales argument right there.

Apparently, that's an old question: https://processwire.com/talk/topic/15367-translating-module/ https://processwire.com/talk/topic/2583-delivering-module-translations/ Seems like nothing has changed in that regard in the last years ? I'm sure there would be workarounds, but then every module developer would have to create such a "install multi-language files" routine for himself, and that's hardly efficient (e.g. a menu in your module config screen where you could map JSON file A to PW-language C, and then the file(s) would be moved to the right folder. It would indeed be nice to have that functionality in the core.

For some reason this is an issue only with this module. You're not the first one to stumble on it. I updated the Readme to add Troubleshooting section that explains this issue in details.

Right, this should be fixed now finally. For those that are interested, there was an issue with the forum session wiping out the ProcessWire session by the end of the script - a little puzzling because right up to the end of the script everything seems fine but when you redirect the session information is lost. To overcome that there's some background CURL stuff going on now so the two systems are separated completely during the login process. Please feel free to post/update your profiles again and sorry it took so long.

Hi @Jofra, welcome to the forum. Did you already read the getting started docs? https://processwire.com/docs/start/ Or do you have any specific questions?

@fuma255 You should put your query to the whitelist https://processwire.com/api/ref/wire-input/whitelist/, but I think that there are some other issue in your search logic. Could you show it to us?

@Miguel Scaramozzino Also, just wanted to confirm with you that you're making request to the correct url. In default PW settings "/graphql" and "/graphql/" are different. If you happen to make a request to "/graphql" (without forward slash at the end) it will be redirected to "/graphql/" and the content of your POST request gets lost in the middle.

@baronmunchowsen A little trick I use when I need to store JSON is to add two methods $cache->saveRaw and $cache->getRaw through hooks, which just add the prefix to bypass the JSON encoding. See my reply here, which is a slight modification of LostKobrokai's code. Same result as @BitPoet's code above, just feels a bit cleaner than manually prefixing the JSON wherever you need it.

Building on @BitPoet's code, here's an alternative way you could add labels to the select options: $wire->addHookBefore('ProcessPageEditLink::execute', function(HookEvent $event) { $input = $event->wire('input'); $page = $event->wire('pages')->get($input->get->id); // Do some check on $page to return early when not applicable $anchors = $input->get->anchors ?: []; $my_anchors = [ 'some_anchor' => 'Some anchor', 'other_anchor' => 'Other anchor', 'third_anchor' => 'Third anchor', ]; $anchors = array_merge($anchors, array_keys($my_anchors)); $input->get->anchors = $anchors; $event->wire()->addHookBefore('InputfieldSelect::render', function(HookEvent $event) use ($my_anchors) { $inputfield = $event->object; if($inputfield->name !== 'link_page_anchor') return; $options = $inputfield->options; $inputfield->options = []; foreach($options as $option) { $anchor_name = ltrim($option, '#'); if(isset($my_anchors[$anchor_name])) {; $inputfield->addOption($option, $my_anchors[$anchor_name]); } else { $inputfield->addOption($option); } } }); });

I saw this slide on Twitter : Apparently PHP8 will throw Errors instead of Warnings for many instances. So perhaps it is adviceable to already start preparing your code for the upgrade.

I think that should work, but your if statements are missing the closing ")" You have: if($user->hasRole('competition-secretary') || $user->hasRole('membership-secretary') { return "/members/"; } else if($user->hasRole('member') { return "/members/" . ($user->name); } else { return "/" } instead of: if($user->hasRole('competition-secretary') || $user->hasRole('membership-secretary')) { return "/members/"; } else if($user->hasRole('member')) { return "/members/" . ($user->name); } else { return "/" } The error should go away if you fix the syntax. I think you might also need a closing slash after $user->name to complete the path.

Sorry @MarcoPLY I didn't saw your last ping! This is the correct way to call the hook, put it in ready.php as you did then, go to Modules > Refresh if you still can't see the hook. Code : wire()->addHookAfter('Pages::saved', function(HookEvent $event) { // Get the object the event occurred on, if needed $pages = $event->object; // Get values of arguments sent to hook (if needed) $page = $event->arguments(0); // your code: $page = $event->arguments[0]; bd($page); // tracy debug: User page object if ($page->template == "user") { $mc = wire('modules')->get("SubscribeToMailchimp"); $email = wire('user')->email; $subscriber = [ 'FNAME' => wire('user')->pad_firstname, ]; $mc->subscribe($email, $subscriber); bd($mc); // tracy debug: MailChimp object } });

Well, I live in Italy, Turin, inside a building 50mt far from an hospital and 20mt of a 24h supermarket. The hospital had 1 decease today and Covid19 is the one to blame for it. The supermarket is overcrowded outside even at 23 a.m. I'm working from home and I cannot go outside without a 'right purpose' and a self-certificate of why I am there. My wife cannot stays home for work and her company produces various cleaning products which are a top-sellers this days... My 4yo son stays with his grandparent all day long, without having the opportunity to play with other kids. My mother is 72 and had, 2 years ago, some lunges problems and now, even though she is fine by now, she is really scared.