Leaderboard

I figure this is an off topic board among friends here (like our pub, or a real one) and it’s okay to write with honesty and engage in spirited or sometimes heated conversation. So just want to be clear that I like and respect @MoritzLost and value his opinions, even if I don’t agree with all of them. We will all have a diversity of views and everyone should feel free to share them, and likewise others should feel free to question those or state their own, which is what I’m trying to do. But I’m glad MoritzLost shares his opinions here. Plus, a little controversy also helps to engage the community, and drags me out of the code for a bit, so I can’t fault anyone for that. Once I can state my thoughts, I carry no concerns, but thought I should defend the things that deserved defending, as I always should. As a caretaker of this project, part of my responsibility to add my honest point of view to a conversation like this, especially when something is posted where I don’t fully agree. I think many in our community know the subjectivity of statements here (whether OP’s, mine, or another’s), but an equal number may not, as this is a public board. So some counterpoint or back-and-forth is not only clarifying to the larger audience, but also useful, as we explore different facets of it all, and lead to the most important takeaways. I appreciate that MoritzLost continues to defend his point of view on parts, despite my own defense or heated questioning of those parts. It helps me to better understand and know which are the parts that he thinks are most important and deserve the attention. We obviously don’t have the resources to pursue everything Craft does, so narrowing in on the most important parts—the meat of it—is helpful here. I’m traveling right now so can’t participate as much as I’d like to at the moment but just didn’t want MoritzLost or anyone else to think I was angry or something. Likewise I didn’t want anyone else to think they had to moderate themselves either. When I’m among friends I feel comfortable to express and be honest, and so should you. If you get a heated reply from me it’s because I care about it and value your opinion. I’ll spend more time reading everything when I get back, but I can see already it’s a good and helpful discussion.

Another 2 cents for the "not an essentiall comment"-jar. 1) WHAT A GREAT PLACE!! (by @bernhard) Indeed. This is one of the most friendly, most awesome and most advanced communities around. Hands down. This is almost a bit like "family" - at least for me. Thank you! Therefore... 2) Discussions like this are needed. Really! They are... hard to digest. Unfair. Emotional. Yet worth it at the end. I think ... first of all there are two people here that might want to "enjoy" a 1:1 discussion to clarify things. As both have very good and honest arguments here. This "clash" could and will be good. I personally think that there was only a slight offset in communication and perception - to be honest. Both aren't far away from each other. I personally hate/love those discussion in projects because they become super emotional right from the start and it takes way too long to calm each and everyone down to a common ground afterwards. Especially when there is a large team around that fires up the situation. Oh. But most of the time the project benefits from it. Therefore my idea of a 1:1 here. I personally enjoy giving harsh feedback. While I hate receiving harsh feedback. But that's life... I guess. We grow with it. It's sad that all comments "against" ProcessWire CMS/processwire.com end at one point aka @ryan. I don't know Ryan in person but still a bit through various discussions in various boards, threads and messages and really enjoy all of his insights, feedbacks and even more for what he has built and builds here - with ProcessWire. Has anyone ever noticed that he dedicates his sundays for this community? So much love for this! That's why I fully understand and support Ryan's post and feedback. Even though while Moritz has some good points as well. I understand Moritz's points here in some kind. I have my very own personal issues with ProcessWire CMS - some days more, some day less but most of the time I praise ProcessWire as the best solution ever. As it is for me and my projects. 3) Takeaways so far - for me (you are free to argue against my perception) This thread was and is some kind of bumpy but as Ryan, ProcessWire, and this community are... this is just another challenge we will laugh about in 12 months and enjoy what happened in the meantime all together. 4) Future outlook Maybe we as a community, devs, friends, however you want to call it should start outlining things WE could do. Not only demanding things and asking for whatever. Maybe we could offer solutions instead. Designers could create a new visual look. Marketers could offer USPs and target-group analysis. SEOs could work with that and look up whats interesting compared to other CMSs. AND. SO. ON. I can offer the SEO aspect in this, maybe frontend templates for very fast loading and awesome Google Insight numbers. Count me in on this! Ok. Ok. I put 2 dollars in the jar.

