teppo

There are two potential issues here: your form doesn't seem to have CSRF protection in place and the lack of HTTPS connection would make it possible for someone to grab the credentials from a request, but other than that this looks fine to me. My usual advice would be not to do this (use built-in login form instead), but of course there are cases where you don't want to do that. For those cases check this post out for the CSRF protection and enable HTTPS. If the price of the SSL certificate is an issue, check out Let's Encrypt; their free certificates are pretty awesome. If your host doesn't allow you to use these, that in itself could be a good reason to switch hosts.

Note: this topic has been moved to the Module/Plugin Development subforum.

It's a real shame that your site got hacked, but this is definitely something we can learn from, so thanks for sharing it. Shared hosting and lax file permissions are an easy way to get into trouble, but I'm still quite curious about how exactly the site was hacked. From what you've mentioned here (uploaded files, etc.) it kind of sounds like the login credentials might've been compromised, or did you perhaps have something on the front-end that could've caused that? Of course if it really was an "inside job", i.e. if the site was attacked by another user on the same shared server, the files inside /site/assets/ could've been planted there manually. Did you have anything else installed on the same hosting account, another site or web application or anything? If you do find out anything else, please let us know, but just in case: if it turns out that this was actually a result of a flaw in the system itself or perhaps a third party module, please let Ryan know of it before posting to the public forums. I'm extremely confident in the security of the core and have a lot of trust in most of our third party modules, but there's no guarantee that nothing will ever go wrong.

@SteveB: thanks for sharing this. Generally speaking I'd advice against a setup where the site can be accessed with both www and non-www domain – for reasons that include SEO considerations, caching, and consistency in general – but there are many situations where multiple httpHosts can (and should) be present and this kind of situation might occur, in which case it's good to keep this feature in mind

Hello there and welcome to the forum! We do have site profiles for ProcessWire, so you might want to check those out. Generally speaking they're intended as a "starting point", and you will no doubt have to dig into both front-end and back-end work, at least to some extent. You might also want to check out our markup modules, which may provide some helpful shortcuts for your site building. Since jQuery is just a front-end JavaScript library, you can easily include it on your site, just like any other 3rd party JavaScript library out there. Same thing goes for front-end frameworks like Bootstrap or Foundation: ProcessWire itself doesn't generate any markup for you, which means that you can use any given framework to build your site. ProcessWire is very different from WordPress, and developing sites with ProcessWire is similarly different. I would suggest giving it a try, but if you're looking for a solution that lets you simply start with a complete theme, install all required features as modules, and never touch code or markup.. well, in that case ProcessWire probably isn't the best option for you. On the other hand if you're interested in learning how to build actually working sites and you're not afraid to get your hands dirty every now and then, you'll no doubt fall in love with ProcessWire and the awesome developer API it provides Hope this helps a bit.

Was literally thinking about the same thing just yesterday. Solved it by a combination of JavaScript targeting only links to assets and instructing users to apply target "_self" to file links they don't want to open in a new window/tab. That's definitely less intuitive than having target "_blank" automatically selected, but does the trick Another option would be injecting JavaScript for when Page Edit Link is rendered and handling this there. In that case it would probably make sense to track the change event of the file input and act on that, perhaps combined with a check that avoids changing the target value if the user has already changed it manually. Just for the record, it would be nice to see a built-in setting for this. I'd assume this to be a relatively common need.

For the time being it's fine to use 2.7.2 – that's our latest stable release after all – but if you're just now starting a new project, and especially if it's going to be under development for a while, I'd strongly suggest basing it on either 2.8 or 3.x devns. If you're feeling slightly adventurous and choose to go with 2.8 or 3.x, the choice between these two depends mainly on whether you plan to make use of external libraries etc. in your project. 3.x includes namespaces, 2.8 doesn't – other than that they're essentially the same and will remain so thanks to the fact that Ryan has mostly automated the process so that updates to 3.x also get applied to 2.8. While namespaces are cool for serious development and can make it a) easier to pull external libraries into ProcessWire or b) pull ProcessWire into other projects, in my experience most site projects don't benefit much from them. If the idea of namespaces makes you uncomfortable and/or you have no idea what they are, it's absolutely fine to go with 2.8. For the most part the built-in FileCompiler in 3.x hides namespaces from plain sight, but if you just want to build a regular site with ProcessWire and don't want to worry about all that namespace stuff at all, you'll probably feel more at home with the 2.x branch

