bernhard

I'm using https://intelephense.com/ and paid for it as it is so useful, but the free version is great as well!

These things are so easy to do with RockMigrations: <?php // site/migrate.php $defaults = [ 'type' => 'image', 'maxFiles' => 1, 'descriptionRows' => 1, 'extensions' => 'jpg jpeg gif png svg', 'maxSize' => 3, // max 3 megapixels 'icon' => 'picture-o', 'gridMode' => 'grid', // grid, left, list ]; $rm->createField('your_image_field1', $defaults); $rm->createField('your_image_field2', $defaults); $rm->createField('your_image_field3', $defaults); You can then set custom labels for your fields or you can even set custom properties either in migrate.php overriding the defaults or via GUI as template context override. PS: If the fields already exist you CAN use ->setFieldData() instead, but ->createField() will work as well. PPS: If you need to change a setting just change the setting in the defaults, save the file and refresh your web broser!

#0 C:\wamp64\www\oh1\site\templates\home.php(18): RockPageBuilder->render() This tells me (and you) that you are not using $rockpagebuilder->render() but RockPageBuilder->render() ? $rockpagebuilder is the RockPageBuilder API variable, "RockPageBuilder" is just a string. The error tells you that you are trying to call the render() method on a string. Use $rockpagebuilder->render() instead.

RockAdminTweaks v1.9.3: Some bugs where fixed thx to @adrian

RockShell v3.2.0: Some minor fixes and improvements to existing commands

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']));

RockFrontend v3.19.0 addLiveReload has been made hookable, that means you can now fire custom actions whenever you save a file! I'm using this to run the tailwind compiler. See the docs here. Some fixes related to livereload and the topbar have been added. We added a new method addPageEditWrapper() that makes it possible to add any custom markup to your ProcessWire backend page editor. I'm using it to place two fields side by side via flexbox instead of using the limited columnWidth layout options. It's part of RockFrontend because I need the latte rendering capabilities and so I didn't want to put it into another module like RockMigrations and add a dependency.

Client quote: We just want a simple event calendar. Simple, right? We just add a DateTime field! Not really... One DateTime field is not enough, as we might have a date range, like summer holidays. Ok, so we add a second DateTime field? Ok, but what if we want a single full-day event, like one single holiday? And how would we easily query all events that are "active" in one month? The module is a commercial module and can be downloaded here: https://www.baumrock.com/releases/rockdaterangepicker/ Docs: https://www.baumrock.com/en/processwire/modules/rockdaterangepicker/docs/ Note: There's also a Pro Module by Ryan, which you find here: https://processwire.com/blog/posts/date-range-fields/ - For my use case this module was unfortunately not usable, because the daterange picker that Ryan chose does not support time inputs. As this was a no-go for me and I found the library www.daterangepicker.com which does exactly what I need, I went ahead and built that module. PS: When using AdminStyleRock it automatically applies the primary colour to match your admin style 😎

I'm not totally against that. I'm using semver for all my modules as well. But it also has downsides: Complexity: SemVer can be complex to implement correctly, especially for large projects with many dependencies. Subjective interpretation: Determining what constitutes a "breaking change" can be subjective, leading to inconsistent version bumps. Rapid major version increases: Frequent breaking changes can lead to quickly incrementing major versions, potentially causing version number inflation. Dependency hell: In ecosystems with many interdependent packages, strict adherence to SemVer can still lead to compatibility issues. Limited expressiveness: SemVer doesn't capture all types of changes, such as performance improvements or security fixes. User expectations: Users may expect significant new features with every version increment, which isn't always the case. Backward compatibility pressure: Developers may avoid making necessary breaking changes to prevent major version bumps. Learning curve: New team members or contributors may need time to understand and correctly apply SemVer principles. I've experienced some of them on my own. Personally I can't remember of a single situation where upgrading PW was a big problem. Maybe I had some minor issues, but I can't even remember a single one. Everything that is pushed to the core is listed in the commit log, so you can easily have a look there and check if upgrading is a problem for your specific instance or not. I think that's our responsibility as developers. I understand that it's tempting to go with SemVer, but I'm quite sure that once we have it there will be people complaining that they did an upgrade from PW 4.xx to 4.yy and there was something wrong... For the upgrade from 2.x to 3.x Ryan even added an upgrade guide: https://processwire.com/docs/start/install/upgrade/from-2.x/ So I'm not sure if your suggested switch to SemVer would improve things a lot, at least I don't understand it from what you wrote. Not saying that release cycles like in my ubuntu screenshot above would solve all problems, but I like the strong message that it sends out and I don't see such a message in PW 4.x, 4.y, 4.z ? Having regular releases could imho help in keeping focus. We (Ryan) could for example state that for the next LTS release the focus lies on improving the admin theme. In the next LTS the focus could lie on building a module ecosystem. In the next LTS ... you get it. Not sure if mixing LTS versions with stuff that is not code but project-related would be a good idea, but I wanted to throw in that idea. Maybe it would help to split the roadmap/ideas/requests into two parts, one for PW itself and one for the project/community around it.

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 ?

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

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.

