netcarver

PW isn't a system that automatically collects emails, so I actually have no idea what you are talking about now. If you didn't install a contact page, who did? The link you posted above doesn't seem to work for me, could you post the actual screen shot you took here please.

Did you install a module, or follow a tutorial somewhere to get your contact form set up? Are you using formbuilder or something like that?

If you are talking about displaying all the emails in a table, then you can just use the PW API to fetch the children of the contact form page and display them in an HTML5 table. If you can let us know what contact form you are using, maybe we could point you further towards a solution. Also, could you just post the screenshots here in the forum rather than links to screen shots stored elsewhere.

Hi @Norman_12 Can you explain what you mean? What submitted email?

You may want to check your droplet IP address is not in a spam blocklist somewhere as well, "Relay Access Denied" Kind of sounds like an auth issue. Updated to add: there's a blacklist checker here you could try. DMARC, DKIM & SPF set up on the DNS service?

Is your intent to use your self-hosted service for email sends only? Or receipt as well?

Hey @benbyf I don't run my own servers, but there is some info here about DNS records for people doing self-hosted stuff... The Digital Life on YT: There are other videos on that channel about self hosting email servers - but I note he's recently given up self hosting mail services.

Ah, in that case, log in to the admin area of your site as a superuser and scroll down the page list until you find the "Trash" can... Now locate the page you deleted and hover over it. You should now see the restore option... Hope that helps.

So isn't it in the Windows Recycle bin?

Do you know what the location and name of the file you deleted was? Also, is this site hosted on a Windows or Linux machine?

There are several ways you could approach this. You've mentioned one already - using a page per check-out and keeping these as children of the book being borrowed. This is a very reasonable approach and you can get the count of the child pages very easily via the PW API. Each "checkout" page also has it's created date that would track when the book was borrowed. You could also use the FieldtypeTable that's part of ProFields package by Ryan. It's not free but you get access to a very nice package of additional field types. That way you could keep check-outs as a field of the book's page. There's also a way to count the rows in the table via the API IIRC. Another way to do this without going Pro would be to use a simple textarea and enter a new formatted line of some kind each time the book is checked-out, but that is potentially far less flexible in terms of searching the checkout history. Working out how many times a book is checked out is a matter of counting the lines in this field.

As your site is essentially running stateless (without cookies or possibly having state encoded into get values holding IDs etc) and no operations require authentication, I think there's very little risk for you. If it's just a contact form or something of that nature, I am happy to (and do) turn off the CSRF protection and then add a honey-pot field + Turing test field to deal with spam. Zero spam so far. I can PM you a link to a site set up like this if you want to take a look. Check out OWASP on CSRF for more information.

@johnstephens Ok, so it's still your function (closure) so it's probably not being overwritten, and that seems right. DV-JS's point is really good. You need to turn off CSRF (≠ XSS) protection in your form's settings as anything that uses $session->CSRF will turn on the session cookie again. See the documentation for the sessionAllow variable in wire/config.php for more information.

@johnstephens Ok, so if you dump the values of $config in somewhere like ready.php, are you still seeing that $config->sessionAllow is a function? Just wondering if it's being overwritten somewhere. I'd also grep the codebase (particularly in site/modules) to see if sessionAllow is being set anywhere unexpected.

I think config.php is the correct place. I use that technique on my site at pwgeeks.com if you want to check it works there. Here's the code I'm using... $config->sessionAllow = function($session) { if($session->hasCookie()) return true; if(!isset($_SERVER['REQUEST_URI'])) return false; // CLI invocation of script? if(!empty($session->config->urls->admin) && strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; return false; }; Have you made any changes to the example function that was linked above?

I generally use this with WiremailSMTP and haven't really tried it with other send methods. Which WireMailer are you using?

Highly recommend Gumroad for selling this. It takes care of all sales tax nightmares and can automatically generate a license key per sale. Personally I wouldn't try adding license key checking into scriptable code (like PHP) as people who are going to cheat you are just going to edit the code to remove the check anyway, or just have it return true etc. Where the key can come in useful is for access to value-added features like support, so you ask "What's your license key" as part of the user's access to your support mechanism (forums/email etc)

Sounds like a possible bug in FieldsetPage - can you open an issue for this in the issues repository please.

Hi @rash You will need the salt from the original config file in order to allow existing users in the DB to log in with their current passwords. However, you can use the Recipe here for resetting an admin account password: https://processwire-recipes.com/recipes/resetting-admin-password-via-api/ That should, at least, let you log in as admin and use the interface. You might also try installing the ForgotPassword module in order to let other users reset their passwords.

You're right that this is by design and is not best practice. I actually don't know there is any proper way of doing this, but my first port of call would be to try hooking the session::loginFailure() method and then looking at the reason argument. Check out wire/core/session.php and look at the code in login() and the ___loginFailure() hook.

Yes, a long time ago. There are probably better options out there (services) and I think there is another module - though I have never used it: https://github.com/andreadewey/ShortLinkGenerator

@kater Hi there, could you try disabling the Nifty module (just disagree with the license) just to see if that has any bearing on the situation. If it does, you can get support in the VIP forum for NiftyPasswordPlus. If it doesn't we will have eliminated part of the complexity around what could be causing this.

Hi @CachePuzzles, welcome to the forum. That's way more time than it should take. Are you using one of the WireMail series of modules for your emails? If so, which one? I've used WireMailSMTP in the past to send via my own email provider's SMTP server and it works very well (although SMTP can be difficult to setup,) usually taking less than 10 seconds for email to arrive in my inbox sending that way. There are also WireMail modules for SendGrid, Mailgun, Mandrill, Swift, PHPMailer and Amazon SES to name a few. You can lookup more wiremail modules here.

If anyone's looking for a shortcut to simplified/extended password reset features, there is a commercial extension module available.

@Confluent Design Nothing amazing I'm afraid, you'll have to edit the included CSS file (InputfieldStreetAddress.css) - or override the selectors it uses with your own in another CSS file that gets loaded later.