It would be good to see some code here, i.e. what exactly you're doing, but based on this comment it sounds like you're caching all the books with the same name and thus always overwriting previous one with the next one. Does this sound familiar? If this is really the case, you should either generate unique name for each cached portion of the content OR cache them together instead of book-by-book. Also: if you're using a relatively new version of ProcessWire, I'd suggest looking into the $cache API variable. MarkupCache is still valid approach, but $cache is a newer solution and widely used by the core itself. Additiionally it provides improved tools for invalidating the cache, which could come in handy here.

So this is where the zombie apocalypse begins. Seriously speaking: for-page-20044 is the parent of repeater items connected to page 20044. The parent of this page should be named after one of your existing repeater fields. Do you have page with ID 20044 in the system and does it have repeater fields? What about those other pages you mentioned? If, say, you have a repeater parent called "for-page-12345" and there's no page with ID 12345 in the system, then this could be a sign of cleanup not working as expected. On the other hand if a page matching each repeater parent does exist, this probably just means that you've got hundreds of pages using a template with at least one repeater field attached. Just an idea, but perhaps you could post a screenshot displaying these pages in the admin. These things are sometimes difficult to explain with text alone

Thanks for letting me know.. and good to hear it's working now

Thanks for reporting this, @grimezy! One issue I can see right away is that date_diff() can indeed return "false" on failure, and this case is not properly handled by the code visible above. Real question, though, would be why this happens. Mostly guessing from the error you're seeing and the code visible above, most probable cause would be some kind of an issue with $login_date, which in turn could either mean that login_timestamp row in database is empty or contains something unexpected.. or it could mean that $date_format is somehow broken. I was unable to reproduce this issue based on a quick test and I'll have to step away for a few hours now, but I'll try to debug this further (hopefully) later today

Agreed, that makes a lot more sense. I'm one of those developers who tend to lean towards the simplest possible implementation and as few external dependencies as possible, even if that means writing a few extra loops, but I can definitely see the value in this

Fun series, but every time someone blurts out something like "shorter code is better", I get the feeling that they've never heard of Perl. Granted he did claim that this is almost always true, but still Say hello to this actual solution to a round of Perl golf back from '02: $_=pop;s#.#push@;,$;until$;++&$;;$@[$_]^=$;/$_&$&for@;,$;#eg;print@@,$/.

I'm mainly thinking about the way ProcessWire makes it possible for third party modules to alter the source of a page, inject their own scripts or styles, etc. While this does require a lot of trust in installed modules, it's also something we wouldn't want to disallow. Inputfields are another thing consider: many third party inputfields rely on existing libraries, in which case the implementation details are more or less out of our hands. Unless I'm missing something obvious, CSP would mostly be useful if users were able to inject their own scripts or styles for other users to see. In order to do that, you'd either have to be a superuser and use some rather specific features to achieve this, or exploit a third party module that allows this. Latter option is absolutely something to consider, but the first one not that much: generally speaking we consider users with access to the admin interface "trusted"... and superusers even more so. While we could introduce a method of "registering" embedded content with the system, I'm not entirely sure if that's worth it. It could make the lives of perfectly legitimate developers more difficult, while the benefits are — in my opinion — somewhat questionable. It's also good to keep in mind that this isn't something that would protect you from malicious / hacked third party modules: a module could simply hook into an earlier (or later) point in program execution and override any CSP rules you've got in place. That being said, I'm not against the idea of implementing this as a configurable option. It would no doubt be possible for ProcessWire to generate nonces for any inline content it requires, and as long as this would be a configurable setting, it shouldn't come as much of a surprise if some third party features stopped working afterwards. I don't see this as such a big thing and I'd imagine the potential use cases to be limited, I for one would be OK with this as long as it doesn't needlessly complicate things ?

