Leaderboard

We’ve been building web site with ProcessWire since 2013. ProcessWire serves to us as a secure, reliable platform, and honestly, I don’t remember any significant issue after 11 years of daily use (for us, PW is also a CRM). The magic of ProcessWire is that it is always growing with our needs and serves any unimaginable demand that our platform has had. All these years, our business has grown around ProcessWire, and as it usually happens, popularity brings the other side of the coin. In our case, it was online fraud and scammers. Our first approach was to use existing fraud prevention systems, but as our business is not pure e-commerce and fraud was indirect, there was no solution that matched our needs, so we started developing our system from scratch. This is where I exactly understood how ProcessWire and the community really hooked me. (-: First of all, taking ProcessWire as an example, we decided not to heavily rely on frameworks. It was a hard decision, because new school engineers like to bring as many dependencies as possible, but I continuously pointed to ProcessWire, and as a result, we created a fraud prevention/user behaviour analytics platform with ~4 PHP dependencies. The second decision that we took, looking at ProcessWire, was even harder than the first. The fraud prevention market, in contrast with CRM, is not widely targeted for open source software, but taking ProcessWire as an example, we decided to open source our system after ~8,000 engineer-hours under the AGPL license. For sure, after being open-sourced for one week, it's premature to give any feedback, and it is highly possible that open sourcing was a mistake. However, it brings me to the understanding that the real measure of software is not downloads or stars, but its influence over other developers, and from them onto other developers, like ripples on the water. From this perspective, I am infinitely grateful to @ryan, @Ivan Gretsky, @Soma, and every person behind the ProcessWire community for all the inspiration through these years. I'm so grateful that 11 years ago I met this community and had the chance to work with some of you. As I'm more reader than writer, I would like to use this rare opportunity to wish the ProcessWire community and your families a Merry Christmas and all the best in the New Year! Best Alex P.S. While this post is not intended to be an advertisement, if someone from community is facing challenges related to online fraud, user spam, or security, please feel free to contact me directly.

Solution is here: https://processwire.com/modules/search-engine/ // Alternatively index just a single page (passing in a Page object): $modules->get('SearchEngine')->indexPage($page);

Happy to hear you found the issue. 😀 You could consider indexing the pages with a Lazy Cron or a cronjob.

You are indexing all the site pages every time a page is saved. You should index only this page since the work for other ones was already done.

Thank you very much for your advice! I have indeed found a hook that was apparently to blame. I can't remember exactly why I added it and what it does ... $wire->addHookAfter('Pages::saveReady', function($event) { $event->modules->get('SearchEngine')->indexPages(); $page = $event->arguments(0); $event->wire('log')->save('Page saved', "Page ID: $page->id / Page Name: $page->name / Page Parents: $page->parents"); });

Hey experts, I had this cool idea I would love to implement, but so far I didn't manage to do it with good enough performance. I've got some date fields on a page, and I'd like to have years indicate on the pagination pages, like so: What I tried is to read all the results, read all the years for each results, then slice them up in pages. This is way to slow, obviously. Only thing i could think of is to make a nightly batch job that calculates the pagination, but it starts to get a bit messy and could easily be out of sync. This is no life-and-death situation, it's just something I would like to do. If you have any ideas how to solve this I'm curious to hear it.

I've been working to improve the deployments feature. As a result I changed a small detail in v6.3.0 that might break your deployment pipeline. If you are seeing this error: You can either update RockMigrations or, if that is not possible, make your workflow use the old version of the deployment:

Hello @tires, have you tried looking in TracyDebugger if there is an error? Do you use hooks or special modules? The amount of subpages should not be an issue in my experience. Maybe there is something else going on. Regards, Andreas

@bernhard I am seeing some odd behavior and I think it's because I'm an American 🤣 When I add a new event on the calendar the date that I click is showing up on the event page has the month/day in the incorrect order (at least for us over here). This is the event date field value that I get if I click on December 9th, 2024 on the calendar inputfield. We write our dates incorrectly over here with mm/dd/yyyy. If I try to create an event on today's date (or any day greater than 12) then it renders NaN values since 16 isn't a valid month. I tried to double check that the locale was set correctly in case that was related, here's how that is configured. Also noticed that there's no option for en-us, I tried entering that manually but didn't see a difference. So I haven't had any luck with either en-gb or en-us. I can confirm that after creating the event and saving it with the incorrect date, I can go back and edit the date and it will save correctly in the right format. I created this one and it saved as October 12. I edited to December 10 and is saves/renders correctly. Let me know if there's anything I should do on my side to help fix. Humble request for en-us haha. Thanks as always 👍

Hello @benbyf, yes I include the wire folder in my repo. I am no Git expert but looked how .gitignore files for other CMS are recommended here in this popular collection on GitHub: https://github.com/github/gitignore Most other CMS like WordPress, TYPO3, Joomla!, Kirby etc. recommend to add Git in the root folder and track the core folders. For WordPress now it is recommended to optionally ignore the core folders, but at the time I was looking that wasn't the case. Here are my pros and cons for adding Git in the root folder: Pros One repo for the complete website You can clone the complete website with one command Sometimes there are important files in the root, like f.e. Service Workers or Composer packages You know which version of the CMS is used You can use new functions of the CMS without keeping track of the CMS version somewhere else If someone modifies or hacks your wire folder, you could see the differences Cons More commits Larger repo But ProcessWire gets a master version only once or twice a year, so the cons are for me not noticeable. Of course as I said I am no Git expert and everybody is free to use Git how they want. 😀 Regards, Andreas

I use Git in the project root as well, and only put things in .gitignore I really don't want to have in that repo. Best case scenario is that I have the full project, besides database dumps, in my repo. # .gitignore .ddev/ site/assets/backups/ site/assets/cache/ site/assets/logs/ site/assets/ProCache-* site/assets/pwpc/ site/assets/sessions/ site/config-dev.php Database dumps are a thing of its own. Managed projects are backed up quite often, long time projects with not that many updates will be backed up once every 3 months. From un-Managed projects I keep only the latest version I worked on - most of the time the release day or when something was updated.

I add Git in the root folder and can recommend GitKraken as app. 😀 I have a develop and a master branch and an origin remote. Our remote repositories are hosted on Bitbucket. This is my current .gitignore file: Regards, Andreas