Leaderboard

This module hooks into the login method to provide the possibility to login with the user's email address. This is my first module and it's very simple. Please provide feedback if you have any suggestions. Thanks The module can be found in the module repository: https://modules.processwire.com/modules/login-with-email/ or on github: https://github.com/noelboss/LoginWithEmail

Same provider - two sites - PHP 7.0 - PW 2.6.23 rc2 upgrades works - PW 3.0.42 upgrades gives error. But... there was some old .gitignore file that PW installed in the old days. Removed that and yes! Upgrades are back. I'll keep my fingers crossed and see if they stay...

I have used Repeater Matrix for this purpose, to create a type of page builder, each repeater type being a possible section, though you still have to have a predefined set of repeater types, most of this types have a checkbox or two for customization of behaviour (even repeaters inside, works wonderful)

$image = $page->images->get("name=myimage.jpg"); $image->width();

This is something that I've been trying to figure out for quite awhile. At the moment I do this: 1) Create template banner-index 2) Create template banner-entry 3) Create page 'Banners' using banner-index template 4) Create child page of whatever the banner will be, let's say 'Sounds good'. So you now have: ... and the template for 'Sounds good': (link to page is a Page type which enables me to pick ANY page on the site with a PageListSelect+ as input field type and 'Home' set as parent) So I create a file which is going to output the actual banner: // includes/_banner.php <?php namespace ProcessWire; // get the banner page determined by the id passed to this template // from wireIncludeFile additional array, see next snippet $banner = $pages->get($Id); ?> <div class="jumbotron jumbotron-fluid py-6 text-center bg-repeat"> <div class="container"> <h2 class="display-4"><?= $banner->headingMain; ?></h2> <p class="lead"><?= $banner->headingSubtitle; ?></p> <a href='<?= $banner->linkToInternalPage->url; ?>' class='btn btn-primary'>Go to <?= $banner->linkToInternalPage->title; ?></a> </div> </div> ...then I grab this file using 'wireIncludeFile' so I can pass an additional value into this template which is the id of the page: // views/about.php <?php wireIncludeFile('./includes/_banner', array('Id' => 1212)); ?> So the page id of 'Sounds good' is '1212'. I pass this manually at the moment. So now, when /about/ is viewed, it displays '_banner.php' wherever I want, where you can see the PHP is populated with values from the 'Sounds good' page: So, what about making this a bit more dynamic instead of manual IDs in a template. Create a new field 'bannerToDisplay' as a 'Page' field type: ...then select it to return just a single page: ...and choose the parent of selectable pages to be the 'Banners' page you made earlier using the 'banners-index' template with an input field type of 'Select': ...go add this bad boy to a template! ...then go edit your page: ...choose a banner, save it. Go edit the code which renders '_banners.php' and get rid of that manual ID: // views/about.php <?php // if something has been selected from the 'Choose a banner' dropdown if ($page->bannerToDisplay) { // get the ID of the selected page $bannerPageId = $page->bannerToDisplay->id; // pass this ID to the _banner.php template wireIncludeFile('./includes/_banner', array('Id' => $bannerPageId)); } ?> ...create another banner and then change the dropdown and refresh the page! This is obviously just an example which enables adding of a single block but once you get the idea of the Page field type and how you could use it, your options will increase a fair bit. The thing I found with repeaters is that you still can't add a content block above, say , a body field, then another one below it. Your template would literally just have to have the repeater on it and you add item after item. Of course, with a repeater, every item will be the same (defined once, then just repeated with alternative content in the same field types). I'm going to try the pro fields repeater matrix next for something similar. I'd love to be able to make entire pages simply from blocks and to be able to drag them around. It takes a fair bit of forethought though. Just experiment, have fun! NOTE: This still means you have to define WHERE the banner will go on the page via a template, but you can change WHICH banner to display on the page edit inside admin it doesn't solve your problem but hopefully helps a bit and gets you on your way. Good luck!

Yep - another Captain Hook update. Often hookable methods for a class are derived from a parent class. Take the "Roles" class for example. It lists add, delete, & save as the hookable methods that are available. But because it extends the "PagesType" class, its hookable methods are also available from the "Roles" class, eg: Roles::deleted. To make these derived methods easier to find, I have added a new: ClassName extends ParentClassName line to each file section. Both names are also linked directly to the API docs so you can find out more info there as well.