Sarcasm (scnr): I've noticed lately that the most valiant defenders of the opinion that PW lacks support for migrations are the ones that have never given https://processwire.com/modules/migrations/ (which dates back to 2016) and https://processwire.com/modules/rock-migrations/ (which has it's 3rd birthday next week ? ) a serious try ? ? Personal note: While I did not read your posting as offending as Ryan seams to have read it I can totally understand his reaction. I have not put a fraction of the time into ProcessWire compared to Ryan but still I was confused about some statements you made. And I know how it feels if you talk about things in a way you did in this thread and in a similar way you did in this thread and in this thread. It might not have been your intention, but it seems you are a bit quick in stating "how things are" and how they have to be... Back to topic (and I try to keep objective): -- Selectors -- Ryan has already answered here. I just want to add that I'm using array syntax for selectors a lot and I really like it ? BTW: Just noticed that it's also a birthday for selector array syntax: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support Happy Birthday and thanks for being with us and being a reliable tool in my everyday work for the last 6 years ? Could you please explain the vulnerability here for others to learn from your example? -- Features -- I just wanted to share that I've had quite the opposite experience with a lot of tools that I've tried over the last view years. At first sight there was a lot of bling bling and shiny cool things, but at second sight I found limitations here and other annoying parts there. Maybe I've just tried the wrong tools but with ProcessWire my experience was exactly the opposite: My first impression was that it is by far too simple for what I need. Several years later I feel like I'm just scratching the surface ? -- Twig -- I'm SO happy that we don't have such a layer by default in ProcessWire!! I've not worked much with template engines but I've used smarty back in 2004 so it's not that I don't know that such tools exist or what they are for. Though what I do a lot is keeping my template files as clean as possible. How I do that? I use custom page classes everywhere and if I need just a little bit of logic somewhere I put that logic into the page class to keep things simple on the frontend part. What I really like here is one of the biggest benefits of PW of all: It keeps simple things simple and makes complex things possible (and fun). If you have just started (with PW or with web development in general) you can simply echo some page properties and see the result on the screen. No additional tools. No necessary build chain. No template engine. Just PHP and HTML. Great ? In my opinion ? I've recently had to try another open source CMS. That CMS has native support for migrations as everything goes into YAML files. It has fancy backend editing for everything. Fancy, yes. But that adds another layer of complexity to the whole thing as well. Imagine how long it took me to understand how I can create a single field and display the content of that field on the frontend? Long. Very long. I don't want to tell you how long. ? Because of all that fancyness that system uses a custom language for rendering all the fields. It was a terrible experience for me and I felt really bad that I as a quite experienced PHP developer was not able to achieve simple things in a PHP based content management system. One user commented on one of their youtube tutorials that it's another perfect example of a german product developed by a few geniuses but impossible to use for the average dev. I agree with him and I'm happy that ProcessWire takes another route! -- Documentation -- I agree that lots of information is scattered around somewhere (in the forum, in the docs or in code), BUT (and that's the part you didn't mention and which is just another example of why things might be taken personally): In my opinion ProcessWire (or Ryan) does a lot right in that regard and is way ahead compared to other tools I've used (maybe tried the wrong tools again). For example the docs in code are absolutely great! Nearly every method that I need to inspect has some explanation directly in code so I can quickly jump to that place in my IDE or even get helpful pieces of the docs instantly as tooltip: Next, the forum: WHAT A GREAT PLACE!! I've been on another system before I discovered PW. They had a forum as well... But I simply did not get help there. I posted a question and did not know if I'll get an answer in one week or two, if ever. That was such a pain and PW is so great in that regard! It might be a small community but the support is outstanding. I've also seen other products that have a discord channel or something similar. Maybe forums are old-school, but in my opinion they are still great and will be for a long time. You have an archive where everybody can find answers to their questions and learn from posted answers. And one other great thing is that 90% of those answers will likely still just work if you apply them today even if they are several years old. -- Version numbers -- What I'd pick up from that point is that some of the strengths of PW might look like weaknesses for others on first sight. Just as the simple and clean backend for me looked like PW is not capable of complex things the used version numbers and the fact that the github master branch might not see any updates for several months can give the impression to others that the project is not actively developed. It's a matter of everybody's perceptions and expectations. ProcessWire could to more in that regard. But on the other hand I really appreciate that it (or Ryan) does not care as much about that as other systems do. The downside of this is that it can be hard to sell to other devs and/or clients... -- A word to Ryan -- I don't agree with you here and I think that's a blind spot on your end. ? When I started developing my first custom Fieldtype it took me quite long to understand how things work. Learning from the events fieldtype was really hard! It is obvious and simple once you know how all the pieces play together (you basically just need an inputfield and a related fieldtype for sleep() and wakeup(), right?) but it was really not easy to start with a blank screen in my IDE without having this concept in my head and then put all those pieces together one by one trying to understand what they do and then making them do what I want. I guess we didn't even have TracyDebugger back then. ? (By the way - how great is Tracy?! Another invaluable tool in our Ecosystem that I don't want to miss!) I think it's similar to what happened when I first discovered the PW backend. This was one of the most liked posts in the forum so I think it was and maybe still is not obvious to many how easy it actually is to work with and customize the PW backend. As a side note I think that might be one reason why PW is still underestimated in regards to being not only a wonderful tool to create websites but also a wonderful tool to create web applications. And I have to do it again: I think RockMigrations is just another example of something in PW that looks more complex than it actually is. And an example of something that looks less powerful than it actually is. I've taken that learning from the other threads and already improved the module greatly. The next version will make it a lot easier to get started with. Maybe that will open some eyes. And maybe Ryan will also revisit this thread one day and will recap and pick up some of the things that were mentioned. There were some good points in it and the amount of reactions shows that, I think. So thanks for bringing those topics up @MoritzLost and thanks for the insights as always @ryan.

Totally agree. ProcessWire is so amazing I wish I could grow with it in larger scale projects. Totally disagree. At work we are 3 devs at the moment working on the same projects all the time and we have fully automated deployments both to staging and production. And it is easy to review and merge pull requests. And I've shared all that is necessary with the community. For free. And so has @LostKobrakai @MoritzLost Please stop stating your points in a manner that discredits the work of others or the way how others are working. Thank you. We have wire shell. Why don't you take up this project? You are obviously in need of such tools. Why do you keep bashing around and do not help improving the tools that we already have or help to make new tools being created and - also important - being shared with the community? I like that you bring up all those points, but I really don't like the way you are doing this. Imagine someone evaluating ProcessWire and somehow finding your thread or reading it by coincidence. Even if that person will likely not read it with the same emotions that I do he/she will still get an - in my opinion - wrong picture. I think it is in the interest of all of us to promote the things we have and to encourage everybody to take part.

Padloper 2 has been released I will write a better post later. Need to know for now: Get it from here. We will be transitioning to a new website and/or shop in due course. For now, please get it from that old site. For now, and to allow it to bow out gracefully, initial purchases will be powered by Padloper 1. All hail Padloper 1 :-). Due to #2, and #3 and due to non-SCA compliance on that particular site, there might be Stripe issues. Apologies. Please contact me for help. Support for Padloper 1 has ceased. Security fixes will continue. Things I have promised to look at will be looked at :-). Support subscription period for beta testers' purchases commences today - 30 March 2022. It is a special day...in more than one way... Update 3 April 2022 Frequently Asked Questions A few questions are coming up with respect to this release. For now, I'll answer them here but might start a new threaded dedicated to FAQs. Q: Will beta testers have to purchase a new licence for this release? A: No. Your licence and download link are still valid. The only difference is the countdown of your VIP support commences on 30 March 2022. Subscriptions and updates are valid for one year. This download link was emailed to you when you purchased Padloper 2. Please contact me if you do not have a download link. Q: I have shops built in Padloper 1 that I'd like to migrate to Padloper 2. I don't have the expertise and/or time to do the migration myself. Is there paid support for this? A: Yes, paid support is available. We can migrate your Padloper 1 shop to Padloper 2 per your specifications. This includes both backend and frontend migration. You can purchase either or both backend and frontend migration. Please contact me to discuss. We will soon add this custom work information to our website. Q: Is there a backend/admin demo of Padloper 2 that I can test pre-purchase? A: Yes. We are currently putting final touches to it. An announcement will be made here once this is ready. Q: Which is now the official Padloper support forum? A: This forum will eventually become the official Padloper support forum Although it is a public forum, we will still be able to offer VIP support. The only difference is downloads will be not be available in the forums, since it is open. Support via email will still be available as well. Q: I am getting a called to undefined function bcmul() after install. What does this mean? A: Please see the minimum requirements for Padloper 2. You will need to install the PHP extension bcmath on your server. This is in order to get accurate rounding off of currencies.