What Adrian said If the question is whether I plan to release a separate 3.x version with namespace declarations in place, I honestly haven't even thought about that yet. On the other hand I do intend to support both 2.x and 3.x for the time being, so if this module isn't playing nicely together with the compilation feature of 3.x, please let me know.

Inline scripts are used widely in the admin interface, so this sounds like a case where you wouldn't want to enable CSP. It's fine to enable it on your front-end if it's something you want, or you could use the unsafe-inline keyword to get past this issue, though. CSP is well-intentioned, but some of it's rules don't make that much sense in certain use cases, and our admin interface is in my opinion one of those cases. On the other hand ProcessWire doesn't dictate any of the markup you see on the front-end of your site Note: this topic has been moved to the security forum.

That's not an option; in this case the field becomes unusable. In my opinion this is correct behaviour: not having anything defined here sounds more like a half-configured field or a mistake than something the developer did intentionally and knowingly.

A while back while importing some 10k pages from another system I wrote an import script that would sniff the extension of the file, and if it wasn't yet allowed, it would first add it to allowed extensions and only then add the file. In this particular case I knew that all files were "safe", but there were dozens of different extensions to account for. To me this idea seems to make sense: as a developer I should have the option of saying that it's safe to insert "anything" in this specific field. A warning would still make sense, considering that not everyone who has access to these options will understand the risks involved. On a related note, I'm wondering if supporting regex would make sense here? Seems to me like one way to support just about every imaginable requirement in a future-proof way. It might confuse some vs. the old * trick, but then again, simple regex is not that much more difficult; just prefix the star with a dot

Thanks, that helps a lot. I'll get back to you if I get green light for the project. Took a quick look at the API docs, and seems like the channel implementation is almost identical to regular one, so probably not a big deal

Hi Antti! I'm currently looking into a project that could be a potential use case for Padloper, but this being a local client there's one rather specific requirement: support for Paytrail – or perhaps Checkout, though I'm not really familiar with that one. Is there any chance that you might have something like that already available, or do you have any idea how much work it would require to set it up? Thanks in advance!

Agreed that we don't really need the wiki that much. Still, I'd suggest rerouting the queries there to some other location on the site. Having an empty directory listing there looks a bit weird

Sure – where I work at we did exactly that, and haven't looked back since. First of all, it's important to understand that at it's core ProcessWire is a (web) application framework. We prefer to call it a content management framework, but that's not very far from what most web applications do: they store, process, and output content. The way I see it, the main difference to so-called traditional frameworks is that modelling and handling data is a built-in feature, not something you have to reinvent on a case-by-case basis. I have rebuilt a couple of old projects from the scratch using ProcessWire, and in all of those cases this has saved me a lot of time and made most of the model layer obsolete. Before we started using ProcessWire we were doing sites with another CMS and custom applications with Zend Framework. At the beginning I had this idea that we would use ZF for "apps" and ProcessWire for "sites", but in just a few short months we realised that there just wasn't anything we could achieve with ZF that couldn't be done, usually with less work, with ProcessWire. Sure, sometimes we pull other libraries into the mix, but that's not a shortcoming; in my opinion it's just good design Regarding some of the things that have been mentioned here: One thing I was originally missing from Zend Framework was a clearly defined structure. Built-in "one file per template" concept is great for simple sites, but that's just about it. This is why I built the original version of my MVC project. It's not perfect, but it has served us well for years. To get most out of ProcessWire you really should be using it's data modelling abilities. Sure, you can still mock up your own data structures and write SQL to fetch content from the database etc. but that's kind of missing the point: ProcessWire makes data modelling a breeze and the selector engine is both flexible and secure. Some users prefer to build custom management panels, but in my opinion that's another thing you should try to avoid. ProcessWire's admin GUI is flexible and extendable (see Process modules), and again: in most moderately sized projects it can easily save you days of work. For routing you can use page URLs, but I'd also suggest looking into URL segments. For me, coming from the world of Zend Framework, templates are a lot like controllers and URL segments make it easy to implement the concept of actions Try not to invent your own access management system. ProcessWire has a very good implementation of RBAC already in place, and if you need more flexibility, I'd suggest looking into modules such as Dynamic Roles and/or User Groups. Rolling out your own solution is risky, tends to cost a lot, and just generally speaking is a very bad idea. Form validation has been mentioned twice here already. I don't have much insight into this, except that in the beginning we used to build forms using Zend Form, which has it's own validation built-in. That was always a bit tricky (not because of ProcessWire), and these days we use Form Builder for pretty much every form-related need. Sure, it's a commercial module, but it has saved us so much time that the price is absolutely not an issue. In my opinion the answer to your original question is yes and no: ProcessWire can't substitute an application framework because it is an application framework

