bernhard

What did you use it for? Also I'd be curious what others have been wire shell for? The most important and helpful commands in RockShell have been pw:install and db:pull and both seem not to be part of wire shell. On the other hand I've never ever had the need to do something like field:create or template:create so I wonder why they are there? Maybe that's something that's only useful if you are not using RockMigrations?

Haha, turns out I only had to change one setting in RockShell to use colon instead of hyphen when loading the commands and it beautifully groups them into their namespaces ?

Thx for your screenshot! Looks like we should maybe change the syntax for commands from dash (db-pull) to colon (db:pull) to get the grouping?

I've just added a demo command that shows how one can add custom commands to their modules: https://github.com/baumrock/RockMigrations/commit/cce0d062d422a7e2b58815c61c5433eee0f65c71 It's also now possible to add commands to /site/assets/RockShell/Commands The idea was to build the foundation and make it super easy for others to contribute commands that we all need. I'm using it every day and alone the "db-pull" command is worth it. I've also updated the readme. Everything should be quite obvious now.

Definitely RockShell! It's super easy to use, works great with RockMigrations ("php rockshell db-pull" is all you need) and it is extremely easy to create custom commands: PS: If somebody wants to get personal support by me and in return help writing the docs let me know!

No problem, just tried to make sure we are talking about the same thing ? What do you find confusing/tedious? Maybe it's similar underlying things? If you do I'm happy to hear how it goes. I've not been using it for a long time as nobody ever showed some interest and for myself I've just gone the quick route and translate it in place. But that will hopefully change as soon as I release my new website ?

That would be good to know for RockMigrations so we could highlight all non-default values in the export code section ?

@psy I'm not sure what you are talking about ? The topic is about how to create and add translations to modules. If I understand you correctly you complain about the whole translation system in PW? My statement was solely about the process of getting translations into the modules folder ? I don't even have a problem with the translation via the PW backend, though I see that it could be nice to have a CSV file that you can send to a client and get back a translated file that you can then back import into the sytem. We have had that request once but then the client didn't want it. The problem with translating stuff in the backend is that you need to provide a login for that and need to make sure that all permissions are setup correctly and even then I heard from clients that this is "too complicated / I'm afraid, why does it not work like WordPress there I know how to do it". @teppo I already wrote what I don't like about the process. Imagine you have a module and you add one translatable string to that module. The steps necessary to push that translation into your modules folder are: Steps necessary when using RockLanguage and when RockLanguage is setup for your project (you have to do that only once per project): Once on the file translation screen, translate the text into the desired language and save git commit Now imagine you pushed your translation and then you add another word the other day... What would you have to do? I intentionally did not use the forums spoiler feature and I intentionally did not use "same as above" to indicate how much (unnecessary and repeated) work the current process puts on the developer. Imagine when using RockLanguage: translate the word git commit

Hey @gornycreative thx, looking good. But could you please give a little more context until I have time to look into it?

Hey @gornycreative thx for the question! This is something that I'd like to have but still haven't found time to implement. Maybe you could add a PR? I'm using wrapFields all the time and I'd love to have a setting to make it wrap fields in a tab ?

This has been an issue for a long time but should be fixed since 2022, see https://github.com/processwire/processwire-issues/issues/1154 and let us know more details if anything of the suggested fixes (or simply a core upgrade) works for you.

Do you include the uikit js file with the defer attribute? I think doing that can lead to a behaviour that you describe. So I'd try including the uikit js script in the head so it get's loaded before the content and that should hopefully avoid FOUC. That has of course the drawback that the site need longer to load. I can't say wether one way or the other is preferable but that's what I'd suggest to exactly identify the problem and then look for the best solution for your case.

That sounds like an interesting setup. I'd be very interested in a tutorial/showcase if you want and find the time ?

This is interesting. I thought it would be the other way round. Thought that ryan wrote that somewhere and also thought that as SessionHandlerDB is newer it has a reason that it has been built and would therefore be preferable over disk sessions. Do you have any more insights/references about your statement? Maybe I should switch ?

Hey @gornycreative thx for the question ? I've setup automatic version numbers (https://processwire.com/talk/topic/28235-how-to-get-fully-automated-releases-tags-changelog-and-version-numbers-for-your-module-or-processwire-project/) not only for all my modules but also for all my projects. Also I have a staging and production system for many of them and there it is nice to know with version of the project is currently deployed. Maybe staging is at 1.2.3 whereas live is still at 1.2.0 Does that make sense? Should I add an explanation somewhere or change wording to make it clearer?

Did a little more research on this ... https://susam.net/blog/timing-with-curl.htm The problem that I'm facing is that curl_multi_exec seems to completely mess up the timings mentioned in that post (and several others). As long as I do single curl requests the timings look reasonable and a page request takes around 200 to 300ms for a fast site and 900 for a slow one. With curl_multi_exec I get ranges from 4 to 10seconds from curl_getinfo($handle) ? So it looks like it's not so easy to create a little uptime monitor just with php + curl that works with more than a handful of urls.

Ryan has pushed a fix for this in the latest DEV that seems to solve the problem for me ? @Ivan Gretsky does it also work for you?