The problem: how to refresh a page's frontend content in real time without a page refresh when the page has been edited in the backend. This is an alternative approach to the one discussed in the topic below. The above topic attempts to solve the problem using SSE. The solution in this topic instead relies on Local Storage and htmx. There is no ajax polling. Please note that auto-refresh here refers to a page refresh during the same session and in the same domain. It is not cross-site. The solution can be summarised as follows: Use a hook in ready.php to inject custom JavaScript to the ProcessWire backend admin, specifically in ProcessPageEdit. This can be a JavaScript file or inline script. The purpose of this file is to update a given Local Storage key after a page has been edited. Instead of listening to the Save Button click, the script just checks on load if a certain hidden input whose value matches the page currently being edited is present. This hidden input is placed inside ProcessPageEdit form using a hook as detailed below. The hook in this step #1 can be: $this->addHookAfter('AdminTheme::getExtraMarkup', null, 'hookAddCustomScriptsToAdmin'); In ready.php, add a hook to listen to saveReady(), e.g. $this->addHookAfter('Pages::saveReady', null, 'hookNotifyFrontendOfBackendPageSave');. When the page is saved, the handler method hookNotifyFrontendOfBackendPageSave will check if there are changed fields. It will then write to a temporary session variable for the current page with the names of the fields that have changed. On page load/reload, there is a hook in ready.php that monitors ProcessPageEdit, i.e. $this->addHookAfter('ProcessPageEdit::execute', null, 'hookAddMarkupToNotifyFrontendOfBackendPageSave'); The handler hookAddMarkupToNotifyFrontendOfBackendPageSave will check if there is a session variable set in #2 indicating that the page has had recent changes in the fields names set to that session variable. If this is true (that there have been changes), this hook will simply append the hidden input in #1 to the ProcessPageEdit form. The JavaScript in #1 will detect the presence of the hidden input. It will then amend the Local Storage value in #1. It cannot simply set the value to the ID of the page being edited as that will not be construed as a change. It will instead append a timestamp to the id of the page as well and set that as the value. This will enable a listener in the frontend, described in the following steps, to detect that change. In the frontend, we have a simple JavaScript file that listens to changes to the Local Storage storage Event. The frontend also has a simple hidden input in the template file whose pages we want to refresh. This hidden input has htmx attributes. Its trigger is a custom event 'autorefreshpage'. It will listen for this event before firing a message to the server. This hidden input also has hx-swap=none as nothing will be swapped to it. Instead, the server will send back results of changed fields in various markup with hx-swap-oob=true. That will enable swapping markup in any parts of the frontend html in one go. When the Script at #4 detects that a given Local Storage value has changed, it first checks if the page ID for that Local Storage value matches the page ID of the page currently being viewed in the frontend. If the answer is yes, it will fire the custom event autorefreshpage. This will make htmx fire a message to the server whose only value is the page ID it has been passed. On the server, in home.php, we have code that is listening to ajax requests. If it detects an ajax request, it checks if the page ID that htmx sent matches an available session that was recently updated. This would be the temporary session detailed in #2 above. If a match is found, it calls a function in _func.php that will set variables for fields for that page. These use partial templates (optional). These partial templates are for different outputs of the page, e.g. images, headline, etc and all their markup have hx-swap-oob='true' in appropriate places. All these content is sent back as one output back to htmx. It will read the hx-swap-oob and find the markup to replace in the DOM using the html IDs of the markup with the hx-swap-oob. This approach allows the developer to have maximum control over what to send back to htmx and over the markup. In this step, we also delete the temporary session, ready for the next updates. The result is as demonstrated below. A simple and effective DOM swap that places very little strain on the server. I'll clean up the code for this and upload to GitHub. This approach will not work with Save + Exit and similar :-).

