Search the Community

I’m late to the Konkat theme but having used it recently, I really like it. It seems without any major UI adjustments that it’s just a nicer experience and if I’m not imagining things, a little faster? Nice job @diogo and everyone. If you’re open to feedback, can I add the following. First, the main grey background is a touch too dark for my personal preference, and interestingly a client mentioned the same, describing it as too industrial. They’re marketing. They like their UI to be friendly and approachable. The issue is a practical one: a heavy base grey compresses the tonal range before we placed a single element on the page. To make cards or panels register visually at all, you have to resort to strong contrast because a nice, subtle layering just disappears. Alternatively, with a near-white base you have room to step up gradually, building visual hierarchy through gentle increments. A heavy base leaves nowhere to go without things feeling either too dark or muddy. This isn’t a design lecture… just trying to pinpoint the particular issue. And I agree it only really affects module builders but interestingly, a client recently remarked that they found it a little industrial and unwelcoming compared to the previous theme. Next up, buttons… I find that buttons with 100% border radius never appear as truly aligned as flat side buttons with a subtle border radius. We switched to rounded buttons years ago on an enterprise project, everyone loved the change ( yay, jelly beans!) and now we’re going back to traditional 4px border radius throughout because everything just looks better aligned. It seems the beauty of using the css vars is I can easily tweak these things myself but wondered if at least the grey background was under consideration? Otherwise and honestly, it’s a great theme and I’m looking forward to using it more.

Hi @Nomak I am interested in assisting with the frontend development of your website. I have experience building responsive websites using HTML, CSS, and JavaScript, with strong attention to clean code, performance, and cross-device compatibility. I understand that the design is already finalized. I can focus entirely on implementing the frontend according to the provided layouts and ensuring full responsiveness across desktop, tablet, and mobile devices. Please feel free to share the design files and any technical requirements or timelines. Happy to discuss the project further. Good Day Deep

Wow. These "ProcessWire as a web application framework"-type updates are coming in strong! Migrations, CLI, Tests, AI. One can wish for a maybe first party queue system too. 😄

Aider has an interesting “architect mode”, where you can define a “strong” and a “week” models for reasoning and acting. This can keep costs much lower https://aider.chat/2024/09/26/architect.html

I really like the way things are going with ProcessWire and AI. Thank you, Ryan. I've been a big fan and strong advocate for migrations in PW, since I started using RockMigrations years ago. What makes RM a particularly strong candidate is the abstraction into a schema-like format which is much easier to understand/read/write than native PW API code. This is a real strength of RM and I would prefer a schema-based approach anytime over writing (or having AI write) PW API code. Claude is very good at understanding the PW API, other models are not that strong. But they all can understand schemata. Be it PHP arrays, JSON, YAML. So I would advocate for either developing an "official" PW migration schema or adapting the existing, battle tested one from RockMigrations.

Hey everyone, on a recent client project we had to deal with a large number of Markdown files that needed to end up as regular HTML content on ProcessWire pages. Converting them manually or piping them through external tools wasn't an option – too many files, too tedious, and the content had to be stored as actual HTML in rich textfields, not just formatted at runtime. So we built a small module that handles this directly inside ProcessWire. How it works The module creates a file upload field (md_import_files) and a Repeater field (md_import_items) with a standard title field and a richtext body field (md_import_body) inside. The body field automatically uses TinyMCE if installed, otherwise CKEditor. You add both fields (md_import_files,md_import_items) to any template, upload your .md files, hit save – each file gets converted to HTML via PW's core TextformatterMarkdownExtra and stored as a separate Repeater item. The source filename goes into the items title, processed files are removed from the upload automatically. Template output The Repeater items are regular PW pages, so output is straightforward: foreach ($page->md_import_items as $item) { echo "<section>"; echo "<h2>{$item->title}</h2>"; echo "<div>{$item->md_import_body}</div>"; echo "</section>"; } Tag mappings One thing we needed right away: control over how certain Markdown elements end up in HTML. For example, #headings in Markdown become <h1> – but on most websites <h1> is reserved for the page title. The module has a simple config (Modules → Configure → Markdown Importer) where you define tag mappings, one per line: h1:h2 h2:h3 strong:b blockquote:aside hr:br This performs a simple 1:1 tag replacement after conversion, preserving all attributes. Works well for standalone or equivalent elements like headings, inline formatting, blockquotes, or void elements like hr:br. Note that it doesn't handle nested structures – mapping table:ul for example would only replace the outer <table> tag while leaving thead, tr, td etc. untouched. Requirements ProcessWire 3.0.0+ FieldtypeRepeater (core) TextformatterMarkdownExtra (core) GitHub: github.com/frameless-at/MarkdownImporter Modules Directory: https://processwire.com/modules/markdown-importer/ Happy to hear if anyone finds this useful or has suggestions for improvements. Cheers, Mike

