Leaderboard

Did you enable all the noise blocking rules in htaccess? https://github.com/processwire/processwire/blob/5094a8ce8eb553ef2cf5a1c928fef647a2fbd075/htaccess.txt#L246:L294 I have no experience with it but it sounds like an easy and good thing to do? https://weekly.pw/issue/315/#latest-core-updates-processwire-3.0.157

You won't believe it but this is really a big issue in some kind. Not really in terms of ProcessWire but in terms of devs. I recently got part of a team to manage existing ProcessWire websites and... yes... no $sanitizers were involved at all. Can't and won't blame anyone for this. Ok... sure... I could but I won't. My 2ct-opinion on this: That's why I call this the most awesome community ever! (This is a USP, take a note!) We could blame each other in some kind or lay open things that don't match/work at all, yet... after some rumbling everything most of the time turns to the better. And to be fair... I have never ever encountered anyone assaulting anyone here. Rough wordings, maybe. Yet... being direct is needed sometimes. Thank you @MoritzLost for the insights and even for starting this discussion in some way here. (yes... that's my personal opinion!)

Definitely yes ? At the moment no, but I plan to create a video that shows the most important parts. The ProcessWire snippets are available here: https://marketplace.visualstudio.com/items?itemName=baumrock.pwsnippets (also on github of course), but the RockMigration snippets are at the moment only locally available until I've used them a little more. Thx for that feedback. That's absolutely understandable and a valid point ? Update 2023: I've improved a lot here and try my best to not introduce any breaking changes. My modules follow semantic versioning, so a major version bump indicates a breaking change so that everybody is aware and can check if that is a problem in his/her specific situation. Also there is the rock-monthly newsletter now to communicate the most important news.

I agree it is unfair to make comparisons like this. I also don't think it's very nice to come to an open source project's support board and try to convince people to use a commercial CMS. Maybe the fact that a comparison can be made at all is a compliment. But Craft is a big commercial project with a sizable team and lots of resources and money behind it. ProcessWire is the opposite of that and the comparison seems inappropriate. But since you've stated this is a comparison, I'm not sure where the comparison is — you've focused exclusively on what you think Craft does better (by your own preference), but haven't made efforts to point out the areas where PW does better. So it comes across a little bit as an advertorial for large commercial CMS at the expense of a small open source project. Throughout you are stating a preference for something in Craft and claim a similar feature in ProcessWire is "not well thought out." This is wrong. A more honest statement would be that you and I clearly have different preferences, or maybe you don't fully understand something. But that does not mean that something that differs from your preferences or understanding is "not well thought out." I would never commit something to the core that hasn't been really well thought out, that's something I take really seriously. While much of Craft doesn't suit my own (and others) preferences, and may not be "well thought out" according to how I think things should work, I'm not going to join their forum and tell them it's not well thought out. That's because I respect them and trust that it's well thought out, according to their needs and preferences. So when you start telling someone that something they've put a lot of work into isn't well thought out, that's akin to saying that you do not respect them. I make no claims about being perfect at anything, and there is room for improvement in everything. What I take issue with here are the broad, subjective and largely false generalizations, and that's what I'm replying to. I'm also concerned that anywhere that you've quoted me, you've taken a statement by me out of context, extrapolating it as proof for an unrelated conclusion you've made. For example: In that link we are not talking about ProcessWire at all, and instead are talking about the processwire.com website in development, NOT the CMS. Why would you say I'm "opposed to the idea" of accessible development? This is something I'm interested in and passionate about. I don't understand why you are quoting me on one thing and saying another. In that link, I'm writing about a module called ProcessUser and something that is imposed upon it for a specific security purpose, unique to that particular module, and no other. But you have used my statement as proof that building custom features in ProcessWire isn't encouraged or supported. Nothing could be further from the truth. I have never had such a thought. My thoughts and intentions would be exactly the opposite. What you consider an advantage, I consider a major disadvantage. PW puts nothing between you and PHP, by design, that's a major advantage. I certainly would not be happy with Twig integration being a default. Clearly you like using Twig, which is fine for you to have that opinion, and I think it's perfectly fine for Twig to be an option. But I definitely wouldn't want to standardize upon it. Maybe it doesn't suit your preference, but I hope you can appreciate why we don't do things like that in PW. You are comparing two different kinds of caches. You are talking about a template engine cache. In PW there is no template engine, so likewise no template engine cache. Most of the time you would never need such a cache in PW at all. The $cache variable is something different, and while it can also cache markup, it is much more simple than you imply. PW's API is not string-based. You are writing about selectors (and specifically selector strings), not the "API". ProcessWire lets you specify selectors as strings or as arrays. Most prefer to use strings due to the simplicity of it. But this does not mean that arrays are not reliable. And if you use arrays, then there's no need to do value sanitization. But the majority of the time you are using selectors, you are not injecting user input into it either, so I would consider selector strings to be a major advantage for PW the vast majority of the time. And for times that it's not, you don't have to use it. The problem with chaining methods for this is that they are live code, you can't store them. Perhaps it has benefits in Craft, but they would not be appropriate for PW. In PW selectors can be specified as arrays or strings, and in cases where you want to separate the query property from the query value, then that's why we have the array option in PW. And yes, they are reliable, despite your claim that they are not. The same is true in PW. Fieldtypes build the query and sanitize/validate the value to be queried. The only thing PW asks you to do is IF you are using a selector "string" that ALSO happens to contain user input, then just sanitize that user input part with the selectorValue() method. If you are using an array, then such sanitization is already done for you. This has nothing to do with details of a fieldtype, which will do its own validation/sanitization. Saying "clunky" is a subjective and hardly fair statement to make. What might be clunky to you is optimal to others. You are writing specifically about the file translation system, so the whole purpose is to provide an interface to translate your site php files (primarily template files). The interface is geared to focus on that task only, and that's the point of it. I understand you value more layers between things (like with Twig), but I always prefer fewer layers, a more direct approach, so you'll see that throughout PW. If I'm using a file translation system, I want to know what file I'm working with and I want to be able to tell the translator what file to work with. That my preference, and I understand you have a different one. Of course you can, that's who it is for. Yes they are grouped by file, and that's how I prefer it, and I have never had a client have a problem with that. If you have some preference to keep translators/clients out of the admin, you can also ask them to translate from a spreadsheet (exported from PW) and PW will happily read that in and use it. None of those 3 statements is true. Translations may be stored in JSON files, but they can be exported/imported (all files at once) to/from CSV files. Translation files are not stored in "random" locations. They are stored with the language's files, which is a static location identified by its ID. Adding translations in the code editor is not impossible, because where else would you add new translations, if not in the code? If you need a new translation, go ahead and add your __('text') in your code, and it immediately becomes available as a translation. You are welcome to your opinion, but as someone that put a lot of thought and effort into field translations, it's hard for me to take your opinions seriously when you state things like this. Nothing about them is "tacked on" or "not well thought out", quite the opposite. So to me it seems like at worst, you don't understand what you are talking about, or at best (and most likely), you just have an alternate preference. This is fine, but I don't think that's obvious to everyone reading. So please don't make statements like "not well thought out" when you really mean that something doesn't suit your preference, or maybe you don't fully understand it. I appreciate examples but I'm not aware of any field where you need to "add the second language's field manually". This does not sound at all like PW multi-language fields. If you are talking about PW at all, perhaps you are talking about the "language alternate" fields option? If so, this is an option that is there to provide additional flexibility for specific cases, but it is almost never used in my experience. Please don't use it as a foundation for any comparison, as its borderline deprecated at this point and I don't expect many will ever use it. This conclusion is the opposite of the truth. The fact that PW doesn't impose a specific framework upon you means that all options are open. Anything is available to you. It is more open, not less open. It's you and PHP, and anything you can run in PHP you can run in PW. ProcessWire feature approach is built around constant improvement. It is driven by the community and the needs of clients. The development of PW has always followed this approach. I have a job working with clients just like most PW users and so I develop according to what's needed and when. Most of my income comes from client work. I work on the PW core for free, so development usually has to have some crossover with the other projects that I work on. Despite being open source and largely unfunded, the fact that PW and Craft can end up with apparently similar capabilities and feature sets—and the fact that they can be compared at all—I would consider to be a sign of efficiency and that we are doing something right. If you consider our approach "chaotic" then fine, but the accurate terms would be "flexible", "sustainable", "consistent" and "continuous". The approach been very successful for PW as a project. And PW is also one of the longest lasting projects in this area (open source or commercial), and will continue to be because it's not built around money. I don't add features without completely thinking them out. That's silly, why would we do that? I would never commit something to the core that has not been well thought out. I don't understand why you would say this unless you just don't understand it. Nothing committed in the core has been abandoned. Elsewhere, I've abandoned a ton of code, but most of it has never been seen by anyone. When I commit something to the core, I've spent a lot of time working on it and I'm also committing to supporting it, long term, for as long as there is value in it. That's another reason why I take a lot of time to think through anything that gets added. You are welcome to say that you have a different preference, and you can I clearly have different preferences, but please do not suggest something is not well thought out because that is not true. Well, I'm glad you think there are "hundreds" of features that look cool... though not well supported? I don't know what we're talking about. False. The only bugs that don't get fixed are those where they cannot be duplicated, or that don't have a clear solution and seem to be isolated to one person. And I don't know what you mean about "don't work well with each other and so on". ProcessWire's core focus is already a limited feature set, where much is left to modules. The aim is to have everything you might "need" and do it really well, but save things you might "want" for modules. This is one area where it certainly does help to have a big commercial company behind it, with full time documentation writers and such. While they do have a structure and hierarchy, I understand it may not be exactly the way everyone might want it. The site search engine is actually quite powerful and searches the API and all documentation pages, so I recommend that when you want to find something specific. This is fair, and it'll continue to be that way, the blog posts can do heavy lifting in between the time that features are added and documentation is updated (as does this forum). The blog posts do also end up as the linked documentation for features in some cases. I'm okay with it. I understand that if we were a big company it might be odd though. I don't put efforts towards pretending that PW is a big company, I work within the resources we have, putting most of it towards where it counts and less of it towards pleasing critics. The aim is that all versions are compatible, meaning you can safely upgrade from any older version to any newer version. I don't know of any other projects that do this as well as PW, so I would consider it a major benefit. If we get to the point where this is regularly not the case, then we likely would adopt semantic versioning. But the need isn't there at this point in time. Close, but not totally accurate. New versions are currently aimed at a group of new related features or a group of issue fixes. The version number goes into systems that prompt people to upgrade, at the time it is appropriate to do so. They are also for documentation purposes so that we can easily reference them in "since" statements. Lastly, it's useful to have version numbers to reference in blog and/or forum posts. Currently this system of version numbers is the most beneficial one for this project. This isn't what I'd consider a breaking change. This is something where it just asks you to install a module as part of an upgrade to the version, it doesn't break the API or the site, just locks down a specific admin feature for security until you install the appropriate module. And security always comes first in PW. But I don't think there are any actual breaking changes in PW. Again, if it became commonplace like it is in other projects, then we'd likely adopt the same version number approach they do. So perhaps that's something that will come in the future, but we're not at that point. I'm open to it at the appropriate time. A "template file" is a "file" for a "template". I don't know how to be any more clear than that. But yes there are instances where we're talking about template files that I might use the term "template" rather than "template file" since the context is established. I agree that terms like "template" and "file" are fairly generic, and it would be nice if templates were like cars where we could refer to the "car" but also have a label like "wheels" and know we are still referring to the bigger "car" above it. But "file" is a generic enough term that while accurate, needs context. I'll take it as a compliment that you consider RepeaterMatrix to be so valuable. The Pro modules were never intended to be "required" for any site. They are meant to be a luxury or a time saver, but there's nothing you can do with any Pro module that you can't do yourself by some other means. Though Pro modules might save you time in doing it. I've built example modules that show you how to do do just about anything that Pro modules can do, they just might require more of your effort. The original intention for Fieldtypes and Inputfields was that everyone would build their own according to their needs, but I don't know many that do that other than me. Have a look at FieldtypeEvents sometime to see how simple it is to do. I don't share your opinion on this. If you are of the mindset that the page tree reflects the front-end site 1-to-1 then you are in the mindset of a different system. I consider the tree to be essential, a major benefit, as you know everything has a place and hierarchy and you don't have to have various different kinds of navigations or buckets to find them. If you know one thing you know everything in PW. I've never been a fan of different bucket systems and the ambiguity that they introduce. ProcessWire was designed from the beginning to get away from what you are talking about, what I subjectively feel is a mess in other systems (again, my preference). PW aims to be simpler and more flexible than that, though pages can still be browsed as a tree or as buckets, even if the tree is the source. I don't agree with your premise, or the linked post. Having a link to someone else's opinion does not make it right, maybe just right for you personally, that's fine. I would agree that there are benefits to letting the page tree influence your navigation, but there aren't drawbacks to not using it that way either. It may have started that way. While I am currently the gatekeeper in terms of maintaining the core I consider ProcessWire to be a long term community developed project, and it becomes more that every year. Every open source project needs someone to start it, and someone to be a caretaker, ensuring the quality of it, and I see that as my role, which I take very seriously. But this is a team project and one that is much more sustainable long term than a commercial one.

To make it really short: There is a project of mine that gets about 5.000 to close to x.000 requests each day to common standard folders (WP, PHPMyAdmin, Backups, Gallery Scripts, and everything that has been on a 0day-list in the last 10 years) in addition to the regular site requests/traffic. I will and need to to bypass 404s similar like @ryan wrote in this tutorial. I disabled 404-monitoring in Jumplinks a while back as the database grew each minute and wasn't "maintainable" anymore - due to auto backups each day. https://processwire.com/blog/posts/optimizing-404s-in-processwire/ Has anyone additional tips in regards to this guide from Ryan? Something to consider? Something that needs special attention? Something that didn't or doesn't work anymore? Or should I already block all this requests in the CDN somehow? Feedback welcome. I will start this little project next weekend. So... don't worry with feedback. And if you ask... I actually prefer adding those block rules to the CDN somehow.

Maybe give Padloper 2 a try. It is a dedicated e-commerce software ? ?. Then again, maybe I am too close to it.

Hi Peter, and welcome to the forums! If you want to get the database name, you can use: $databaseName = $config->dbName; Or you could look for $config->dbName in the site's config.php file. To see the database structure, you could use a tool such as phpMyAdmin or Adminer, or install the Tracy Debugger for ProcessWire module (https://adrianbj.github.io/TracyDebugger/#/) which is highly recommended and, among many other things, adds an Adminer page to the Setup menu. However, I note that in a typical ProcessWire installation, you don't need to use SQL queries at all, and they're probably not the best way of going about things. Generally, using PW selectors will do everything you need, and will be much more straightforward: https://processwire.com/docs/selectors/. They're one of the really nice features of PW! Let us know if you need more pointers or suggestions.

@taotoo i have experienced that and i thought i had fixed it. I will check to see if there is some change or update i forgot to commit to the repo and get back to you - it is definitely solvable if i recall.

I think ProcessWire is perfectly capable of handling an ecommerce. My main consideration is that such project requires more time and expertise than for example configuring a Woocommerce, Open Cart or Prestashop type of ecommerce and just use their apis for showing up the products. If you would need a tailored approach, surely ProcessWire and Padloper can be handy ?

Check out this thread ? Do you have your database charset set to utf8mb4?

Cool ? Thx for sharing that @horst this sounds exciting! How does that work?

https://github.com/processwire/processwire/blob/dev/wire/core/ProcessController.php#L388

Maybe the 7G-Firewall htaccess rules do help? https://perishablepress.com/7g-firewall/ https://processwire.com/talk/topic/24230-7g-firewall-tweaks-required/

Hey all. I have read a bit through all the posts here, got inspired and have changed my personal little local tool for live reloading from using ajax polling to use SSE. If you like, I can share my experiences and thoughts to some of the (somewhere) above mentioned problems. My setup is manually enabling / disabling SSE via a button. The SSE-php file does NOT use PWs system. It is complet solely, means it does not use (and maybe block) a users PW session. It uses the basic examples from MDN, as the JS do too. No special buffering, string_padding or the like is needed! I use h2 (HTTP2) protocol, what also needs https to run. (I'm not sure, but I think h2 is needed for not early disconnecting (and then start polling)). My polling loop on the server is every second. I send one keep-alive ping around every 15 to 20 seconds. In the one-second-server-loop I check if something has changed in the GIT tree, in comparison to the previous run. If so, I do an ajax call to PW, where my styles and scripts pre- and post processors are hosted (in a module). (It is similar then included in ProCache, but was coded earlier then that in PC.) They do a in-depth check and do recompile necessary files on demand and return if refresh is needed or not, what, only if true, gets pushed through to the client browser. I can work in the admin, I can work in the client, also with concurrent fetch/ajax calls while SSE is listening, etc. My PHP file is: My JS in browser is: Here is a screen, showing the network tab and console:

I stumbled across this post searching for the reason why my module won't create the process page under setup. I tried some suggestions from this threat, but eventually found another solution. I just wanted to share this in case someone needed it. I used the getModuleInfo() function to add a page. I did not prefix my modules name with "Process" but only extended it with the Progress class. The only thing I had to do was calling the parents install() method in my modules install() method. That`s it. Now the setup page is created automatically on install. <?php namespace ProcessWire; class MyModule extends Process implements ConfigurableModule { public static function getModuleInfo() { return [ 'title' => 'My Module', 'summary' => 'A module', 'version' => 1, 'page' => array( 'name' => 'mymodule', 'parent' => 'setup', 'title' => 'My Module', ) ]; } public function install() { parent::___install(); } public function uninstall() { parent::___uninstall(); } }

A few weeks ago I told you about a new module I was working on that automatically saves front-end form submissions and can send email reminders for the user to finish their form. The module is called FormAutoSaver. This week I finished up that module and have released it both in the ProDevTools board and the FormBuilder board, and it's available for download now. Note that it is first release/beta test version right now. This module can be used with or without FormBuilder. Though when used with FormBuilder it is more of a turn-key setup that can be done in the admin. I've put together a dedicated FormAutoSaver documentation and information page on the site, so rather than repeating a lot of information here I'll point you to that, if you are interested in it. I also wanted to mention that a new version of FormBuilder has also been released this week (v52). There aren't any major feature additions to write about here, but there are several small improvements and bug fixes. By the way, I've added FormAutoSaver to one FormBuilder form on this site: the site submission form. There's not much to see, since it silently works in the background. But if you want to try it out, fill-in some or all of the form (making sure to fill in your email address), but don't submit the form. Feel free to leave the form or even switch devices. You should get a reminder email in 5-10 minutes with a link to finish your form. While you are there, please submit recent sites you've built in ProcessWire, we love seeing your work! My kids are starting spring break from school next week, so I'll be mostly offline and likely won't have any updates next week, but will be back to core updates after that and hopefully getting ready for a release candidate of our next master version shortly after. Thanks for reading and have a great weekend!

This is great, thanks @MoritzLost for taking the time to write this up and share it with us. Although I don't agree with all the points (e.g. I think the PW emphasis on tree/hierarchy is a pro rather than a con) it's really interesting and useful to get an insight into how other CMSs solve problems and bring value to their users. I'm not sure if Ryan feels the same, but speaking as a person who enjoys developing modules and tools: eventually the limiting factor becomes ideas. That is, the will is there to keep creating useful things but the challenge is knowing what will consititute a useful thing to the audience. So getting user requests and descriptions of pain points is what's needed to keep the wheels turning. Regarding the Craft/PW comparison... You did state this clearly at the outset but I want to really emphasise this because it's such a major factor: the difference in cost between Craft CMS and ProcessWire is massive. I did a conservative estimate of the net income I would have lost as a solo developer over the last 5 years if I had have built all of my projects with Craft/plugins rather than PW/modules. It's approximately USD $43,000. For someone in my position that is just huge. Maybe I could have successfully added those Craft costs into the quotes but then maybe I would have lost many bids if I had done that. In general, if you think about the difference between something that's free and something that costs upwards of $299 it should be no surprise if there are some advantages to the thing that costs you $299. In fact it would be outrageous if you paid $299 for a thing and it was worse or no better than a free alternative. Suppose I would like a drink and I'm choosing between the free option (a bottle of tap water) and the $299 option (a bottle of Dom Pérignon champagne). The champagne should be a better experience than the tap water. That's why it costs $299. But when we bring this analogy back to PW/Craft, it's like ordering a bottle of tap water and then having the pleasant surprise that it's a very nice méthode traditionnelle. Maybe not quite as good as the Dom Pérignon, but at $0 that's extraodinary value and a lot of people would say it's the better choice for them. For the types of projects I use PW for, I have the occassional niggle but it's very minor stuff. Although I'd love to see PW match all the features of all its commercial competitors I also think it's reasonable to take the position that a free product is not going to be all things to all people. I actually wish there was more clarity about the kind of developer and kind of projects PW is targetted towards. In my opinion, narrowing the focus of PW and clearly communicating this at processwire.com would be a step in the right direction. Even if this was somehow expressed in negative terms, e.g. Don't know what a foreach loop is? Other tools will suit you better than PW. Looking for themes? Other tools will suit you better than PW. Looking for "a plugin for everything"? Other tools will suit you better than PW. Part of a large development team? Other tools will suit you better than PW. Building "enterprise" applications? Other tools will suit you better than PW. Working on projects with budgets in the mid-five-figures and higher? Don't be such a cheapskate, get out your chequebook because other tools will suit you better than PW. The way I see it, the person who will get most value and satisfaction from PW is a solo developer with at least intermediate experience (or a willingness to get there), working on projects that have demands that go beyond the basic but where the budget is somewhat limited. The main benefit that I get from PW is that I can build surprisingly powerful sites and build them fast so the hours/costs are kept down. This is the PW sweetspot and I think we should lean into it.