ProcessWire 3.x markup module for rendering meta tags in HTML document head section. Note that this module is not a full-blown SEO solution, but rather a simple tool for rendering meta tags based on module configuration. Adding custom meta tags is also supported. Built-in meta tags The following meta tags are supported out-of-the-box: Document title consisting of page title and site name Character set Canonical Viewport Description Keywords Hreflang tags Open Graph og:title og:site_name og:type og:url og:description og:image og:image:width og:image:height Twitter meta tags twitter:card twitter:site twitter:creator twitter:title twitter:description twitter:image Facebook meta tags fb:app_id The full documentation with configurable options can be found here: https://github.com/Fokke-/MarkupMetadata Requirements: ProcessWire>=3.0.0 PHP >=7.1 Installation using Composer composer require fokke/markup-metadata Manual installation Download latest version from https://github.com/Fokke-/MarkupMetadata/archive/master.zip Extract module files to site/modules/MarkupMetadata directory.

It never ends does it! ??‍♂️ Awesome thank you sir! Ok this is very good of you indeed. Private message you about this in a mo.

Good day, fellow Wireframe users! @Zeka once asked about how to organize large number of components in subfolders of components folder. Since then @teppointroduced view namespaces (for partials ATM), which probably could be extended to support components. We have found another way to use components in subfolders - via the usage of php namespaces. In @Zeka's case with the Blocks subdolder it would work like this: <?php // In [wireframeRoot]/components/Blocks/BlockText.php // Note the namespace namespace Wireframe\Component\Blocks; class BlockText extends \Wireframe\Component { ... and <?php // In the view file <?= Wireframe::component('Blocks\BlockText', [...]); ?> I guess this is possible due to PSR-4 compliance of the autoloader used. Or maybe @teppohas added something since then. Do you see this as a valid usage? Do you see any drawbаcks?