Largely agree with this, but in my experience, it has depended on the (potential) client and their role and what CMS they are moving from. I think I should have made this qualifier because I agree with this. It does depend on the size of client and role the website plays in their business operations. @Peter Knight I think reliability is also a very strong key feature. Those coming from WordPress will be all too familiar with surprise downtime, plugin vs. core upgrade challenges, high update frequency, and overall complexity in maintenance. If as a website owner/maintainer you need to call a developer to fix a website regularly, or to even just update the site because you can't figure it out, then you're not taking into account the hidden costs. Add plugin subscriptions on top of that. As I've said elsewhere in the PW forums, I like WordPress- I make a lot of money off of it. I'm not shy about openly discussing pain points with clients because I have none to offer and they're well familiar with those they've had to live with. I think I mentioned this in another post/thread recently. A demo can do a lot of the talking. I think PW had one at some point(?) but it would benefit both developers and clients immensely now. You can skip the main ProcessWire site, and a lot of Q&A, by just saying "take a look". Yes. No. I don't think that there is a standalone repo for the new theme either. I think it would be really helpful to make that a standalone repo that can accept PRs. Having the theme wrapped into the core means that all fixes and updates have to go through the same channel as core. The issues repo has been much more busy after the new theme launched. While there are a lot of big suggestions and input, there are plenty of fixes and smaller suggestions that could be implemented via PRs and result in easier per-contribution review, faster iterations, and quality improvements.

