Leaderboard

This module for ProcessWire sends a notification email for each failed login attempt. Similar modules exists already in the module directory of ProcessWire. However, this module is designed to notify, even if specified user doesn't exist. Settings The settings for this module are located in the menu Modules=>Configure=>LoginFailNotifier. Notification email Specifies the email address to which the notification emails should be sent. Email subject Specifies the subject line for the notification email. Post variables Specifies the $_POST variables to be included in the notification email. Each variable must be separated by a comma. For example: login_name,login_pass Server variables Specifies the $_SERVER variables to be included in the notification email. Each variable must be separated by a comma. For example: REMOTE_ADDR,HTTP_USER_AGENT Link to ProcessWire module directory: https://processwire.com/modules/login-fail-notifier/ Link to github.com: https://github.com/techcnet/LoginFailNotifier

ProcessWire 3.x markup module for rendering meta tags in HTML document head section. Note that this module is not a full-blown SEO solution, but rather a simple tool for rendering meta tags based on module configuration. Adding custom meta tags is also supported. Built-in meta tags The following meta tags are supported out-of-the-box: Document title consisting of page title and site name Character set Canonical Viewport Description Keywords Hreflang tags Open Graph og:title og:site_name og:type og:url og:description og:image og:image:width og:image:height Twitter meta tags twitter:card twitter:site twitter:creator twitter:title twitter:description twitter:image Facebook meta tags fb:app_id The full documentation with configurable options can be found here: https://github.com/Fokke-/MarkupMetadata Requirements: ProcessWire>=3.0.0 PHP >=7.1 Installation using Composer composer require fokke/markup-metadata Manual installation Download latest version from https://github.com/Fokke-/MarkupMetadata/archive/master.zip Extract module files to site/modules/MarkupMetadata directory.