I reckoned as much ?. That version does not have the bug fixed, sorry. Please use the latest version. The same link I sent you should work. It is valid for one year effective 30 Match 2022. No way! That'd be very unfair ?. Now that Padloper has been released (no longer in beta), although the beta testing programme is finished, your licence does not expire with the end of the testing. In fact, your subscription and access to VIP support 1-year countdown starts from the release date, i.e. 30 March 2022. I hope this answers your question. This would be awesome. Thanks.

Hi @alexm, Are you using the release version? I.e. when did you get your Padloper copy?

Hey @Ivan Gretsky, I don't see anything wrong with your approach. This is not something I had specifically planned for, but as you've noted above, it works thanks to the autoloader setup ? Only "issue" — and it's not much of an issue to be honest — would be that technically /components/Blocks/ should be the "view path" for a component called "Blocks". I can't really think of any real world situation where this would cause problems, though. The approach Zeka took in earlier posts effectively created a whole new type of components, in some ways more strictly separated from the built-in component structure. I'd say that it's largely a matter of preference.

Yes, the code in the first post was copied directly from the source in the two browsers. The full set of nav links are completely missing. I haven't been able to track down any JS or browser plugins which could have removed the HTML elements. I disabled all JS, ad-blockers etc. to see if it made any difference. Really stumped by this. I can't believe it could be PHP altering the output. Think it's much more likely a browser and/or user error, but I just can't track the damn thing down. Anyway, I've hard-coded them for now, and luckily the nav pages are unlikely to change. I'll just have to circle back to it once the project's finished for my own sanity!

Hello, I've never used it but I casually read the posts of this LoginRegister module during the days, and as far as I can remember, this module has its own issues but still usable even from a security standpoint. However, I highly recommend that you carefully read most of the topics before deciding whether to use it or not: https://www.google.hu/search?q="LoginRegister"+site%3Aprocesswire.com%2Ftalk Personally, next time I need frontend user login, I will use the commercial version instead. EDIT: to make it clear, I was referring to Ryan's free/commecial Login and Registration modules, so I added a google search URL to show what I meant.