Hi @Stefanowitsch What I did is to add a hook at Pages::saved which will save the content of the RPB field to a hidden field which then can be queried via regular selectors. Each block had a dedicated method createIndex() which was called in a loop: $blocks = $page->getFormatted(RockPageBuilder::field_blocks); $index = ''; foreach($blocks as $block) $index .= $block->createIndex(); $page->setAndSave('your_search_index_field', $index); The benefit here is that you can define custom markup for each block, for example a headline block could just return this for a search index: public function createIndex() { return "** {$this->title} **\n"; } Does that help?

@double thx for sharing! Have you seen ?

@ryan thank you for your reply on my last post. I have to think about everything that has been said, but I have to mention here that this might not be trivial for someone new to OOP where everything that he/she wants to do is add a hook this will only work if you have at least one instance of that pageclass loaded. So if there is no page loaded (or no page exists) yet with that template then hooks will not be added and therefore some important features might not work and you'll get unexpected results. I understand what you said about why you don't want to have them in the pageclass itself, but I still think PW could make it easier to guide/support the user (that might be totally new to OOP) in how or where to attach hooks that are "related to" (whatever that means) the pageclass. Similar to what we have with /site/ready.php and /site/init.php, which is really trivial. ? @FireWire fully agree!

Hey @ryan first of all let me thank you for ProcessWire in general and for all the work you put into it! Also thank you for mentioning me and my modules. Unfortunately I can second what @jploch said, that it's very hard to offer commercial modules in PW, but that's a topic for another post as this one has gotten very long already ? NOTE: Sorry, this post got very long, but I think it covers some important concepts and I think some of the concepts can really push PW forward on the web-application front. I think it's important to understand the details, so I ask you kindly to read carefully and try to understand the bigger picture ? In this post I'd ask for clarification about what you said about custom page classes attaching their own hooks: I think the phrase "everything necessary" might be worth considering here. A class ideally just has one responsibility. Page instances are there to provide an interface to one page's content and be swapped in and out of memory on demand. When there are things like hooks going into a Page, that changes the role completely. If you start doing this a lot on a large site then it may affect scalability. Maybe it's fine for one individual installation or another, however. I didn't want to believe that, because everything that I've built over the last few years relies heavily on the concept of "MagicPages" which is a feature of RockMigrations and which basically turns every custom page class into an autoload module where you can add hooks that are related to that pageclass. This concept makes maintainability of the whole project a lot easier imho. Before I invented that concept I had quite complex applications and they had hundreds of lines of code in /site/ready.php or /site/init.php; ---------- first some background, later the tests ------------------ ---------- the tests ------------------ ---------------- Very, very long story short: @ryan I'd appreciate if you could explain in more detail why you think it is bad to put - what I'd call - pageclass-related code into pageclasses? Also I'd like to invite you to re-think if it is really bad to have things like "getPageListLabel" in the pageclass. I think this is a great to have these methods and I really enjoy having "editForm($form)" as a shortcut for ProcessPageEdit::buildForm if($page->template == ...) and so on. At the very minimum I'd love to have an init() and a ready() method where we can add hooks as we need them. Thank you very much for reading. I'm sorry for the length, but I hope there was maybe something interesting in it. Please let me know if I did anything wrong with my tests or what I could do better. Thx. Long live ProcessWire ?

