Leaderboard

I am with you @EyeDentify when you praise PW's simplicity and easiness to start to get around. But PW is also great being a powerful framework. Ryan always managed to balance things perfectly. New cool things like custom page classes never disturbed ones that didn't need them. So I am sure we can easily move forward making PW more suitable for larger projects, multi dev on the same project, more best practice compliance without sacrificing simplicity for the newbies.

Clickbait title aside, I recently found a cool new feature in PHP 8.1 and wanted to share it with you, in case you didn't know this either. Starting with PHP 8.1 you can write $this->method(...) (yes, that's the actual syntax, not a placeholder) to reference a method. I find this super convenient, especially for defining hooks. Plus the IDE can refactor this much better than the traditional [$this, 'method'] callback. <?php class MyModule { public function init() { $this->addHookAfter('ProcessPageView::finished', $this->doSomething(...)); } private function doSomething(HookEvent $event) { // TODO: something } }

Hey @ryan thank you very much for the invitation to write a blog post. I'll probably ping you about that when my client projects that I'm working on are done! Regarding selling modules: I want to add that it can be very complicated to sell stuff online in the EU due to tax regulations. In very short as soon as you hit 10.000€ revenue you need to charge tax in the country of the buyer, which can be 7% CH, 19% DE, 20% AT etc... There are companies that offer the service to sell stuff for you, so you only have one customer instead of hundreds. But they charge for it, of course. So if you ask me it would be ideal if PW had a shop for commercial modules where all you have to do is add a github link to a private github repo and PW does the rest. Which is invoicing, taxes, generating license keys, offering download links etc. I know it's a huge task to do, but if I'm just sharing my point of view from selling modules. It would also be great if the customers were able to update modules with one click, just like they can do with regular modules. In case of commercial modules the'd need to have a valid license key in their settings, of course. And of course, that should only be done on development environments. I'd be more than happy to pay a reasonable share for that and support the project with my work. ------------------------ But what I actually wanted to say: @ryan could you please make it more obvious how great PW is and how actively it is developed? I think @teppo does a great job with his weekly newsletter and that also deserves a lot more attention! I just checked the website and the github repo again. I know we've "lost" people just because they looked at the github repo and saw the last commit on the main branch was over a year ago and they thought the project is dead. We all know better, but newcomers don't and the amount of work put into PW is unbelievable and people should instantly see this! I also checked the download page on the website: These two buttons probably don't mean anything to a newcomer. And the sentence below is really hiding itself. What about something like this? The breaking change thing might get a footnote that we are talking about breaking changes to the API here. English is not my first language so there might be better wordings, but you hopefully get the idea. Or maybe something like this: I think "we" already have an absolutely great product and we can be very happy to be able to use it. @ryan I hope you are very proud ? But I think this is not obvious to someone evaluating ProcessWire and maybe we could do more in that context. I don't know if growing the userbase of PW is a goal of @ryan at all or should be. But at least for selling modules it would be a benefit. Also when looking for a job it's a lot easier to find an employment as a WordPress dev compared to a PW dev, I guess. An interesting retrospective: I remembered we had a discussion about this topic some time ago. Turns out "some time ago" was 2017 ? https://processwire.com/talk/topic/17348-is-pw-becoming-more-popular/ It's an interesting read and shows that the same still applies 7 years later. wow. Ok so I googled a bit and found that the current website of processwire.com seems to be from 2019: https://processwire.com/blog/posts/pw-3.0.124-and-new-site/#new-website-launched And while I can remember that a lot has improved it's still not a great website at first sight, to be honest. @ryan please don't get me wrong, I know it's a lot of work and it's a great website and I know it has a lot of great stuff under the hood (like multiple instances talking to each other via API and bootstrapping, etc). Or take the blog post: That's great, but no website visitor will ever realise that! All a first time visitor will see is an more or less default UIkit theme which looks outdated to be honest. Compare that to some agencies from the showcase section (eg https://typneun.de/) and you'll notice a difference ? Maybe one of them would be happy to sponsor a facelift for processwire.com ? At least @heldercervantes showed his interest in that in 2017. Ok, so I explored a bit more... And compared... What do the folks at Nette do? From the Design imho not a lot better if at all, but I love the catchy statement at the top and they instantly show some big brands that sponsor the project which instantly builds trust. I'm not a marketing or communication specialist, but this is some basics I realise. I'm quite sure we have experts that find a lot more room for improvement ? I'd also love to see sponsorship packages for processwire where agencies can support the project and also SHOW the support. Something like this maybe: Gold sponsor Logo on frontpage 999$ / year Silver sponsor Name on frontpage 499$ / year Bronze sponsor Fund 1 hour of bug-fixing 99$ / year Maybe github issues of gold sponsors could be addressed with priority or such. I don't know. Don't get me wrong again. I like that PW is not dependent on someone elses money, but it will definitely not hurt to add the opportunity for PW users to give something back without asking for any return (which is different to buying pro modules). I know that many buy pro modules just to support ryan, which is nice but again is not obvious and does not build trust for anybody viewing the pw.com frontpage. Ok so I jumped back to pw.com ... For the record, here is a current screenshot: So I clicked on "demo" - I haven't been there for some years... Ok... Frontend... Ufff. 2024? Doesn't look like. And again it hides all the beauty that lies under the hood. Ok, so over to the backend demo: A lot has been said about the pw backend already, this shows that it might be a worthwhile area to work on. What it shows is a big orange warning about an .htaccess issue. This is probably not a good invitation for anybody new. Maybe it even draws people off. Instead it should show a huge warning like this: What if we dropped the skyscraper profile and instead built a new modules directory which can serve as a new showcase? Keeping a profile up to date that is not used (and probably not of any use other than showcasing pw) is maybe unnecessary work if the same thing could be done with something that creates additional value. Also I think it could be good to showcase the PW can be an absolutely great choice for modern frontend tools like TailwindCSS, AlpineJS or HTMX. I think we could really do a lot on that front just by thinking less about the product (pw is great and I think that is not going to change, whatever we do or don't do) and more about how to communicate this. What about a section where we showcase "ProcessWire as XXX Alternative in 2024" Many people are unhappy with existing CMSs. If I was unhappy with WordPress I'd probably google "wordpress alternative 2024". Many products do that and have comparison pages on their website where they show strengths and weaknesses of both tools and by that make it easier for people to understand what PW is, what it can do, where it is good at and where other tools might be better. This post has again got far too long ? But one final note: I think it would be great if PW not only was a great product but also helped people using the tool make money. What do I mean by that? IMHO ProcessWire does not sell itself. It can be hard to compete with other tools that are more popular. At the moment basically anybody doing business with PW has to "sell" processwire as the correct tool on his own. Not everybody is good at marketing though, so it would be great if that was done by experts. For example we could have professional guides why pw is the right tool for job x or y on the official website. Like @dotnetic's post for example: https://dotnetic.de/blog/processwire-the-best-cms ; Edit: Note that I don't think that this is the responsibility of PW, but I try to say that PW could make it easier for us on the marketing front and everything that helps people that are using PW make money will help the project as they will have more money to spend or more resources to contribute or have more spare time to share modules with the community. The idea is to establish a strong win-win situation. I don't know how exactly but I'd love to see processwire being a tool that, when chosen, let's the dev assured that he/she can on one hand trust the product and rely on it and on the other hand also know that there is a market for it so that he/she can make a living and that it's worth learning and exploring the system. PS: If anybody has not yet starred the pw repo and is still reading, please do it now ? https://github.com/processwire/processwire

Thanks @BitPoet I have never heard about this config settings property, but I will give it a try.? It happens only on a testing site, so I have changed the site from multilanguage to single language and then the error was gone. So the problem is only on a multilanguage installation in my case.

Ha! That did the trick! ? Thanks a lot! Went through the whole installation process a third time, and now everything worked out fine. The .htaccess file in root now looked *completely* different, must have had something to do with that. ? Thanks again for your help!

@Tiberium how are you detecting the languages exactly? I am using the Accept-Language header because it's simple and works almost every time. Here is the snippet I am using which is in readySite.php because this should only run on the frontend. Note that this requires the Language template to have the custom field 'iso_code' which I am always creating no matter if the site is multilingual or not. <?php namespace ProcessWire; /** * @var ProcessWire $wire * @var Session $session * @var User $user * @var Page $page * @var Sanitizer $sanitizer * @var Languages $languages */ // language detection, also make sure language detection only runs once if ($languageHeader = $_SERVER['HTTP_ACCEPT_LANGUAGE'] ?? false) { // see if we have run detection before if (!($session->get('http_language_detection_done'))) { // in any case, we got a header and can indicate we did run detection (even if it's not successful) $session->set('http_language_detection_done', 1); if ($languageInHeader = Locale::acceptFromHttp($languageHeader)) { // map the value to available codes $isoCodes = $languages->getAll()->each('iso_code'); $preferredLanguageCode = $sanitizer->selectorValue(Locale::lookup($isoCodes, $languageInHeader, false, $languages->default->iso_code)); if ($preferredLanguageCode && $user->language->iso_code !== $preferredLanguageCode) { $requestedLanguage = $languages->get("iso_code=$preferredLanguageCode"); $session->redirect($page->localUrl($requestedLanguage), false); } } } } Do you have a better approach? Without JavaScript that is. I don't like that at all.

It’s not a folder, but the URL http://localhost/processwire should be accessible and show a login form. ProcessWire dynamically handles such URLs using, among other things, the .htaccess rewrite* directives. I believe you’re asked to optionally rename the admin URL during the installation. Some people like to do so to obscure the login page from attackers. If you have entered a custom admin URL and forgotten it, you can check the database table “pages”. It should be ID 2. But maybe just try reinstalling from htdocs. It shouldn’t give you any htaccess problems IIRC. I spun up a PW installation on XAMPP on Windows only a couple weeks ago and I don’t recall having to change anything apart from enabling some optional php.ini features ?

You should be able to append the required settings to $config->dbInitCommand.

Yes, if you only plan to access PW on http://localhost I would just do that. If you want it to accessible at http://localhost/processwire-master I believe you need to add RewriteBase /processwire-master/ to section 8A in the .htaccess file. The processwire-master directory is only put there by GitHub, it doesn’t really “belong” to ProcessWire per se.

We choose also via language, not country. In the end, it is important what the user speaks, not where it lives (in the case of most of our customers). For automatic redirects, we also use only the first two letters of the browser sended Language code. The language itself. As by example of switzerland: de-ch, it-ch or fr-ch. You see that the language came first. For you I would ask, is that a site who will have special/other content depending on the country (because other products or other prices) or will 99% the same content, but then in the other's language? Is it the first, then you should separate it like poljpocket suggested and consider there multi language approach, if that make sense for that country. Is it the second case, then you should primary focus on the language

Since it looks like there is a some crossover with Mystique, and it also looks like that module is active and supported, I'll release this module in ProFields instead. That way it's not competing with Mystique, which looks to already be a great module. I'll focus on making Custom fields have some features that maybe aren't available in Mystique, like ability to query from pages.find and perhaps supporting some more types, etc. Plus, the new module fits right in with the purpose of ProFields and a good alternative to Combo where each have a little bit different benefits to solve similar needs.

@Jonathan Lahijani Sort of, but it's not just that. I'll go into the details once I've got the storage part fully built out. It supports any Inputfield type that can be used independently of a Fieldtype. Meaning, the same types that could be used in a module configuration or a FormBuilder form, etc. It can be used IN repeater fields (tested and working), and likely in file/image custom fields as well (though not yet tested). But you wouldn't be able to use repeaters or files/images as subfields within the custom field. Files/images will likely be possible in a later version though, as what's possible in Combo will also be possible here. Yes, if you use the .php definition option (rather than the JSON definition option) then there are $page and $field variables in scope to your .php definition file. @MrSnoozles Searching yes. Can be used in repeaters (yes), but can't have repeaters used as subfield/column types within it. @poljpocket Yes. While I've not fully developed the selectors part of it yet, the plan is that it will support selectors with subfields for searching from $pages->find(), etc. @wbmnfktr The API side of this should work like most other Fieldtypes with subfields, so I think it should be relatively simple for importing and may not need any special considerations there, but I've not tried using it with a module like ImportPagesCSV yet.

Hello There @ryan just wanted to add my concerns here. I am not an "advanced" developer, i just develop sites or conduct experiments on my own personal website thats been running PW for a very long time now. That being said, i have read through this tread and i have become a little worried that PW would be going away from it´s root that made me many years ago fall in love with it. I am concerned that many of the more advanced users of the CMS want´s to take it to a more complicated place instead of keeping PW simple for us beginners to pick up and use wich is why i love it. As a laymans dev i can actually understand most of the API and what i can use it for. Ryan have made some posts in this tread that makes me feel calmer that the core simplicity is not going to go away. I also feel that many of the more advanced devs are missing the point of PW simplicty and why not everything should be in the core. There is modules for a reason,, want something special?, then create a module. Reasons PW appeal to me: 1. It´s API made sense from the start, logicaly and was adopted fast by my Authistic brain. 2. It´s does not interfere with how i want to render my website. 3. It´s has a great admin backend that should not confuse anyone. 4. PW is not WP. Thank you all.

Well... processwire.recipes uses Astro as of right now, therefore not a great example but... I can offer processwire.pw as a demo platform and resource. Yet I'm open to move processwire.recipes over to ProcessWire and the community. That's why I re-booted it. It's for the community - not me. Btw - I was finally able to get the old domain / @marcus: As I mentioned Astro here... they have an awesome way to communicate their progress and they move pretty fast. Their versioning and communication, community talk and support on social media is on point. Maybe those points should be added to the ProcessWire 20XX agenda as well. more community work* more visibility in social media* more activity in social media* * yes, that's most of the time on us and not on @ryan more communication and posts on processwire.com/blog every weekly forum post should be a blog post, and the blog should be the leading source (my opinion) - right now it's in the forum, but... a new thread in the forum with a link to the blog post would work for me and would be even better for everyone. As mentioned before: it's about marketing, therefore the blog should be the leading source. (Change my mind!) blog posts should be posted on: X/Twitter, Facebook, Reddit, Discord ... whereever we have an official home or community - and even in non-official homes. final solutions from the forums which involve PHP/API code should/could be posted to processwire.recipes (ping me to add that recipe if you like!) for ProcessWire, modules, hooks, hacks, ready.php, whatever it's easy to add a recipe Thoughts about Demos and Profiles each and every profile should be super close to the user, the user's needs and therefore a longliving and understable profile and concept. Examples should be timeless, therefore no need to update them once in a while: Skyscrapers ? American Diner Restaurant Classic Movies Collection Grand Mom's Recipes Antique Shop Inventory Billboard Charts History these examples alone would support everything we all ever faced and built - I guess. (Apps not included, but as starters) all these examples would build a solid foundation for all kinds of websites and projects we face nowadays (still apps and custom things not included) I repeat myself here but I can offer processwire.pw as a demo platform for that, all we need is long-term Hosting SSL CI/CD deployment and/or someone that maintains those installations

From my perspective this is mostly spot-on @poljpocket. Yet there are a few things I'd like to add here: those of us that are active in the forum, read the weekly posts from Ryan, read weekly.pw from Teppo and follow every last bit... ProcessWire is evolving each day, each week, each month, all the time. YET... the last commit to master was 9-10 months ago, which is a century or two ago in the fast-living webdev-world - mostly due to the JS-sphere. I know a lot of people that look very close at this metric, but unfortunatelly on the wrong branch in this case. I'd love to see (and I personally keep it this way) the master branch as something like an LTS, while dev is more like a stable-rolling-release of some kind. I'd probably even use an unstable branch in some projects, even though there is no branch for it. BUT this isn't about naming, but MARKETING. And the last push on master is really bad marketing for ProcessWire right now. That's all I am saying. It doesn't look good. This needs to be changed. I don't care how, but it needs to be fixed. Fast! I don't care if we use SEMVER, ROMVER, WHATeVER, or any other way of versioning (besides the one from Ubuntu, which is really a bad look in the long run and introduces a lot of stress as there has to be a release no matter what at a specific date). All I need to know is if there are breaking changes or new requirements, like min. PHP 8.x and similar. I won't see (as in recognize) this in the version number and wouldn't even think about breaking changes the moment a ProcessWire 4.2 pops up in my upgrade module. Yeah, sorry... I just click UPGRADE as most of the users out there. Maybe the upgrading process/module needs a few upgrades, tricks, and markers to show and tell breaking changes, changed requirements, and what not. Sure more work for module developers but probably not really. Modules already have all these details like requirements. I'm not that deep into developing but as a user... that would be nice! One more thing... In this thread a lot of things were mentioned but mostly like "I'd like to have this feature and this, and that, and ..." which is fine. I'd support most of that. But I'd like to know and ask: Where do we want to see ProcessWire in 5-10 years? What can I do to support ProcessWire/Ryan more?

I think this is the wrong approach. Country is not relevant if we are only talking about language. Many countries have several languages, and each language is used in several countries. In some countries a part of the country uses one language and the other one another language (Belgium for example). From the visitor point of view this is confusing, a visitor thinks in term of language, not country. In terms of implementation you are choosing the more complex solution, if PW is straight forward for managing languages, you'll have to develop a solution over this language management for managing countries.

Remember that if you have all your country sites in one installation (without my inputs below), you are stuck with one set of Templates, one set of Fields and one set Languages (PW's term for localizations). From experience I can tell you that the more sites you have and the more different markets have to be reached, the more you will run into problems. Mostly, these will manifest in content only to be available in select regions and not others. I am from Switzerland and you could think, a site here should be in German and then offer a carbon-copy for French and Italian. Sometimes this is fine. For sites with multiple regional target audiences, I was immediately proven wrong though: The french want a banner for their super discount only the store in some location gets and the italians want a blog post which must only be available in their region. Remember, that a ProcessWire instance has one and exactly one default language/localization and all content must be available in this one language in order for the others to work. Now this is one country. You have multiple! Simply because of that, I would most likely use completely indepentent installations for every country. But PW has you covered! Here are some ideas: Building on @wbmnfktr's answer, there is also multi-site support in ProcessWire. This is where you have separate site folders with separate databases but all under one roof. More info here: Multiple site support in ProcessWire CMS. There is also multi-instance support which would allow you to e.g. fetch data from other installations (e.g. other countries for you). More info about this is here: How to use multi-instance in PW 3.x (processwire.com). You can use the multiple-site approach for your country pages. With this, every country has it's own set of Templates, Fields and Languages. They can mostly be the same but don't have to be the same at all. This allows for flexibility and sites to diverge from the "standard" as needed. On top of that, multi-instance would allow you to for example have a central newsroom section which gets displayed on all your sites somewhere.

Not really a solution but other things to keep in mind: Switzerland (CH) German (CH-DE) French (CH-FR) Italian (CH-IT) Canada (CA) English (CA-EN which is most often EN-EN like UK) French (CA-FR) USA (US) English (US-EN) ... maybe spanish as an option, depends of a lot of things UK (UK/EN) English (EN-EN) So... you might have a bigger challenge here as you have to separate the country and the languages and sometimes even have to be careful which english you use - American VS British English. Best example could be the Privacy page. It's different in every country due to legal differences, but needs to be available in 1-to-n languages in a worst-case scenario like Switzerland. I'd probably start with country-specific page trees for every country and go from there, like this: Home / Global as a gateway to select a country US / Homepage for the country ... CA / Homepage for the country ... DE / Homepage for the country ... Pages below those Country pages could have all languages you define in the backend, but you would only activate those necessary. You would have to mirror a lot of pages - but maybe this could be fixed with references or something. I remember a thread with a very similar challenge but couldn't find it. Maybe someone else has a link or more ideas.

Very interesting and reading through it, I was also instantly reminded of Mystique. And also, why I am almost never using fields like it. That is because of it's almost complete lack of support for selectors. Looking at your example, I am immediately thinking of problems like this one (people which have an email set, e.g. to filter contacts for a mail send operation): <?php $emailContacts = $pages->find('template=person,contact.email!='); Does your implementation support this? Mystique doesn't and you are stuck with loading everything and then filtering manually once the JSON is decoded.

I think ProcessWire has a well-estabilshed versioning plan: Ryan is increasing the version every few commits whenever some notable new feature was introduced. And the master version then just follows suit. I think a set release schedule with fixed time intervals is a very bad idea. I have been working with WordPress in the past and they have been notoriously bad at using their fixed minor release schedule. Sometimes a version introduced very important and big features and other times, there was barely anything new but both were minor releases just because the schedule said so. I have only been in the ProcessWire game for almost three years and thus have started out around where version 200 was released. At that time, I didn't look at GitHub too much though. I didn't notice the "slow releases" at all and was mostly influcenced by the forum and the website. For me, they did a good job. As many before me have mentioned, community activity is very important especially for new potential users (and even more to the target audience: fellow developers). This could also be reflected in more activity on the master branch. Finding a good solution might not be the easiest endeavour though. Has there ever been a situation where old versions needed to be patched for some bugs or security vulnerabilities? I haven't seen one yet. I think this mostly stems from the slow master releases which only ever get done when high stability has been reached. So for me, every master release is a "LTS" version, which is a big strength of ProcessWire: I have no reason to ever update a PW website I did years ago. As long as it doesn't get outdated because of external influences (PHP EOL comes to mind). I think using time-based releases like Ubuntu or Windows don't make much sense for ProcessWire. Years give a feeling of outdatedness. This directly contradicts ProcessWire's strengths: It does away with the stability and ease of upkeep arguments. How do you explain to a client that PW 2016.3 is still completely fine in 2024 and doesn't need any updates whatsoever? With operating systems, you want a sense of outdatedness simply because there is much more incentive to update to never versions, e.g. for hardware compatibility or platform support. Why not stick with semver with a few adjustments? One idea is to keep the patch part of the current versions as sort of like a build number which would primarily be used on the dev branch to indicate new features and fixes. And then every master version gets a minor version bump which corresponds to a dev version (indirectly that is). This would then allow for security fix updates down the road. Not that this would be needed much :).

@ryan What I was thinking looking at your syntax, is that it looks a lot like Rock Migrations syntax. If Combo pretty much does what you need but is too slow defining through the UI with a lot of subfields, if Rock Migrations fully supports Combo, then it would be very easy to define combo fields in code like you've done. Although Rock Migrations is primarily about migrations, it takes a definition in code of the state of fields and templates that looks a lot like what you've illustrated, that's easy to move between dev and live environments, so it's absolutely possible to use it to define fields, and you can be selective about it. If there are fields or templates you want to maintain the traditional way via the UI, then don't include them in the migration definition files. It's not all or nothing. On the other hand, because it works with fieldtypes, if you start out doing things via code, then decide you want to make some tweaks via the admin UI, that's possible, as it displays all the code for a field definition, that you can copy and paste back into the migration file, so it can work both ways. I'm not sure if it needs some tweaks for your use case scenario, but I think if Combo does what you need but is too cumbersome to define via the UI with a lot of subfields, then as long as it works with Rock Migrations, then it would probably be an existing way to achieve something very similar. As always with ProcessWire there is often more than one way to achieve the same outcome. ?

This approach to defining fields looks not unlike what Bernhard has done with Rock Migrations, although admittedly, in his case they're not subfields. I haven't checked to see if the Combo fieldtype is compatible with Rock Migrations, but if it is then that might be another way of achieving this, with the bonus that Rock Migrations lets you have it both ways; you can define your fields in code or via the ProcessWire admin UI. If Combo isn't currently compatible with Rock Migrations, it would be worth ensuring that it is. I think there's this overlap because I'm not sure if @bernhard uses ProFields, and I'm not sure that @ryan uses Rock Migrations as you each have different workflows, but in this case it might be worth checking out each other's efforts. A couple of options I can think of: Talk to Bernhard about including Rock Migrations in the core. Pros - it's always there. Cons. It's always there, and for simpler sites where people are happy to use admin UI may be unnecessary. Build an empty site profile just with Rock Migrations installed. That way when someone needs to start a new project with this functionality they can get it straight away when they set up a new instance of ProcessWire. Pros - There when you need it, not when you don't. Cons - if you've already set up your site profile and realise you need it can't go back and reinstall profile (but still really easy to install the module from the directory).

RockMigrations v5.1.0 The automatic detection of the php version/command on the remote when using deployments has been further improved and some issues have been fixed. Breaking Change: We now share the sessions folder by default on deployment. If you don't use RM deployments there is no breaking change and you can simply update. Another fix for deployments: We now use a timestamp like release-20240801220000-12345 because github deploy ids jumped from 999... to 1000... which broke the folder rename operation of deployments. Added automatic modules refresh on $rm->installModule(); Before this change I sometimes had the situation that I had to do a manual modules::refresh on my remote after pushing a new version that installed a new module. This is not the case any more ? You can now (again, as this has been there before but was removed in the last release) define the remote PHP command in your deploy yaml file if the automatic detection should not work for whatever reason. Simply add something like PHP_COMMAND: /path/to/your/php_binary_81 Added getTemplateIds() method that can be handy when PW wants template ids but you want to define that in a human readable way like $foo->bar($rm->getTemplateIds(['home', 'basic-page']));

I don't think it's bad to have less frequent master versions, it just needs to be clear that PW is VERY actively developed. Maybe I'm not the right person to ask, though, because I'm always on dev ? But in terms of marketing I think alone such a schedule could be worth gold: https://ubuntu.com/about/release-cycle This alone says a lot: They have a plan They care about their product and their customers When choosing a recent version (24.04) I'll likely be fine for the next 10+ years until 2036 They still support 14.04 which is more than 10 years old, which says a lot I as a customer know what to expect A lot of that is true for PW as well, just nobody knows. In some parts we are not there yet (I think part of that has already been mentioned as versioning chaos or similar). So maybe instead of semantic versioning we could introduce PW 24.04 LTS and PW 24.10, 25.04, 25.10, PW 26.04 LTS... I think having such a release cycle could help in many ways, like working on clear roadmaps, prioritising issues or features and it could also help developers in what to tackle and what to just wait for until it is built into the core or a pro module. Also, having a 10 year LTS would be an incredible strong marketing signal! And PW - as we all know, but many don't - has always been like this, which is outstanding. --- I have to leave unfortunately --- So what if we used the PW developer directory for this instead? I think this would be a win-win again. First of all we showcase our developers instead of skyscrapers ? We show that PW is used by many developers around the world and when done correctly this could also be such a thing that I meant when saying "help devs to make money". For example if that profile looked really good and showcased the skills of that developer, he/she could use that profile to show his/her skills and credibility to customers and hopefully sell more, make more money, contribute more to PW, etc. Every PW developer should feel like a hero, not a stranger using something that nobody else uses (again please don't take me word by word). We could maybe show the forum post and like count, show badges, show site of the week awards, etc. This could serve as a kind of gamification on one hand but could serve a very serious aspect on the other hand: Help the dev grow as a dev, grow as a business, grow as a person. It could show statements of other developers, like "what others say about me". So if a potential client doesn't know a developer the developer could share his PW profile and it might help in getting the job. Thank you very much. Glad if something was helpful! Now I really need to run. Marketing experts, the stage is yours ?

@floko May be you can try this module https://processwire.com/modules/process-file-manager/ https://processwire.com/modules/process-file-manager/ Gideon

The only field that is related to page url is the field "name", not "title" or custom field. It's located under "Parameters" tab. But you'll probably need to edit PHP code in template files, that depends on how the links are created.

This is a bit of a long shot given your description and the fact you don’t have access to the php files but maybe this has to do with URL Segments ? Head to Templates > Course (or whatever the template’s name is) and under the “URLs” tab have a look at “Which URL segments do you want to allow?” and add there the “contact-persons” segment on a new line (if “Allow URL segments?” is on, that is)

Hi @floko and welcome to the forum and processwire. From your other thread it sounds like you don't have access to the template files? So I'm wondering if you added your new field somewhere to the output in the template file? ProcessWire is very open in how anyone develops a website with it, but usually the template file is in /site/templates/[name-of-the-template].php There you should have something like <?php echo $page->c_element_text ?> otherwise only adding fields to templates does not output anything. If you don't have ftp access it might even be possible to modify templates with tracy debugger, see https://processwire.com/blog/posts/introducing-tracy-debugger/#template-editor-panel; But be very careful with that as changes might brake your website and are instantly live - so this should only be your last resort.

DaCha is a water sports center in Egypt and a hotel. https://surfdacha.com/en/ Multi-language. The backend implements the management of customer reservations and bookings. Naturally, the website is made on ProcessWire. UiKit 3 layout Modules: LoginRegisterPro, Cookie Management Banner, Map Marker, FrontendForms, Markup Sitemap XML, Video embed for YouTube (and Vimeo), Tracy Debugger. The backend implements the management of customer reservations and bookings.

Hi, Initial findings aren't positive unfortunately. In our application, whenever I try to generate a User Token I get an Error message on the Instagram popup. I got a colleague to create an application from scratch in a FB dev account not associated with our business one, and we also got the same error when trying to generate a token. There's a message in the App Review section indicating that reviews are delayed for Instagram apps due to volume, which suggests that they've recently made it necessary to submit for App Review and there are a lot of people scrambling to get this done. We're going to investigate further and see if we can find some more information about this, perhaps getting confirmation through developer support and/or the community help. If this is what is going on, this module will still work for 'Live' (reviewed) applications, but my understanding is that the process is a likely a lot of jumping through hoops, and completely overkill for what the application is trying to achieve. It isn't something we'd be attempting willingly! Cheers, Chris