bernhard

Everything working as expected now, thx @ryan ?

Turns out it is not an issue with my modules... I've installed a fresh installation of the latest PW. I have even done that manually to make sure it has nothing to do with the installation process of RockShell. When I try to edit the "Home" page and rename the title from "Home" to "Home2" the page saves but the change is not saved: This is my config - maybe it makes a difference which settings to use on install? <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); /** @var Config $config */ /*** SITE CONFIG *************************************************************************/ $config->useFunctionsAPI = true; $config->usePageClasses = true; $config->useMarkupRegions = true; $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; $config->templateCompile = false; /*** INSTALLER CONFIG ********************************************************************/ $config->dbHost = 'db'; $config->dbName = 'db'; $config->dbUser = 'db'; $config->dbPass = 'db'; $config->dbPort = '3306'; $config->dbCharset = 'utf8mb4'; $config->dbEngine = 'InnoDB'; $config->userAuthSalt = 'xxx'; $config->tableSalt = 'xxx'; $config->chmodDir = '0755'; // permission for directories created by ProcessWire $config->chmodFile = '0644'; // permission for files created by ProcessWire $config->timezone = 'UTC'; $config->defaultAdminTheme = 'AdminThemeUikit'; $config->installed = 1662291609; $config->httpHosts = array('dev-save-issue.ddev.site'); $config->debug = true;

And exactly that was my suggestion: Ask Ryan not to make something hard-coded or opinionated like a toggle to either strip all <!--# comments --> or to leave all <!--# comments --> as is, but ask him to make that definable by the user, so that he/she can for example tell markupregions to leave all comments that start with " ko " as is, so that knockout comments stay untouched and all other comments still get removed. That way you would not have to rewrite your codebase and you can use markupregions with any external tool that relies on a custom comments format.

I'm also having troubles with my RockMatrix module that worked great until the last commit and now stopped saving any content. I'm investigating...

My suggestion was a suggestion for that feature request, not a workaround ?

I totally agree ? Another suggestion could be to add a textarea to define custom comment tags that should not get removed, or maybe a regex or such, eg <!-- ko (having a space after ko)

Thx for the links ? I remember I've also started with both and they were a great help! I just realised that it seems we have no list of all available hooks online somewhere? I'm always looking that up in my IDE (or tracy), but for newcomers such a list (as captain hook) is for sure interesting.

Ryan was quick with this one ? It's now easy and bullet proof: <?php $img = $page->get('images.first'); if($img) echo "<img src={$img->size(200,200)->url} alt=...>"; https://processwire.com/talk/topic/27528-weekly-update-– 2-september-2022/#comment-226391

Just for reference Ryan was very quick on this one and we now have this selector to force return the array value of an image field: $page->get('image[]')

Maybe you can trick it by using this? <!--# <!-- ko if: properties.ms == "pro" -->

No idea what's going on. But if you get an error 500 go and inspect your webservers error logs or the ProcessWire logs (in /site/assets/logs) and see if you find some helpful information there.

With document.ready I was referring to the javascript event that is fired when the DOM is ready. See here: https://stackoverflow.com/a/9899701/6370411 That has nothing to do with the server side ready.php file ? That's quite easy to do: <script> let infoShown = localStorage.getItem('medicalPopup'); if(!infoShown) { UIkit.modal(...).show(); localStorage.setItem('medicalPopup', 1); } </script>

Your examples are confusing. Your first snippet shows UIkit.modal().show() just before </body> and the second shows that you are loading the script just before </body>. So which one is true? The loading order is important, so if you do that: <script src="uikit.min.js"></script> <script>console.log(UIkit)</script> You should get a proper log in the devtools of your browser, but if you do that: <script>console.log(UIkit)</script> <script src="uikit.min.js"></script> You'll get "undefined" for your UIkit variable. So if you did UIkit.modal(...).show() in the second example you'd get the error that you described. What you can also do is to wrap your javascript in a document.ready callback: <script> document.addEventListener("DOMContentLoaded", function(event) { console.log(UIkit); }); </script>