So I guess you are calling $page->save() somewhere in that endpoint, right? In that case you can just add whatever runtime property you want to that page and then use that as a flag in your hook: <?php // api endpoint ... $page->isFrontendSave = true; $page->save(); // hook, eg in init.php $wire->addHookAfter("Pages::saveReady", function($event) { $page = $event->arguments(0); if($page->isFrontendSave) { // do something } else { // do something else } });

There are many possible solutions and it depends how you implemented these forms and how you submit the data so it would be good to share some more details here ?

Hey @Greg Lumley great to hear that, thx ? There is a latte extension for VSCode. It's not perfect, but it's ok: Also there is no proper intellisense/code completion in latte files which is a pity, but I try to keep my latte files as clean as possible and put all the logic in the custom page class or in my Site.module.php so latte files are really just some simple markup and calling {$obj->method()} which is something that I can manage without typos most of the time ?

I don't like this statement either. ProcessWire is a timeless tool and does care a lot about long time support. That's something great! We should not blame anybody for not being on the latest and greatest versions. But we should make clear, that this is not the recommendation and it's everybody's own decision and risk. Like having some food where the expiry date is over. It's perfectly fine if you are alone and you smell it and decide to eat it. But it's a different story if you sell food to others!

PHP says something different https://www.php.net/manual/en/security.current.php and this blog post https://kinsta.com/blog/php-versions/ lists some good reasons for staying up to date. So in general I think it's a good idea to stay up to date. Note that my intention is not to blame anyone not updating his/her setups or modules. I'm still running some sites on PHP7.4 because that are low budget sites or sites for friends or personal projects. There are reasons why it can be better to stay on an old version, but there are also many good reasons to keep up to date. For example better performance and better security. Personally the php-supported-versions page has helped me to communicate to my clients that some kind of maintenance is important for every project. Some clients have the expectation that developing software means pay once and then it works forever without any additional costs. And we all know that this is not true. And even though PW is a lot better than other systems (which I find great) I think that we as web professionals have to educate our clients to continuously invest something into the assets that we made for them. I'm not talking about WP Update Hell but doing maintenance every 2 or 3 years should really not be too much for a professional website. And it also makes sense from a business perspective for ourselves! It's like having a car and doing regular maintenance and changing oil etc. before the engine takes damage. Also it's better to take smaller steps (PHP5 --> 7 --> 8 --> 9 than waiting for a long time until you hit a "relaunch or die" situation). Personally I'm not recommending to my clients to update to the latest & hottest sh* all the time, because being an early adopter usually comes with additional costs. But I'm trying to keep them up to date with officially supported versions. And I try to use newer PHP versions on my own projects so that I can report issues that I find. That way we can continuously fix those issues when they come up and before they get critical (meaning fixing warnings rather than bugs/errors). And I think it would be good if ProcessWire showed commitment for that and communicated that in clear and understandable way so that everybody interested sees the benefits and the reasons behind the strategy. And so that everybody sees ProcessWire as what it is: A serious and professional tool that you can trust and that is actively developed. "PW needs PHP5.4+ but we recommend PHP7+" clearly does not do that in my opinion. When PW was mentioned on other platforms I read comments like "latest commit 2 years ago - that project is dead" or similar. Just because they didn't realise there is a dev branch. That shows the same problem from a different angle in my opinion. And it shows that having minor releases like PW3.1 or 3.2 can be a good thing. And the solution (and intention) is not to push devs into a version number race but to have a strategy and communicate that clearly. So that everybody knows what to expect and so that we have less assumptions (which is clearly the case as this discussion shows). Have a great weekend ?

Thx for your input so far! I'd definitely not thought of many of these points ?

Great to hear that, thx for sharing! I'm quite surprised, but that's a nice example that it makes sense to keep it alive besides findRaw ?

I think there are pros and cons and I think @wbmnfktr has made a good suggestion in bringing up the topic. While writing that post I've had to lookup the requirements page. This is what it says: I imagine if I didn't know anything about ProcessWire and someone gave me the link to the PW website and this was the first thing I saw I'd turn around and run. Actually that was what happened in 2013 but gebeer was patient and kind enough to make me have a second look. PHP7+ recommended? How can a system that I should build my business on and that markets itself as security as top priority recommend a PHP version that has been end of life for more than half a year now: https://www.php.net/supported-versions.php ? And it's not like PHP8 is totally new... We have it since 2021 and PHP8.1 since 2022 So while I'm a huge fan of ProcessWire being a timeless tool that can run untouched for years without updating either PHP or PW I'm also really liking the idea of having a clear cut and maybe even bumping the version with that cut to PW3.1; Maybe it should just be communicated in another way! When looking at the requirements page nobody knows that it's a timeless tool and that this is besides security one of the top priorities. Also... PW3.0.220... That's such a weird version number that I've never seen in any other library. In my ProcessWire lovestory I mentioned that and I framed it as "not a single breaking change for 220 weeks" and that's not a lie I guess, but my feeling says that moving forward to PW3.1 with minimum required PHP8.1 would be a good thing. If anybody didn't like that he/she could just use PW3.0.222, no? Also more feelings than facts ?