He's banned off the internet after I found out he was using my credit card to buy bones.

Found it https://github.com/noelboss/LoginWithEmail And it work fine @noelboss

Hi guys, I want to share what I found working on my custom front-end email login: Even if no user were found for the submit email, Processwire should check for login because the login throttle api will be triggered and it will prevent multiple login tries. If the $session->login() is only called when the email owner is found, then the login throttle api will not be triggered and that tells requesters that a user with the email they try to login exists or not in your DB. /** * Login a user with the given name and password * * @param string $email * @param string $password * * @return bool|string * */ public static function signIn(string $email, string $password) { $signedIn = false; if(!empty($email) && !empty($password)) { // taken from ProcessLogin->execute(); if($email = wire("sanitizer")->email($email)) { $emailUser = wire("users")->get("email=$email"); $name = ""; if($emailUser->id) { $name = $emailUser->get("name"); } $password = substr($password, 0, 128); try { /** * even if the user is not found, try a login with a empty username * because the Processwire Login throttle API will be triggered and * prevent multiple login tries on the same email */ $result = wire("session")->login($name, $password); if($result instanceof User) { $signedIn = true; } } catch(\Exception $exception) { return $exception->getMessage(); } } } return $signedIn; } Look at pw_login_throttle_api_nessage.png for the message it will return if many tries are made. Thanks hope this help.

Awesome, thanks @AndZyk

Hello @SamC, I have never used this option, but you don't have to and shouldn't edit the contents.css inside the wire folder. Instead you can define your own stylesheet in the field settings: This file can then be inside site/modules/InputfieldCKEditor/contents.css. Regards, Andreas

If you have the ability, on a new installation of ProcessWIre with only the ProcessWire Upgrade module installed, what happens? Are all the errors associated with one hosting provider? If so, have you inquired whether they have some security script running that could erroneously flag these websites when the ProcessWire Upgrade module is running? Just looking at all possible explanations. I know it can be very frustrating whenever someone has these types of issues. We will eventually figure out what's happening and correct the issue.

Boom. Perfect.

This is the only posting that I have seen that refers to that error:

yep, if you look at the first post error this is the module that was having the issue reported on it.

You can download and test from this address: GITHUB-SITE-BS4 and this MODULES - SITE-BS4 And I add a screenshot:

I have a similar module in use. For security reasons I verify if only one single user has the login email address in use. Emails aren't unique in PW like user names! Furthermore its useful to log login failures. Keep the ProcessWire Login Process safe!

Hi @noelboss - you might want to consider the issue of triggering a login attempt when there is no user for the entered email address:

Hi @ryanC, I recently created a profile and added something like this to admin.php: // Add Name Class Module if ( !$modules->isInstalled('BodyClass') ) { $modules->refresh(); } // This is Default require($config->paths->adminTemplates . 'controller.php'); If you sign in to Admin Panel then it should refresh all modules including your automatically ... In addition, you can protect the front file, such as home.php or basic-page.php, as follows: if($modules->BodyClass) { echo 'Your Code'; }

HI @Roberts R , Why you didn't upgrade your installation with the latest stable version of ProcessWire ? Could you give us more information about your server configuration ? PHP version, GD lib, etc ?

Any information on how to access this new module would be helpful? Thanks.

- Ditto - : PW 2.7.3

I just tested them, those listed under the "DONT WORK" are not working on ProcessWire 3.0.73. Now why... no idea. Edit: same behavior on ProcessWire 2.8.62

Another small update for Captain Hook. Now if you have Ryan's ProcessWire API Explorer module installed, the Class::method link will take you to the appropriate page of the API Explorer interface, rather than to the processwire.com API docs page. This means it will work offline, and of course also means it will be updated to the version of PW running on your site.

I decided to go ahead to do this so now you can specify exactly which pages will be exported. Hopefully others will find this useful also:

These tutorials by @Michael van Laar should help you get started https://digitalardor.com/articles/cms-content-blocks/ https://digitalardor.com/articles/basic-setup-for-content-blocks-in-processwire/ Also https://processwire.com/api/fieldtypes/repeaters/

Agreed. I'm still convinced that PW should be PHP 5.6+ as everything before that it unsupported (all support for previous versions ended over a year ago). At the very earliest, I think the limit should be 5.5. Edit: I actually think Teppo should run a weekly.pw poll on this...

I've just pushed a new version of the Create Users Batcher which adds proper CSV parsing (so you can have commas, quotes, spaces etc in other user fields) - thanks to @Rudy for noting this deficiency. I have also added the option to use JSON instead of CSV in case that is easier for your needs. Creation now also supports image fields so you can use a URL to an image to have that added to the user's page.

Think t Just making sure. Think maybe there may be some mileage in http://schema.org/MusicRecording as well.

Yes it is: http://modules.processwire.com/modules/pad-loper/ https://www.padloper.pw/

First, some background to lit a light. There are some functions in PHP that may produce unexpected results in special situations. This functions are used by PW core files and in user contributed modules. Some users may have problems with file upload (pdf, zip, image, whatever) if filename has non-ascii character at the first place. For example, if user upload a file named "år.jpg" (year in Swedish language), it is expected that PW would transliterate (transform) the filename to "ar.jpg", but because of the bug in basename() PHP function, the filename would become just "r.jpg". Nevertheless the file would upload successfully. But if the filename is "привет.jpg" (Hi in Russian language) the upload would fail. There are two ways how to handle this: Write and use custom functions instead of builtin functions Let end user fix that with proper locale Option 1. is used in some CMS/CMF (like Drupal), PW (Ryan) opted for option 2. After successful login PW perform a test and warning is issued in case of test failure. It is now your responsibility to set proper system locale. The locale is a model and definition of a native-language environment. A locale defines its code sets, date and time formatting conventions, string conversions, monetary conventions, decimal formatting conventions, and collation (sort) order. Those "problematic" builtin PHP functions are locale aware, that means they work as expected, if locale is configured appropriately. Locale can be set by the underlying operating system or in PHP. Because on shared hosting you don't usually have root access to the OS, the only option to set the locale is by using the builtin setlocale() PHP function. But, before you can use/set the locale, it must first be installed on the OS. On most unix systems at least some basic locales are already there, they are just not used. To check what locale are you currently using and what locales are available for you to use, create the file testlocale.php at the root of your website with the following content: <?php echo "<pre>Current locale:\n" var_dump(setlocale(LC_ALL, '0')); echo "\n\nAvailable locales:\n"; echo exec('locale -a'); Then point your browser to http://yourwebsite/testlocale.php If your current locale is "C" (and you are on unix), then you will probably get warning after login to the PW admin. What you want to do is change the locale to something that has "UTF-8" or "utf8" in the name of the available locales. In your case you would be looking for something like "sv_SE.UTF-8" or "sv_SE.utf8". Now, there is a chance that Swedish locale is not installed. You can ask your hosting provider to install it for you or use some other UTF-8 locale. On most unix systems I have seen, at least "en_US.UTF-8" or "en_US.utf8" is installed. If even that English locale is not available, then look for "C.UTF-8" or "C.utf8". And this is what you have to use as parameter in the setlocale() call: setlocale(LC_ALL, "sv_SE.utf8"); You could actually "stack up" multiple locales and one will eventually work: setlocale(LC_ALL, "sv_SE.utf8", "sv_SE.UTF-8", "en_US.UTF-8", "en_US.utf8", "C.UTF-8", "C.utf8"); Now, regarding where to put that setlocale() call. If you are not using PW multi language capabilities (you don't have Languge Support module installed), then you place setlocale to /site/config.php. That's it. If Language Support module is installed (PW checks for that), you have two options: Translate the string "C" in LanguageSupport.module for each installed language Put setlocale() call in /site/init.php My preferred method is option 1 and this is what PW (Ryan) recommends. See https://processwire.com/api/multi-language-support/code-i18n/ for more info on translating files. Option 1 allows you to set different locale for each of the installed language, while option 2 allows setting of one locale for all languages. PW will also provide links for the files that needs to be translated in the warning message. Ryan just pushed an update that makes it use the locale setting on the frontend when using LanguageSupportPageNames module (until now just language was changed, but not locale). Also setLocale() and getLocale() methods are added to the $languages API var.