I guess they are not, because that's what the error says ? How/where/when do you load UIkit?

I have created an alias command to get the same settings for all my projects ? alias ddc='ddev config --php-version "8.1" --database "mysql:8.0" --webserver-type "apache-fpm"' So for me its this: ddc --> setup a new ddev project git init --> initialise a new git repo git clone git@github.com:baumrock/RockShell.git cd RockShell php rockshell pw-install I should maybe create an alias for that too ?

Could any of the moderators please unpin this thread and also the captain hook one? The links are all 404 and I don't think that those projects still exist? At least I have not used them for years...

Hey @MarkE thx for your message! I'll answer in detail soon. Could you please describe exactly what you mean here? Best with a specific example from the very beginning until the very end. For someone that is not really familiar with your module please ? What do you do in code, what do you do in the GUI? Where? When? Why?... Thx

Something like this (from the docs)? <edit field="events" page="1001"> ... </edit> PS: ALFRED can help with FrontendEditing: https://www.youtube.com/watch?v=7CoIj--u4ps&t=1714s PPS: I don't really get the problem... Shouldn't it just be something like this? foreach($page->children() as $child) { echo $child->edit('body'); }

Sure, if you only need to store data and don't want (need) the overhead of creating fields you can just use json. Have a look at https://processwire.com/api/ref/page/meta/

I think that pages are a fundamental concept of pw and many things are built around that concept. If you think that storing data in pages is not a good idea, then you'll likely end up in a situation where you can not use some of the great tools that you can use when being aligned with pw concepts... That does not mean that one way is better or worse than the other. It always depends on the situation. But there are not many things in pw that are more fundamental than pages ? Imagine you want to add notifications whenever an entry changes. Using pages: $wire->addHookAfter("Pages::saved", function($event) { // send mail }); Using custom storage solution: No idea - I know why I'm using ProcessWire ?

As I've never had that need could you give some examples where you missed that feature? What could one build when having it? How would the workflows be then and how would they be now... Just to get an idea ?

I don't think so... Maybe I'm misunderstanding your message, but it looks like you are mixing things up. I'm not talking about using $this to refer to the current page inside the dedicated hook method. Of course, that would not work. Because in the hook method, as you have said, the context is different. And there you get the page by using $event->arguments(0) or similar. That's what I explained in the video and I never said something different. I'm just using $this in the init, because then I can be sure that I'm in the correct context. $this in init is the custom page class (or the page object), and I request the wire property of the page, which is always an instance of the current processwire instance. And then I call addHookAfter() No mixing things up. Inside the dedicated hook method (like "resetCache" in the example above) we are of course in the hook context. So $this would NOT be the current page there. But I don't see a problem here and I don't get your point?!

Those custom hook methods need to be public. It's not about pretending something. It's about keeping the code as easy to understand and therefore as easy to maintain as possible. If you put everything into a callback than it can be quite tempting to add a little bit extra code here and there, that actually does something different. Just because you want to do some additional logic and you think: "Well, I already have the hook in place... Let's add another line of code there". For example to change the "bar" property on page save. If you already have a dedicated method like "updateFooOnSave()" then it's much more unlikely that you add your BAR change there. Or at least you get reminded that it might not be the best idea... Hope that makes sense. Another thing you can do is to share the same logic and apply it to different hooks: <?php public funtion init() { $this->addHookAfter("Modules::refresh", $this, "resetCache"); $this->addHookAfter("Pages::saved", $this, "resetCache"); } public function resetCache() { // reset cache of whatever } We can do the same on newer versions of PW by attaching multiple hooks in one line, but I usually find it cleaner to be a little more verbose.

I'm using custom page classes a lot like modules. It's all about making things reusable to get more productive and to be able to increase quality step by step and not re-inventing the wheel from project to project...

Didn't think of using wire() - that would work. At least until you are using Multi-Instance. Or someone else uses it that uses your code ? And you still have to define the hooks as callbacks, which I don't like because of the reasons mentioned above.