FireWire

Never knew about that module. Good share. Outside of having the manually coded implementation, an integrated approach would be great for those who aren't strong back end developers and wouldn't be comfortable digging into hooks. There is value in the behavior. One of the big draws of PW is it's raw power combined with ease of use which puts this kind of feature within the hands of developers like you and I but beyond many others. I couldn't find this module being listed anywhere that could be found. Is it something that you put together? If it's used by someone then having proper attribution is something that would be a good practice to keep going (myself included). Thanks again for the share.

100% don't think it's pedantic. I think this needs to be part of the conversation for developers who look to implement features that are truly needed for a website to function well while considering security. As a dev in the U.S. we have a data free for all over here- but one day I might build a site/app with an international focus- other devs as well.

I think @wbmnfktr may have a good point on scalability and load handling. It's curious because they have been around long enough to break into the American market and their performance is so good that I'd have expected an acquisition by now. Very odd indeed. Whether technical, financial, or bureaucratic, the fact stands that they've been around long enough to go into the American market- they just haven't. If they're citing tax purposes either it's a f****-off answer, or they're just trying to do it now. I'm an American and I run VPSs in the EU with a subscription model which would be similar. There's too many variables here to even guess.

You only have to send the domain, so your GET request would be: https://open.kickbox.com/v1/disposable/mailinator.com I'd write a server side validation script that makes a call to that endpoint and also have that script return data to AJAX requests. You get server side validation as well as a way for your client side validation scripts to make an AJAX call to your own server so your user's IP address is never exposed to a third party site either. If you wanted maximum privacy for your users.

That looks like it's only good for Payoneer to Payoneer payments where both parties have an account. Kind of a bummer- I had already started working on a module before I ran into this problem. I'll pick it back up if/when the service becomes available in the U.S.

I always prefer an API when available to keep the information up to date and future friendly and The link @bartelsmedia posted looks like it's dead. This repo maintains an updated list, but also provides a link to an API that lets you check a domain on-demand. https://github.com/ivolo/disposable-email-domains The API is simple, send a GET request here https://open.kickbox.com/v1/disposable/{DomainOrEmailAddress} and it will return a JSON response like {"disposable": true} (or false) I think that using a live service is preferable to relying on PW to continually update an internal database unless there's a special use case. Integrating this feature into the Pro form-based modules would be great.

I looked into this and one of the limitations that their website does not say is that this API is not available to anyone purchasing access from the U.S. This basically is a dealbreaker for a lot of people and the implementation would mean it's limited to a very small number of people. Modules essentially would only be useful to someone that can purchase using billing addresses in the EU. I briefly considered some sort of credit card fraud... but passed haha. I was really interested in DeepL and went to sign up for the API to get access to it and only found out that I couldn't buy access to it when I went to enter my CC information. Very disappointing that they did not say this anywhere on their website (I checked). I spoke with them this week so the information is up to date on this finding. I sent an email to their staff and they said they are working on making it available outside of the EU but that it isn't due to "tax reasons". They didn't give any sort of timeline so until some point in the future this would only be available to users there. Big bummer.

That's a great idea. I'm going to add some information to the configuration screen with recommendations and information on that as well. Would this benefit from creating a post in the Modules/Plugins forum since this one is in the Module/Plugin Development forum? I initially wanted to see if there's any critiques or feedback that showed it wasn't ready for primetime but I think it is.