Last week we released the new ProcessWire 3.0.184 master/main/stable version. This is our biggest version release in a year. It's been a very smooth stable version launch with no major issues so we're keeping the version number where it is this week. If you haven't upgraded yet, it's an easy and worthwhile upgrade. For full details see the blog post that covers it all. This week I have 3 new Textformatter modules released in the modules directory. These are modules that I developed earlier for recurring needs that I had, but this week decided to finish them up and release them. I hope that you might find one or more of them useful sometime. TextformatterFindReplace This module applies find/replace patterns to formatted text or markup at runtime. The patterns may be simple text or more complex regular expressions. This module can be handy if you perform a text replacement on all output from a particular field, without having to manually make the change on all instances where it might appear. For instance, maybe you need to insert a trademark symbol ™ after every appearance of a brand name, or maybe your website hostname has changed and you need to replace all references to it, or perhaps you need to replace all <h1> headlines with <h2> headlines. These are just a few examples of any number of possibilities. Read more / Usage / Examples TextformatterMarkdownInMarkup Enables you to use Markdown formatting codes in CKEditor (or HTML). A significant amount of content that is populated into the “bodycopy” field of websites is not actually written in the admin and instead originates from text editors, word processors, and other tools outside of the CMS. It then gets pasted into CKEditor, and then manually formatted into HTML using tools in CKEditor. This process of manually converting links, lists, headlines, bold, and italic text and more can be sometimes very time consuming. This module provides a time saving alternative, enabling use of markdown formatted text in CKEditor (or any HTML/richtext editor). It remains as markdown formatted text in the editor, but as soon as it is rendered on the front-end it is automatically formatted as HTML. This means that text like **this** gets converted to this, links like [this](https://processwire.com) get converted to this, and so on for most types of markdown formatting. This enables markdown formatted text to be written anywhere and the formatting to be rendered properly in your bodycopy when viewed on your website. Using this module means that you can mix richtext and markdown in the same copy. No longer do you have to manually convert all of the links, lists, bold/italic, and so on in pasted in text. This module saves me quite a bit of time when writing blog posts like the one last week. Much of the formatting in that post was markdown based, since I wrote the post in my text editor over a period of a couple weeks. Once I got it into CKEditor, I did some formatting with that too, but when it came to other formatting (especially links and inline `code`) it was a big help to have them just work, and not to have to re-do all of them manually with CKEditor tools. So why not just work exclusively in Markdown? Well I don't like working with just markdown most of the time, I much prefer CKEditor. But I also can't deny the convenience of markdown for a lot of cases too. So being able to use Markdown within CKEditor is the best of both worlds, to me at least. Read more / Supported markdown / Configuration options TextformatterEmoji This module converts more than 800 named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. ? This can be especially useful if your ProcessWire database uses the utf8 character set rather than utf8mb4, as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Though when you want to specify an emoji by name, this module will be useful regardless of your database charset. Read more / Supported emojis reference

Wow, a triple-whammy of modules, thanks @ryan! I noticed that two of these new modules don't have support threads in the forum and the Support button in the modules directory listing isn't functional. That situation also applies to your Login Register module which I believe used to have an entry in the modules directory but no longer does. (Edit: after doing a quick scan through your modules in the directory it looks like the majority don't have support threads in the Modules/Plugins subforum) It's inevitable that users of these modules will have questions/issues that they will want to raise here in the forums, so it would be good if every module that's shared with the community has a dedicated thread in the forums. Otherwise people open multiple new topics so it's harder for users to look through the history of discussion about a module. If the reason some of your modules don't have support threads is that you're not able to spend time responding to support requests (which is totally legitimate IMO) then the opening post could explain the support status of the module, maybe something along the lines of "this module has been shared with the community but the author is generally not available to provide ongoing support". Then people can still post questions or issues with the understanding that they are not guaranteed to get support from the module author but that other members of the PW community may offer advice.

Hi Juergen, I tried to install the module to processwire (latest version) and got a fatal error: Aw shucks… Fatal Error: Uncaught Error: Using $this when not in object context in C:\xampp\htdocs\p20\site\modules\FrontendForms\FrontendForms.module:41 After changing line 41 in FrontendForms.module and remove the '$this' module installed in processwire. The line 41 changed to: 'summary' => 'Create forms and validate them using the Valitron library.', Just writing this remark as maybe help some other users in module installation. I am going to test your module in the following days. Thanks for your work

Thank you, @horst. Possibly that was the core of the problem.

Thank you very much!

Hi Ryan! I upgraded to 3.0.184 and saw that it kept trying to add the title field to the templates for extra image fields. I'm not sure why it's doing this. Will need to reproduce it on my minimal ProcessWire install to figure out how to reproduce it reliably. It does happen. Just not sure how and why. That being said, I do love the new page hooks! They make it easier to output my main site pages in JSON if I just want to show them in JSON. Excited about possibly formatting page outputs in markdown or yaml later for the fun of it.

It’s been a great two weeks in Processwire land. Thanks Ryan and community.

I do not know how you do this magic ?, Ryan, but it happens once again. I do need emojis in utf8 db this week. And bang ? - now I have it))

I finally got round to try the language tools and they are great, as expected. I have a few basic questions please. Sorry there are a few here but I thought it better to do it in one thread. I have searched for the answers but couldn't find anything. How do you access a language-alternative field if the language has a dash in it? E.g. you can have language foo-bar but not $page->body_foo-bar; the field is not allowed (tried it without the dash and with an underscore when using the API to no avail) Is it possible to have the languages expanded by default? I.e. as though you have clicked the folder icon Is it possible to show the languages in a dropdown instead of tab for large numbers of languages? Just curious really. It's not often this would be used but I do have one site with 15+ languages that I may eventually port over. In Languages what are Live Search, Site Translation Files and Core Translation Files for? Is this irrelevant to the front end? It looks like it is for translating PHP files but just wanted to make sure it wasn't something I could make use of. I will only ever require English back-end and would store or translations in fields in the database. If you choose a non-default language in your profile in the back-end is there any way to know from the site tree that for a given page the name is not active? It doesn't appear so but I feel this is quite an important feature if managing lots of pages and languages. What is the rationale behind always searching the current language and the default language when using the API? There is a workaround here but just wondered as I wouldn't thought it better to only search the current language. Finally, let's say you have a latest news section on a site with five languages and you only wish to publish an article in one or two of those languages. Is that possible? From what I can gather so long as you are publishing in the default language you can simply uncheck the “Active” box for the languages you don't wish to have a page for. However, it looks like you must have the default one. I presume this is so it has all the fallbacks it needs. I guess it would be easy enough to throw a 404 for the default page. Thanks!