Thx, I hope you enjoy it! Looks good. I'm always using an autoload module for every project called /site/modules/Site/Site.module.php and put all the global things there. So there I'd have a migrate() method with something like this: <?php public function migrate() { $rm = rockmigrations(); $rm->createTemplate('doo'); } And then all the migrations that are related to the "doo" template go into the DooPage.php pageclass. Creating the fields can either go in Site.modul.php or in DooPage.php - it depends. If I want to reuse these fields I put them in Site.module.php - if they are solely for DooPage I put them in DooPage.php In the module settings you have a checkbox to copy snippets over to /your/project/.vscode and that should make VSCode recognise the snippets and show suggestions once you type "rmf-" etc

Anybody using RockMigrations for automated deployments please check out v5.0.1 which changes the names of the release folders from "release-[deploy-id]-[commit-sha]" to "release-YYYYmmddHHiiss-[commit-sha]" The reason for this change is that yesterday suddenly my deployments broke and it turned out that the deploy-id made a jump from 999... to 100... which broke the logic that was used for renaming all release folders after each deployment. This should not happen any more now that we are using timestamps which are maybe more helpful anyhow. I don't think so but in case it does not work with the new version remove all old release folders and then deploy again.

Please check out the new version on the dev branch which will be merged begin of next month: // site/ready.php wire()->addHookAfter("RockFrontend::addLiveReload", function ($event) { // if the current user is a guest user we override the // original return value and set it to false // which will tell RF to not add livereload markup if(wire()->user->isGuest()) $event->return = false; });

What do you mean? For a guest user on development? On a live site you should never ever enable Livereload.

Ok glad it was helpful. I never know the level of the users so it's sometimes hard do find the right amount of information ? Looks like you are just missing the |noescape filter. Use it with caution, see https://latte.nette.org/en/tags#toc-escaping-output The reason why you don't need it always is that many times RockFrontend/RockPageBuilder will return HTML objects so that Latte knows not to escape the output. If you return some html code as regular string then latte doesn't know anything and will encode entities for preventing some vulnerabilities.

I just had a look at your example and answered the question about the latte syntax. I didn't think about what you are actually doing. The error message means that you provided an invalid selector, which is obvious in your case as you are - as I said - in PHP land inside the brackets. That means inside the brackets the $block->rpb_left will likely be a RockPageBuilder\FieldData object (similar to a PageArray). You can't to a $pages->get( FieldData ) and that's what it complains about I guess. What you are doing with " ... " is to typecast it to a string value and that makes it return the page ID if you have a single block in that field. If you had multiple blocks added to that field it would do something like $pages->get("1010|1011|1012") which would also cause an error! It's really nothing related to RockPageBuilder or Latte, it's just basic PW API usage. Didn't understand you where having problems with this, sorry. But glad you got it sorted.

Once you are in a tag you don't need any brackets any more. Basically inside the bracket its regular php: {$pages->get($block->rpb_left)->text()}

Hi @sebibu thx for the great feedback ? Technically you can achieve that by creating a new block called "layout". Then you create two new RPB fields, eg column_left and column_right. Then you can add blocks to those fields, for example add "headline", "text" and "image" blocks to the column_left field. Then you can go to column_right and click add new block and click reuse existing block for all of your blocks. For the frontend you have to create the markup of your layout in the "layout" block's template file (eg layout.latte or layout.view.php). The problem with such setups is that it get's more complicated and you are moving the sweet spot between easy of use and features more towards features at the cost of more complicated content editing. On the backend RPB will show a button for nested RPB fields to edit those fields in a modal (or panel I think). So editors have to save the base page first, then can edit nested content. On the frontend this should be less of an issue. You can try and report back what you find. Also @Stefanowitsch might have useful tips as he built a quite complex page using RockPageBuilder recently and I think he is going to share something soon?! ?

Yes, quite easy ? $wire->addHookAfter( 'ProcessPageEdit::buildForm', function (HookEvent $event) { $form = $event->return; $page = $event->process->getPage(); // if page is young enough don't lock the page name field $lockPagenameAfterSeconds = 60; if ($page->created > time() - $lockPagenameAfterSeconds) return; // get field and set status to collapsed + locked $field = $form->get('_pw_page_name'); $field->collapsed = Inputfield::collapsedLocked; $field->notes = 'Can not be changed any more'; } ); Alternatively you could use $page->meta() to set a flag at some point instead of waiting 60s.