Hey everyone- We recently had a need come up for a website. After launching our website the company hired an SEO specialist who is doing some significant work revising and optimizing content. To help enhance this process I wrote a very simple module that automatically submits the website's sitemap.xml file to Bing and Google when a page is published, or when a page is saved that was already published. As for our reasoning- there's a lot of information available as to why submitting your sitemap regularly can be beneficial. In classic Google style their official documentation says that there "is no guarantee" that submitting a sitemap alone will trigger a re-indexing by Google's bots. That said, devs have done tests where there is a strong correlation between a sitemap submission and activity by Google bots on that website. Google has stated that there is no limit or cap on the number of times you can submit a sitemap so there is no penalty for triggering this for every change. For more details and the hard science visit this excellent article https://trevorfox.com/2018/09/ping-sitemaps-search-engines/ 2021 Update! This module has been rebuilt almost entirely to perform even better and cover more events that can affect sitemap.xml data which makes it more effective for your SEO performance. Previously the module submitted the sitemap.xml URL when a page was saved but has now been expanded to encompass any event that potentially modifies your sitemap and does it more intelligently. These events include: New page is published - New URL created Existing page is unpublished - URL no longer available Existing page is saved - Content on page may have changed Existing page is moved - URL has changed Existing page is deleted - URL no longer exists Existing page is restored - URL is now available ProcessSitemapSubmit also: Checks if sitemap.xml exists/is available Logs submissions and results to sitemap-submit log Allows for the sitemap URL can be specified, defaults to yoursite.com/sitemap.xml Templates can be excluded for pages created/saved that should not be submitted to search engines Hidden pages do not trigger a submission. Supports Bing and Google As always, I'd never share a module with the community that I haven't used in production but I still ask that you test and ensure that it works for you. The repo for this module has a notice that it is still in development but I am going to bring it to a release and add it to the Modules directory soon (i.e. when I have a spare minute). This module should have little to no risk and the best way to test is to check the sitemap-submit logs for successful submissions. I am a big fan of the Sitemap module by @Mike Rockett and use it on all of my sites. The Sitemap module uses caching to deliver your sitemap.xml file efficiently. I've worked with Mike to update his module so that it allows ProcessSitemapSubmit to clear it's cache and deliver the latest changes to search engines. This module is aware of Sitemap and works with zero configuration out of the box. To get this functionality in tandem with ProcessSitemapSubmit, please update the Sitemap module on your site. The Sitemap module is not a requirement for this module to work as long as your website has an available sitemap.xml to submit. Check it out. https://github.com/SkyLundy/ProcessSitemapSubmit Feedback and bug reports welcome!

@horst Thank you for that code. I was able to ensure that the language was being delivered properly. It turns out that the tech managing our in-house web server had very very aggressive caching enabled through Nginx and purging the entire site's cache fixed the issue. The issues that were coming up didn't look like a caching issue so it was odd. Had odd URL issues and redirect looping. General recommendation to everyone is check with your server admin when all hope is lost...

I do remember checking that the URL was enabled on the Home page so it should be available on all of the children pages as well- which has been what I've experienced before. Thanks for the code snippet- I'll start with that to start troubleshooting.

Hello everyone. I have a multi-language site that has an issue with redirecting the user to the default language if they are not logged in regardless if they have visited a url for another language. When I am logged in I am able to visit either language fine. When I'm not logged in I get a 302 redirect to the default language. Example: /es redirects to / if I'm not logged in.

Good to know. $this->getLangFromCookie() returns a string and is shared by other methods in the same/other classes. I could probably refactor it to work directly with the language object, but I'll have to come back to that sometime. Appreciate that info.

Added that to a comparison and that did the trick! Here's the method after adding your trick: private function doInitLocalization() { $page = wire('page'); $user = wire('user'); $input = wire('input'); // Get/set user language from either browser or cookie $user->language = $this->getLangFromCookie() ?: $this->getValidBrowserPrefLang(); $urlSuffix = str_replace($page->url, '', $input->url(true)); $userUrl = $page->localUrl($user->language) . $urlSuffix; if ($_SERVER['REQUEST_URI'] !== $userUrl) { header("Location: {$userUrl}"); } } getLangFromCookie() checks if the user has visited previously and selected a language from a dropdown. getValidBrowserPrefLang() gets the language pref sent by the browser, if it exists as a language in the CMS, returns the value. By setting the language for the user this checks against what the browser request asked for/server is delivering vs. what the CMS knows it should be delivering. If they differ, then redirect. This is executed in _init.php so any point of ingress is checked for url vs. preference. Thanks @kongondo for introducing me to $input->url and the good idea for direction. Thanks @Soma for concluding my head->desk marathon. Your solution is the simple one I couldn't see.

That sets the user language properly but getting the $input->url(true) still gets the non-localized version of the URL so it doesn't redirect to the translated page. It loops and fails the redirect. Also the language move has been a little rough because using the code below seems to lead to a possible solution but is where I was hitting the paging/GET issues. $languages->setLanguage(-lang str here-); // Also sets the language as a $user->language assignment does $page->localHttpUrl($user->language); // Returns the proper localized URL, but does not include pagination or GET vars I've seen many posts in the forums about redirection to a language and all of them use $page->localUrl($user->langauge) and none consider GET vars. Multi-language documentation says that the $page->localUrl() will automatically adjust to pagination but I haven't seen it. Would still have to manually build GET vars.