@bernhard: exactly the question I've been meaning to ask too! Syncing a site to another location periodically and preparing a failover mechanism for static data is one thing, but I'm also curious about how data gets merged back and forth in a situation like this

this is not possible with no existing system on the web..... Actually I believe @JRW-910 was referring to the users not having to know any coding. Please correct me if I'm wrong, though In addition to what @mr-fan said above, I'd suggest taking a closer look at the devns branch of ProcessWire. This is the future 3.0 version, still in development, and among other features it includes a kind of a front-end editing support. Perhaps not exactly what you were looking for, but this could come in handy anyway. Other than that, Fredi provides front-end editing support right out of the box, and you can always embed admin views into the front-end by applying "&modal=1" to the URL of the edit view. This is all good to know in case you don't actually require a fully customised front-end editing experience, but would rather use the one ProcessWire provides out of the box. If it is a fully customised front-end editing feature you're looking for, that's relatively easy to achieve via the API. ProcessWire is awesome for this kind of stuff, but again: unless you really need a fully custom solution, I would suggest looking into the existing solutions first. For an example the FrontendUser module mentioned above is definitely a viable solution for the user registration part For managing permissions ProcessWire makes use of a simple role-based approach, but if you need something more specific, here are a couple of alternatives: Dynamic Roles provides a very flexible method of defining new "dynamic roles" in addition to the real ones based on various factors. There's very little in terms of permissions you can't achieve with this module. User Groups allows you to define page-specific or branch-specific permissions, and adds the new concept of "user groups" for grouping users together, regardless of roles they might have. Page Edit Per User does what the name says: assign edit access to individual users on a per-page basis. This module is a bit older already, so not entirely sure how it works with the latest versions of ProcessWire, but it's also a relatively simple one, so if it doesn't work it's easy to cook up something similar.

For the most part I agree: classes don't have actual semantic meaning, so technically speaking they're fine, and I believe we're pretty much on the same page regarding pseudo elements too. It's just that I've recently started to emphasise pseudo-elements over classes whenever it makes sense. There are many cases where it doesn't make sense, but for something as simple as alternating background colors for predefined elements it fits the bill perfectly. I've also grown tired of trying to guess which classes I should add to my markup in order to make it easy enough to style, and I strongly dislike having to change any aspect of the markup (including generated classes) if I later on decide that I need to do something purely style-related – such as make odd items have a different background color. Pseudo elements are awesome for separation of concerns, and they can reduce the clutter quite a bit. While classes rarely add a considerable amount of extra weight to the document, unless we're talking about a serious case of classitis combined with extremely large scale use, that's another (however minor) argument against them: why add something that isn't required in the first place