teppo

Quick search for this particular error from the forum returns one thread: https://processwire.com/talk/topic/5361-apache-recursion-problem/. I'd start from there.

@Stefan: error message itself is a sign of CSRF check failing. Are you seeing this error before or after login attempt, i.e. can you still type in your login credentials and this just appears after or are you unable to see the login form in the first place? It's possible to skip CSRF checks entirely by adding "$config->protectCSRF = false" to your site/config.php, but I wouldn't recommend it in the long term -- this is a security feature after all. There are also some things you could try here, such as checking that you've got necessary directories, as discussed here. Please let us know if the issue persists. Providing any additional info (such as is there anything that could've caused this, any apparent change to your site lately, have you switched servers etc.) could also help diagnosing the issue.

Why aren't you just adding template file to each track and in there rendering the lyrics? Your modal link could point to the URL of the track page itself and then you'd just need some simple JS to open that as a modal window (or popup, whichever it is that you want). .. and if you need to stick with current structure, you'll have to append track ID or some other method of identification to each modal divs id attribute (such as id="lyricPopup1234" where 1234 is ID of track page) and matching ID to each modal link (data-reveal-id="lyricPopup1234"). Based on your attributes there I'm assuming that you're using this plugin. They've got pretty good instructions for using the plugin, so please take a closer look at those first. Edit: just saw what Soma posted in your other thread about this. Makes sense. Just stick with what you've got here

Wait, there are other editors besides Emacs?

I've been thinking about something along these lines too, though more like "custom module paths", i.e. an option for adding multiple module locations. Either way this would be nice

@Pete: not saying that it would be a bad idea, but there are benefits to separate site too. First thing that comes to mind is that external sites with PW focus may actually make us look bigger (not that size would really matter, you know), but this could also promote healthier ecosystem; if there are existing sites that focus on PW topics, it's much easier to setup one of your own, which IMHO benefits the project itself in the long run. All in all I'd love to see more diverse ecosystem and don't think that we should attempt to gather everything in one place.. apart from the things it makes a lot of sense for, such as the modules directory, of course

Awesome idea -- there's definitely demand for this. Please keep us posted on your progress! Seems like you've already got some great ideas there too. Might want to cover various caching settings and modules too, and of course classic tasks like "how do I create tags in ProcessWire", just to add something

I'm assuming that this is a front-end form and submitted values are somehow converted to pages and/or page data. If that's really the case, those values really need to be sanitised when submitted, but including HTML Entity Encoder textformatter is still a good idea as an additional precaution -- unless, of course, your field has to be able to contain HTML. For sanitising user input $sanitizer->textarea() is one option, other one being $sanitizer->entities(). First one strips tags but leaves entities intact while latter encodes all entities, including "<" and ">": $foo = "<b>bar</b>"; echo strip_tags($foo); // outputs bar echo htmlentities($foo) // outputs <b>bar</b> This pattern you've mentioned is probably a front-end thing? In that case it can be used as a way to signal to users what kind of values are valid, but you should never really trust it; it's very easy to circumvent things like these. Note: you could probably just add a space in your pattern, like [a-zA-Z ], to make it support those. I'm not sure if this makes sense, though; user still wouldn't be able to type in dots, commas, lines, underscores, non-ASCII characters etc. etc. This method seems complicated and prone to errors, so I'd probably skip it altogether, relying on the server side sanitation instead.

To be honest I'm not really sure what you're trying to achieve here, but what I'd probably consider (without fully understanding your situation, so this might be completely off!) would be serving the page user is asking for without current "render home page if this isn't an AJAX request" trick. This way there shouldn't be any caching issues and as an added "bonus" all sorts of crawlers, users with JS disabled, screen reader users etc. could still use your site. Assuming that pages requested via AJAX (using this clientside routing you mentioned) can be directly mapped to "real pages" by their URLs (and are, in fact, identical to those) I can't see what the problem with that approach would be. Unless there's something on your home page that is required for the rest of the site to work properly, i.e. other pages actually only contain part of what the user should end up seeing, in which case I'd consider fixing current template structure to take care of that by including common header/footer files etc. if the request isn't AJAX. Anyway, I'm sure we could come up with various tricks to enable caching here (been there, done that) but first I'd really like to understand why this is even necessary in the first place. There's probably a reason, I'm just not seeing it right now

You'll probably want to make this module (if it's not already) a Process module. ProcessHello is an example of this module type; they're essentially modules that add a page of their own, usually under admin, and use that to handle incoming requests, whether GET or POST (and respond to those accordingly). Depending on your use case it might make sense to bundle "regular" hooking module and Process module together, so that the module attaching hooks doesn't need a page of it's own and the Process module isn't loaded unnecessarily before it's really needed. Not a huge difference, but just wanted to mention this option. In some cases this can also make the module "architecture" more sensible, separating different types of features. As a concept this is very close to controller actions, really; in Zend Framework I'd have IndexController with methods indexAction and actionNameAction, in ProcessWire I've got ProcessMyModuleName.module with methods execute (requests to the initial URL of that page, same as indexAction in Zend Framework) and executeActionName

I used to have this printed out on my desk, but eventually just gave up. Every single attempt to implement something properly ended with Microsoft pushing out new (and worse) version of Outlook and us doing tons of extra work "fixing" existing newsletters. The uglier the implementation, better it works and more future-proof it is. It's a screwed up world out there. Anyway, I've also been meaning to properly check out responsive newsletters and see if there's something to that already, but old wounds still haven't quite healed.. and it's pretty hard to believe that things would've improved that much in such a short time

Your PHP code isn't interpreted as PHP, but sent directly to browser. If another PHP file works fine, this does indeed sound strange. Just to make sure, is this a Linux host, is the web server Apache and have you had any issues with .htaccess (or mod_rewrite) before on this server? What about PHP version, could you check that too, just to make sure that it meets the requirements? Also: are you aware of anything else that could be somehow off with this host, i.e. safe mode turned on, suPHP in use or any other "non-typical" detail?