Yeah, I'm not explaining my situation well enough and it's becoming a little more complex. I'm working on abstracting localization to a class where one of the methods is used to redirect the user to their preferred language. That preferred language is either the language preference they have set in their browser, or a language cookie that was set last time they visited and selected a language via a select dropdown in the nav. That said, since the method is run on page load it will not have any access to specific pagination instances because they don't exist yet. I read the link above and didn't see a solution that covers all of the bases and the module reference in a link to another post is no longer maintained, so I am going to write a custom implementation. Here's my solution: Language detection will be tied to a unique session variable. On page load, the script checks for that session variable, if it exists- it exits because the language has been checked/redirected if necessary on ingress already. If no language session variable exists, then compare the destination URL against the URL of that page for their preferred language. If the URLs do not match then build a new URL The destination URL is checked for page numbering using $input->pageNum(), if > 1 then create a URL string for that. Any GET variables are extracted and rebuilt into a string- this preserves any possible incoming variables like UTM trackers. Get localized URL for user's preferred language, re-add page number, re-add any GET variables that existed. Set unique language session variable, then properly redirect to the localized page using the build URL. I kind of wish that there was a built in method that could wrap most of this up and preserve URL details while redirecting to a given translated page, but this should work and also only redirect once. I may be over-complicating this but it's what I've got. I really appreciate your help!

So I figured out the source of the issue. I wrote some code that detects a user's preferred language either from their browser language setting, or from a cookie that is created when they have visited and chose a language last time. If a preferred language detected and the current page URL does not match it, it will redirect to the same page but in the proper language. My problem is finding a way to get the URL that includes the pagination to compare. Right now my idea is to use $input->pageNum to build the URL myself... is there a way to get the URL including the page number? Lesson learned...

Indeed I have. Page numbers enabled, url segments disabled.

Hey everyone, I'm pretty experienced with pagination and haven't seen this before. I have my pages pulled using $pages->find, which is working fine however using renderPager() generates pagination where the links do not work. Here are some details. All templates needing pagination have pagination enabled in the admin. URL Segments are not enabled. Clicking on the "Next" or numbered links merely reloads the current page. The link href values are properly being output with the urls being /page2, /page3, /page4, etc. Manually entering the paginated urls has the same effect of reloading the current page with no new content. Pages are being returned from the ->find function properly and with the proper limit. A few other details: ProcessWire v3.0.98 Multi-language is enabled, 2 languages implemented. Pagination does not work on either language Have very few modules installed (few enough to list), none of which I could see interfering: ProFields, ProDrafts, ListerPro, DB Backups, Cronjob DB Backup, Upgrades, Upgrade Checker, Force Password Change, Markup Sitemap XML I'm stumped. For the sake of being overly-thorough, here's the code: <?php $articleTemplates = [ 'template_news_article', 'template_news_video', 'template_news_press_release' ]; $searchParams = [ 'template=' . implode('|', $articleTemplates), 'sort=-published', 'limit=' . $pages->get('template=template_news')->list_count ]; $articles = $pages->find(implode(',', $searchParams)); echo $articles->renderPager(); ?>

I did see that and I tried it out in the past, I just couldn't get past the 24hr format entry and the clock entry method, I know that will be an issue with the client as well. This was a fast and easy way to get a picker that matches the datetime entry field. I really wish there was a native way to do that- it makes for a cleaner look for the user. Also looks really good in the new uikit theme.