Hi folks, I am currently in search for a new hosting solution for my processwire client-websites (40 websites) with a strong focus on loading performance. Right now, the websites are hosted on an old Hosteurope shared hosting with HDD - which is going to be closed down this year. The new cPanel shared hosting Hosteurope offers in order to replace the old one has some strange weaknesses/limitation (I have tested it deeply). So I am forced to leave Hosteurope after many many years. Right now, I am testing varios hosting provider - for various reasons it must be form Germany. For testing I am comparing a live-website running on my old Hosteurope shared hosting with a duplicate of the live-website running on the new hosting provider. The testing tool I am using: Pagespeed Insights (https://pagespeed.web.dev/) In the past weeks I have tested webgo.de's managed vServer with ssd/nvme. But it was really disappointing: the websites loading performance was weaker than on my old Hosteurope shared hosting. And, they didn't even managed to activate http2. So right now, I am testing the managed server from Hetzner (product name MA80 with really strong physical stats). Even here, the websites loading performance is weaker than on my old Hosteurope shared hosting. And so far, the Hetzner support didn't help me to configure the server the for more performance. I am no server expert, can anyone recommend a hosting solution that has a really good loading performance? Best Nomak

Hi everyone, Like many of you, I have relied on the Pages2Pdf module in the past. It was a great tool, but unfortunately, it seems to be no longer actively maintained. With the shift to PHP 8 in most modern environments, the older version of the underlying mPDF library used in the original module has become a bottleneck, causing compatibility issues. Since I needed a working solution for a current project, I have already created a fork and updated the code to work with a newer, PHP 8 compatible version of mPDF. The Idea: Wire2Pdf I am planning to release this updated version as a new module under the name Wire2Pdf. This would distinguish it from the legacy module and allow for new features (like custom font support) without breaking older installations. What I have done in a fork so far: Code refactoring for PHP 8 compatibility. Updated the mPDF library to a recent supported version. -> https://github.com/markusthomas/Pages2Pdf Before I proceed... I wanted to check with you first: Is there still a strong interest in a maintained module based on mPDF, or have you moved to other solutions (like RockPdf)? Are there specific pain points you had with Pages2Pdf that I should address if I move forward with Wire2Pdf? If there is enough interest, I will polish the code, package it as a new module, and release it. Cheers! Markus

Let's say I have Fieldset Group called Tables that contains 3 x Pro Fields table. Each table is label, value where label is set via the API and is readonly (see below). If I set the field to be Closed on load, how can I set it so that if in any of the tables if value is empty instead of seeing a closed fieldset: Tables ... I get something like: Tables ... 7 missing values or Tables (7 missing values) ... (either is okay) Additional questions: I also want to hide the new row button but I think I can easily do that with CSS. Use this CSS: li#Inputfield_{myFieldName}pageText a.InputfieldTableAddRow { display: none; } How can I make the label field in the table readonly, add readonly=readonly to the settings for that column doesn't do it. Use this JS: $('input.{myFieldName}-label').attr('readonly', 'readonly').attr('onfocus', 'this.blur()').css('opacity', 0.6); How to sort the table A to Z by label Didn't realise there is a setting for this, great! Thanks. EDIT: Here's how I did it: \ProcessWire\wire()->addHookAfter('ProcessPageEdit::buildForm', function(\ProcessWire\HookEvent $event) { $object = $event->object; $form = $event->arguments('form'); $page = $object->getPage(); $page->of(false); if ($page->myField) { $toAction = 0; foreach ($page->$myField as $row) { if (!$row->value) { $toAction ++; } } if ($toAction > 0) { $form->prependMarkup('<div class="pw-container uk-container uk-container-expand"><div class="uk-alert uk-alert-danger"><span class="fa fa-exclamation-circle"></span> Check the <strong>Page text</strong> tab; ' . (int) $toAction . ' value(s) needs entering</div></div>'); } } });

@KrlosThat is strong looking to https://processwire.com/modules/seo-maestro/ The JSON Schema is not coming from that.

Hi @perplexed ah ok, i thought you were using special fields (tag/text and so on) for you rimage field, then i was thinking it would be easy just to put some strong and color in the description of the image field telling there are details you don't see but don't forget to edit those images and then fill those not visible fields for eaxmple i do this kind of thing when i use @horst croppableimage3 module to remind my victims that when adding an image to this field, you don't see it working but it generates a cropped variation and you can modify the framing to your taste thus don't be mad if you don't lke the result 😄 have a nice day

Hi @perplexed actually,in may cases thet' where the field description is very usefull and more, you could use a nice red strong to remind your user they have to fill something special thie module by @adrian will help you emphasise the part of the description you don't want your user to miss https://processwire.com/modules/dynamic-description-notes/ honestly, i don't know how far you are in your wensite dev but i would bet this is something you would regret as soon as you need one of the great image crop modules... (i can't think of one of the many xebsites i've made with pw that don't use at least one of them...) 🙂 have a nice day

Hi everyone, we’d like to share a small but handy module we developed at frameless Media: TextformatterSmartQuotes. 🧠 The Problem While working on a client project, we needed to replace straight quotes ("...") with typographic quotes (like „...“) — but only in the visible text content, not inside HTML tags or attributes. Using the TextformatterFindReplace module, a case like this: <strong style="font-size: 18px;">Improved "well-being"</strong> would turn into: <strong style=„font-size: 18px;“>Improved „well-being“</strong> which breaks the HTML. We tried solving it with regular expressions, but none proved reliable enough. Every approach either failed to match all valid cases or accidentally modified tag attributes. That’s when we decided to build a dedicated solution. ✅ Our Solution TextformatterSmartQuotes is a Textformatter that replaces quotes only in visible text, leaving HTML markup untouched. It supports the following quote styles: German: „…“ English: “…” French: « … » The quote style can be selected in the module’s settings. 📦 Installation Place the module in /site/modules/TextformatterSmartQuotes/. Install it via the Modules admin interface. Assign it to any text/textarea/CKEditor field under “Text formatters”. Configure your preferred quote style if needed. This module helped us avoid fragile regex workarounds and keeps content formatting clean and reliable. Feel free to use, improve, or contribute to it. You can download it on GitHub or via the Modules Directory We’re happy to hear your feedback! Cheers, Mike

I can’t believe ProcessWire Weekly is still going strong! Its 10 year anniversary was actually in May last year.

@adrian Interesting, I've been liking the white background that appears when you hover. The Original theme uses horizontal lines instead, so I thought the white background that only appears on hover was a better alternative, while still creating a strong visual row for the current hovered page. But if you don't care for that look, making the whole background white like you did in the page list seems to work well too. I like your new version much better too. It looks quite good, and easy to read as well. Yes, I've been trying to compile a list of things like this. But if it's something that NOT visible in regular usage, if possible, please post in the GitHub issues too so that we have instructions on how to reproduce. Though this one may already be there. Okay I will make note of this. And we're talking about the dropdowns that appear on submit buttons, and the Add New button in the page list, correct? (since the masthead dropdowns already have variables). How do I reproduce that one? This is how the repeater add-new button looks on mine: and this is how my file upload buttons look: @Mikel Thanks for reporting the small bugs, I hadn't see those yet, will add them to our list.

Thanks @jploch for your time, the thoughtful perspectives and the in-depth explanations behind the new theme direction. I’d like to add that – regardless of trends like monochrome color palettes – there are universal usability best practices, especially when it comes to complex interfaces. Renowned usability experts like Jakob Nielsen have shown that color differentiation and clear visual hierarchies are crucial for orientation, error prevention, and efficiency. Relying on just one color (even with accent tones) can make it harder for the user to distinguish between navigation, controls, content areas, and information messages, particularly in a CMS as flexible and powerful as ProcessWire. On the marketing and positioning front, it’s also important to recognize how much the market has changed. Many users today are looking for ready-made, hosted CMS solutions with out-of-the-box themes, rather than building or customizing everything themselves. When ProcessWire started, there were far fewer quality options available; now, even agencies often prefer SaaS CMSs for their convenience. So it raises the question: who is ProcessWire really for in 2025? Is it still mainly aimed at developers and agencies who need maximum flexibility, or is there a desire to broaden the target group? I believe clarity in both design and communication about the intended audience will help keep PW competitive and attract the right users, whether they value flexibility and control, or are seeking quick, plug-and-play solutions. Thanks again for all your efforts and the open dialogue – these conversations are what keep the community strong!

I don't have strong feelings about checkmark style versus toggle style checkbox controls. It sounds like some people do. I'm fine with regular checkmark style being the default rather than the toggle style, but I divert to the designers. I don't understand the strong feelings because they both represent the same selected (1) or not selected (0) states. You posted a screenshot with "light" (left) and "dark" (right) labels, and that is not what we are doing. Those labels make it represent something else. That relates more to our dedicated toggle Inputfield, which has an entirely different appearance. In the physical world, the checkmark style represents something we would do with a pen, and the toggle style represents something we'd do with our hands on a machine. If I think of an airplane cockpit, there won't be any physical check boxes and marks. The same is true with literally any physical tool or machine we interact with. On my Android phone at least, there are no checkmark style inputs in the OS, they are all toggle style. So I'm quite used to them being one and the same as check marks, which is probably why I don't notice one way or the other. But I do prefer checkboxes when they are unlabeled and in the far-most right column of a table, like a delete checkbox, because it uses a little less space, even if a toggle style checkbox might be easier to click/tap vs. an unlabeled checkbox.

@ryan thanks for doing this work! For process modules, I want to point out that you can use variables like this color: var(--text-color, #000); This will use the light/dark color from the new theme, but default to black if the variable doesn't exist and, therefore, work on the current theme also. I tend not to agree with this. The submenus have a completely different feeling than the main menu, since they are boxed and stacked vertically and allow for a much stronger marking with the background. The size of the font is also smaller and denser, and it's readability would suffer more with a lighter color. Also, unlike the main menu, the links in the submenus are not even marked with the active class, since many of them don't even represent pages, but actions. There seems to be a strong reaction against the toggles, and some good arguments. Although I would argue that, comparing to the light switch situation (referred on a blog post linked in the other thread), our toggles on and off states are unequivocally clear because of the use of muted vs strong colors. @jploch and I really like how the toggles look like in the theme, but are not insensitive to the requests. We'll discuss possible solutions with @ryan. I personally made a point in keeping the number of css vars low. I'm totally open to tweaking them, and adding a couple more, but I will definitely not add a bunch more. The idea of these variables is to allow users very easily create a different feeling to the admin, by only changing a few colors. Having few variables and making them depend, by default, on other variables, allows you to completely change all the colors with defining only 5 or 6 variables. You are correct that changing the background also changes the button text, the reason is that, like this I know for sure, that whatever colors you chose, there will be contrast between the background of the button and the text even if you don't define the (--button-color) variable yourself. For a complete change and control of the admin theme (not only colors), I would say it's better to with the original theme or AdminStyleRock and LESS. Again, this doesn't mean that we can't tweak the variables to account for cases like in your example. There's no special reason why it's --muted-color and not --muted-text-color. In our opinion, the most important information on pages list is the the name of the the pages, and the most important action is to find the page you need to work on. The action buttons are always the same, and so, it's much easier for you to find the one you want to activate, then looking for the correct page on the list. Most of the time you will even be clicking "edit", which is the first one to the right of the page name. That's a very automated process. Also, in our case, "muted" does not mean unreadable. We want the hidden pages to be as easy to find as the non hidden pages, and easier to find than the action buttons. For us, using a softer color makes it softer to the eyes that a string of words appears from nowhere when you hover the pages in the list. Again, I'm willing to tweak the name of the variables to make them clearer, and even add a couple more variables to the list, but I wouldn't be happy to add a bunch of new variables and make the system more complex.

We will look into adding these. Okay, can look into this too. This is supposed to be low contrast because it is non-essential information. It's the sort of text that we don't want to have your focus unless you are specifically looking for it. Admittedly I like the contrast, but I also like anything easy on the eyes, so will definitely give it a try. I'm not seeing it currently, but have definitely seen it before, and before the new admin design. I think it is related to the Inputfields JS for 'showIf' dependencies rather than the CSS of the admin. Look closer, there are definitely functionality upgrades here. Just to name a few, the masthead is now sticky and always available, the navigation dropdowns are quite a bit better as they scroll within rather the whole page, the top search now acts more like a command palette (with its own hotkey), and much of the admin appearance can now be easily styled with CSS variables.a I think forcing is a strong word for giving people the option to decide whether they want to use the Original look or the new Default look. In your case it sounds like you'd want to continue using the Original style for AdminThemeUikit. As mentioned a couple of times already, it will always be there, it's not leaving. That's correct. It'll be the default on new installations. The Original option will be there for new installations too, even if it's not initially selected. Users on existing installations will have the option of switching to the new default look if they want to, but it won't be the default on existing installations except on the dev branch while our beta testing proceeds. Do you mean the headers of repeater items, or literally the inputs? I like using the main-color as the background color for AsmSelect items, PageAutocomplete items, and repeater headers, so that's part of my custom CSS. @cst989 Sorry, I'm not trying to call you out. Having a cake to decorate was meant to make you laugh. We have a diverse community with lots of different opinions on design, and all are valid, I didn't mean to suggest otherwise. I've been trying to be clear that I'm no authority on design, and so that's why I'm trusting full time trained designers that know PW really well. They have a lot of success stories in their portfolio, and I'm confident PW will be one of them. But design is always tough because it's so subjective. For your preferences, it sounds like the new design isn't a good fit, and that's fine. But if you like the Original design, then know that it'll always be there too. ProcessWire is slow to get new users in large part because our admin and website often look dated to people that aren't already familiar with ProcessWire. I'm pretty sure that group of people will be more likely to explore ProcessWire with the new design. I think once you see the new website, the overall branding picture will be a lot more clear as well. I don't expect anything designed to appeal to everyone, but I'm confident this will help PW to grow.

@bernhardI think that functionally the new look is better in this regard because the lines are limited to the actively hovered page. That makes more sense to me. I'm not sure the Original lines have any actual purpose. So not sure why I put them there other than it was part of the design style/trend 10 years ago. 🙂 Though if someone can find a strong functional reason for the lines where it provides some benefit to the user, then that would be worth having a toggle for. You mentioned that it would "help" some users. Is that because it's a more obvious clickable element? That seems more functional to me, and maybe something worth having a toggle for. I'm indifferent myself, as I don't really have a preference one way or the other. But worth passing along to the designers to see what they think. From the PW standpoint, this is the "message" notification, which is one that's informational and not supposed to call attention to itself. In that respect, I think the color is ideal and much more consistent with the purpose of it. But maybe something to get used to, as the Original design was more "in your face" with it's message notifications, even if it wasn't really supposed to be. The Warning and Error notifications are supposed to call attention though. I have that same "doesn't feel quite right" with most dark modes. But have to admit, the one in the new admin design feels just right to me. Maybe that's because I've been using it more than a month now. But once I tried it, I was hooked. Of course, there's always room for improvement. The new design makes it easy to adjust things with the CSS options, so it's easy to test things out, such as the background color you mentioned. If you have more specific suggestions over what would make it feel right to you, definitely share them. As of Friday's updates, if you provide an SVG logo that has as fill="currentColor" then it will inline the SVG and the new design will be able to use the new light mode or dark mode main color for the logo automatically from its CSS. Thanks, I didn't realize that, I think the the installer must have been in light mode when I tested it. I will test it in dark mode and fix the colors. I will look into adding this, not as new configuration values, but as extra inputs that get populated with the hex code when the color picker changes, so that you can change it if needed. Probably just a little JS should solve it. There's no plan to drop the original Uikit theme, but it's no longer going to be the default (at least for new installs). But we do plan to remove the AdminThemeDefault and AdminThemeReno from core and maintain them in as modules separate from the core. Maybe. We can see where we're at when we get closer to merging to master. Though if we did that, I wouldn't want existing installs to be unaware of the new addition either. So for existing installs, maybe an option to select it on a user-by-user basis, and a one time notification that tells users about it and how to switch between the two. Currently only the superuser can make this change, but I think it would be good for it to be selectable on an individual user basis.

AI, Cursor, Windsurf, Claude Code... you name it. In terms of ProcessWire they all need a strong hand that guides them through different tasks, ways, and whatever its in the way. You need to oultine your part in ProcessWire in great detail. You need to define hooks, the solutions to use - from ZIP to TempDir. You have to outline the forms it needs to render and the fields to use from start to finish. You could give an existing module as baseline, but beware it knows what to do then. But extending existing modules works pretty good - see my fork here of GUID/UUID Generator Whatever tool you use, it knows the baseline I knew 2 weeks into ProcessWire back in 2014 after doing the tutorials and reading the forums. Hint: Let Composer/Cascade finish the tutorials - it's wild! And let them create rules, workflows and memories from it. You will reach a junior-junior grade PW-dev this way. BUT (big time)... it's great and even superior in terms of PHP. Do the outline, from start to finish, do what you know in terms of ProcessWire. Let the AI/IDE/Agents do the PHP part, including docs, and you will be happy. Sure... not that much fun as people have that use NextJS (13, and maybe 14, but not 15) or AstroJS (2,3, and parts of 4, but not 5)... but hey... that's still only JavaScript (maybe Typescript) those AI/IDE/Agents are good at - the concepts still need either docs or a solid foundation. In the JS-world everything is a pattern, everything is JS or TS, the concepts are the same. But framework-specific... is another story. Laravel works great. Ok, maybe not the latest version, and maybe not all the extensions, like Forge and Filament. But yeah, it works. Even migrations. Depending on the database. And don't try Supabase or Neon. That's super wild. But... older versions with just *.blade.php - works! Flux, InertiaJS, VUE, React? meh I am still not a coder/developer/programmer BUT... I know how to write a technical concepts and know how to outline modules, hooks, whatever in ProcessWire. The moment I realised that those tools are great at PHP, and s*ck at ProcessWire - I understood what to do. A new project I work on, a NextJS/AstroJS/ProcessWire-combo, has already 50+ documents to outline which tool does what and how to do it. And I didn't even really start to outline anything in terms of modules or hooks. The ProcessWire part, or at least a big part, is already outlined here: https://github.com/webmanufaktur/pwai/tree/windsurf Which is the latest commit with most of the stuff needed - for my projects. But yes... those AI/IDE/Agents only see patterns and try to match up - in frameworks. To give a bit more helpful details here: AutoTemplateStubs is a great addition to help your tools to understand what's happening. In case you hate to do everything yourself: RockMigrations has some nice .vscode snippets that help and most AI/IDE/Agents understand it and can create templates and fields right from migrate.php. Noice!

Hi again, actually it's sooner in the code that i would have siwtched to array functions like foreach, map and so so on, more something like $allEvents = $pages->findMany("has_parent=$player->id,template=event,date>=$dateStart, date<=$dateEnd"); foreach($allEvent as $ae){ if(...) { // here come your conditions like $e->template == '... ' $ae-date>= and so on $player->negAttitude = ... // and here trhe details/pages... you store } } the case you descibe is normal, allEvent (result of a pages find is an array of pages and as much as i love working with objects, php is reallt fast and strong with arrays and in your code you switch from object ($pages) to array ->find() result) and then again to object methods ($player->negAttitude = $allEvents->find...), i can try and guess why foreach may become a little reluctant to eat what you give 🙂 honestly, what i do in this kind of situation is to dump/print_r the result step by step to see exactly what i get and then which will be the best method to use and parse it and of course, once i've switched from object to array i try to stay with it to avoid surprises 🙂 have a nice day

I may be missing something glaringly obvious here (I am admittedly tired!)… I have the text formatter TextformatterMarkdownExtra applied to a field that uses EasyMDE in the front end. If I add HTML to the field it gets putput as is. E.g. This is <strong>bold</strong>. This is bold. I thought Markdown would trip out HTML by default. Indeed, in the module settings if I submit the under the Test Markdown section I get: <p>This is &lt;strong&gt;bold&lt;/strong&gt;.</p> But on the front end it renders as: <p>This is <strong>bold</strong>.</p> Any ideas? It's not a massive issue as a client wouldn't typically even know what HTML is but thought I'd check. EDIT: I just tried another site and the other one seems to work as expected but I can't see anything different in the settings! The only difference I can see is the site that doesn't work uses 3.0.229 and the one that does uses 3.0.246. Both use the same version of TextformatterMarkdownExtra (1.8.0).

I got yesterday exact this question from a client. He has 5 different languages. When he corrects one word, it is not very comfortable to update the other translations. Personal, I don't have a strong opinion if that has to be default or not. I have to go to the config screen of fluency anyway, to setup it.