You just saved my bacon, @Robin S — thanks for this! For those searching, this is the secret sauce for presenting a subset of entries to select from, based on a previous selection. In my case: parent=page.refSection where refSection is a grosser-level selection in a hierarchy. I believe this also answers this question:

@da², there are probably several standard ready-to-use scripts floating around on this forum and elsewhere and I think there was another module - curious to hear responses from others, I haven't checked recently. Here is a login/register process from the main PW developer Ryan Cramer. It's 5 years old, but I think it should still work and that it was provided as an example that you can adapt and expand to suit your needs. And if you really need a generic out of the box solution, you could always use the Pro module. Here are some of the old threads where I was trying to solve some parts of this, like best practices to secure registration and front-end password reset. Also see this post.

This looks really cool but I have to admit that I would have to look at the code to really understand what's going on ? It looks like you are mastering htmx a lot lately, nice job!

True, but just want to point out there can be occasional "gotchas" when doing this because PW sometimes returns things that may be unexpected in the unformatted value. For example, the unformatted value of a Page Reference field will include unpublished pages and the unformatted value of a Repeater field can include "ready" items that are not populated in Page Edit. And in the case being discussed here the unformatted value of an images field can include "temporary" images that have been uploaded in Page Edit but the page has not yet been saved. So in the example below the frog image is saved but the fish image has just been uploaded but not yet saved, and might yet be abandoned before saving because of being a mistake or unwanted. Yet it appears in the unformatted value:

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.

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!

I bet that the first version of LR was removed because the module is not maintained in favor of the new version. As well, the pro module make things easy to implement and will let you sleep tight, as most hassles (security.. blabla..) got handled by ryan and contributors. If you want to try it out before pulling out the wallet, you can find the free version on the author's github ? https://github.com/ryancramerdesign/LoginRegister - (I have myself the first version in the wild since years without issue / registration disabled) and you will find some threads around the forum to customize it.

Hey, @Mats! Please create a separate topic as Wireframe now has a dedicated subforum. This way we can easier track issues. @teppo, do you think locking this topic would be the right thing to do? Adrian did lock the old monolithic Tracy thread. Sorry for being meta and not on topic)

New version of the module is now released. Truncate description using $sanitizer->truncate() method Added properties: description_max_length and description_truncate_mode Due to the usage of truncate method, the module now requires PW >=3.0.101 Image added using API will be resized Validate image object before resizing it Added API notes for all fields in module configuration Documentation fixes Download here: https://github.com/Fokke-/MarkupMetadata/releases/tag/1.1.2

In the "Selector string" setting for "Selectable pages" you can use "page" to refer to the current page, but only if you also specify a subfield using dot syntax. In your case you would use page.id to exclude children of a parent: template=item, parent!=page.id Unfortunately I don't think this is documented anywhere.

@Soma Yeah this is my issue with Vue.JS - I use Vue.JS often for two way data-binding which is amazing to be able to easily update content and do visual changes to the site based on those updates. For example adding something to a basket. It's much easier with Vue than jQuery or JavaScript. My issue with Vue is exactly that. You can use it just on a component basis or you can use it to render your entire UI. To me it just doesn't make sense to use it to render an entire UI with a website. A web app sure, but a website it's often overkill and introduces that exact problem. You can introduce server side rendering of Vue with Nuxt but then it just seems like another layer of 'over complication'. I personally stopped using Vue for websites unless I absolutely needed two way binding. It just didn't make sense and the extra complication of implementing it such as having to convert everything from ProcessWire into a JSON feed. EDIT: Noticed this post still gets likes, so what's changed since then? AlpineJS. AlpineJS is a solution to this exact problem, worth a look for anyone wanting to do some cool UI stuff without including all of Vue features and overhead.

That <p> tags come from ckeditor: https://processwire.com/talk/topic/10999-ckeditor-remove-wrapping-from-in-source-code/ The easiest solution would be to change your code to this: <div style="color: white;"> <?=$faq->faq_answer?> </div>

@franciccio-ITALIANO If you have an HTML Entity Encoder in Text Formatters you need to remove it, because that is causing the issue you're describing.