I've run into this need a few times and decided to take a crack at it. I am doing a custom calendar and really needed to get this time field and I'm on a deadline. I have a solution- albeit a little quick and dirty, but it works well for my project. I've only played with this in the new AdminThemeUikit admin interface though and do not know if it works in previous versions of PW. This is similar to the solution above but with no dependency on the Admin Custom Files module. I created a file called pw_admin_timefield.js and put it in site/templates/admin/ to keep it organized from the site's code. Inside that file I added this: $(function() { if ($.fn.timepicker) { $("input[name*='_time'").timepicker({ controlType: 'select', oneLine: true, timeFormat: 'h:mm TT', stepMinute: 5 }); } }); Checking for the existence of that function is a requirement as it is not loaded on all admin pages and will prevent the page from rendering properly. Since this isn't integrated as a true module these settings dictate how the time select will render every time. The timepicker plugin included with PW is here at this link and has all documentation for configuration: http://trentrichardson.com/examples/timepicker/ In the site/templates/admin.php file I added these two lines: $modules->get('JqueryCore'); $config->scripts->add($config->urls->templates . 'admin/time_field/pw_admin_timefield.js'); If the JqueryCore module is not called you will get the $ not defined JS error. Whenever I need a time select field with no date I create a text field with a suffix of "_time" on the end of the field name which matches the jQuery selector above. So my calendar has event_start_time and event_end_time and they both get time-only pickers. This would be much better as a module with the level of configuration that the Datetime field has. I might work on doing that next, but in the meantime this immediately solved the problem I had quickly. Thanks to @Soma for this article on custom JS in the admin: http://soma.urlich.ch/posts/custom-js-in-processwire-admin/

After you had started to explain the use of the users directly rather than the pages I began thinking in that direction as far as the URL segments go and I just read about the login-disabled role a couple of days ago but didn't think of that use case until you mentioned it. That very well may have swayed me away from building this module. Unfortunately in my case we haven't updated our core yet and we're still back on a .6 version. We're upgrading to the latest with our next feature push so I'm pretty stoked about that. Your method is really solid and I am very sure I'm going to run into places I can use that. Building page references with better selectors opens up a ton of possibilities. Thanks for the explanations and help- I really appreciate it!

Creating the extra pages allows for a page select field to be generated so a specific user with a blog-author role can be chosen to override the blog post creator. I wanted this to be more static/persistent than drawing from the list of admin user pages directly in case at some point a person is removed completely from the CMS we won't be trying to reference someone that isn't there anymore and create an issue with blog posts that have been published before that. A bonus to having a page generated from the user is the ability to have an author page available at say "blah.com/blog/authors/john-example" where I can show a page on the site displaying all the blog posts by John Example (and his ghost writer). Then let's say John Example leaves the company and his user is removed from PW completely, the page structure and all of the page references are intact with no user attached to them. We won't have guest authors per se, just real authors that need to write posts and sometimes be attributed to other posts. I think I get your solution but I don't know if I'm making the connection well enough to understand if it satisfies my scenario. Absolutely interested in your explanation. I also need to get more familiar with the selector string for page reference field. It's great!

That modal module looks great. I'll play around with that. The method you described was my original approach as well- it would definitely fit within the blog use scenario. After I met with the team we decided that we wanted to have it both ways. More specifically- at my company we will have many people contributing to the blog so they do need access as blog authors to write posts, however there will be other people helping write more than others. There will be times that they will have to post as someone else so going by the creator of the page won't work since that can't be changed unless they are a superuser and that's not possible for our system. Basically, there's a site-manager role for a person who does a lot of copy writing but may need to contribute as someone else. If a blog author contributes that's great, otherwise if a site-manager posts for them they can override the author since the page creator won't be the author we need. My module tries to solve this by always having a page under authors like you had described while still allowing the authors to log in and blog as they need.

Hi everyone. I just completed first draft work on a module that I wrote. It creates a page for a user with a specified role when a user admin page is saved. I'm sure it could use some more work and would like any feedback on implementation, code quality, and any better utilization of the PW API. The problem I aimed to solve is that we are using the fantastic MarkupBlog module and wanted a way to easily specify an author for a post when the person who created the page is not the author we want shown on the post (example: one blog author ghostwriting for another blog author). This module allowed me to create a blog-author role and on user admin save create a page under the "Authors" page in the tree. After that each blog post gets a page select field that lists the Authors page children for selection. More detail: If a user is deleted from the CMS, their page remains in the page tree. This is to prevent problems if there are other pages that depend on that page. A hidden field is added to the User admin page that holds the id for the page created. When creating a page for a user, it checks if there is a page already created with that user's name- if it is, that page is used and the hidden field is updated with that page's ID. If a user's page is deleted from the tree, a new page is created on user admin save and the hidden ID field is updated with the new ID. Module installs and uninstalls properly including adding and removing the hidden ID field from the User system template. The module settings allow for choosing more than one role to create pages. Again since this is my first rodeo with ProcessWire module development I would love feedback and critique. The code is available here: https://github.com/skylundy/AutoUserPages Thanks!