snck

Hey @Mike Rockett, thanks for this module! ? I was wondering whether it's already possible to exclude certain languages, e.g. using a hook. I have a website that has a few languages installed, but one language is used only for internal stuff and the pages should not be accessed from the outside. What can I do to prevent MarkupSitemap from outputting links to page versions using one specific language completely (even if the language version is "active" on many pages)?

Thanks for the input, @ngrmm! After further investigation, it became apparent that the editor who was experiencing the problem always accessed the backend of the website via a bookmark that referred to a URL with a www subdomain. Since the www subdomain is not set up as a host in config.php, the "View" link always points to the domain without www. Presumably the session cookies were running on the subdomain, which were not classified as "same site" by the browser and/or cookie policy, which may have led to the 404 error. For me, this has now been resolved. I was at least able to solve the problem for the editor by using a rewrite rule that redirects all traffic for the www subdomain to the main domain. Since then, the strange behavior has no longer occurred.

I have a strange problem with a site that I was not able to solve until now. I have a website running on domain.com (which is also the only entry in the hosts array). If an editor (or me as superuser, but for me this is happening only sporadically) is logged in (also using domain.com/processwire/), they cannot access an unpublished page using the "view" link, but get a 404 error page. If the previewed url is changed from domain.com/xyz/page/ to www.domain.com/xyz/page/ manually in the address bar, the page is viewed correctly. There is no .htaccess rule for www redirects in place and I have disabled ProCache for debugging purposes. What makes it even more bizarre: Sometimes if the user logged out and is logging in again, they get redirected to the page they wanted to view directly after submitting the login form. Has somebody experienced a behaviour like this before? As I am not able to reliably reproduce this behaviour, I feel a little lost. At first I was thinking that this problem is related to some network configuration/filter/firewall stuff on the client's network, but as I was also facing it a few times, I am really confused. Is there any configuration on the webhost side that could cause issues like this? Any input is appreciated! Thanks, Flo

@Juergen After testing with a colleague we found some points that could probably be addressed: Translations: German translation shows "VERöFFENTLICHT" (instead of "VERÖFFENTLICHT"). Maybe it could just be "veröffentlicht" (no CAPS, but bold)? If you have set a publish date (in the past) and save a page as unpublished, you get a warning, that the page will be published on the next run of the cronjob (same for unpublish date...), which is fine. We were asking ourselves, whether the method that is triggered by the cronjob should also run on page save (for pages that have values in the module's fields). This way the warning could be changed to something like "you have set a publishing date in the past, the page can only be unpublished, if you clear the field...". We think that (although the message that is shown is clear about the effects) it is not the best possible experience that a change has an effect, but only for a short time and changes back automatically after that. Warnings might not be read everytime. Page tree: If a page is published (because of a publish date in the past) and gets unpublished directly in the page tree, the warning mentioned above is not shown (because it is an ajax request) and the user will not notice, that the page will be published again soon (only if he reloads the page tree manually). I do not know, what the most elegant solution is, but I think, hooking $pages->[un]publishReady() and "stopping" the (un)publish action if it is against the settings in the module fields (and outputting a warning that explains the reasons) would be a solution that also solves the problem mentioned above. As I said, the improvements are huge already. These are no necessary changes, but suggestions on how the module could become even better. ?

@Juergen Thank you! ? We are still testing it, but it's looking good! A massive improvement over the previous versions. ?

@bernhard You are completely right! ?‍♂️ We can consider that solved, I guess. Thank you!

Hey @Juergen, thank you! That was so quick that I am not sure whether I can test and implement it before you release the next version. ? Visually it looks great to me! ? But I think, the method should be "smart" and also check whether the module has "fired" yet or if it will in the future (which should not be to hard as it is just a date comparison). I think the big value in highlighting pages in the page tree is in reminding the user that there WILL be a change to this page. The user should not be bothered by pages that already have been (un)published by the module and there could be a lot of those. You could even include a tooltip that gives detailed information on the (un)publication of the page if the user hovers over the clock icon like "Will be (un)published on XX.XX.XXXX – XX:XX:XX". I really love how quick you implement feedback. Thank you again! ?

@Juergen No worries! I am looking forward to it and happy to test, when it's ready. ?

And I just had another idea ?: Pages that will be changed by the module in the future could also be marked in the page tree, e.g. prefixed with a "clock" icon.

Great news! ?You could even attach a hook on page save that triggers a warning if a published page is unpublished manually, but will be published by the module again in the future (could work analog for an unpublished page that is published manually, but will be unpublished because of a "publish_until" date in the future).

I would disagree on that. If you only want to schedule publication of some of your pages, you would not expect anything to appear in these fields on pages that have been published manually. In contrary I think it is misleading this way, because it looks like the publication had been scheduled, although it was not. I think it is much clearer if the fields give a clear indication of the user's intention: Blank = nothing happens Filled = publish/unpublish at this date/time Imho the page status is handled by PW and editors should be aware that they can publish and unpublish pages manually. Your module is a great addition, but in my eyes it should enhance the core functionality by offering a way to schedule publishing/unpublishing without forcing additional actions or altering page data. Maybe it would be a nice addition to show a status in the fields that informs the user about the effect of the module like that (in an InputfieldMarkup or as description of the fieldset): Page is currently PUBLISHED, no settings have been applied Page is currently UNPUBLISHED, will be published on XX.XX.XXXX – XX:XX:XX Page is currently PUBLISHED, will be unpublished on XX.XX.XXXX – XX:XX:XX You could even make it really fancy and include a countdown or something like that. This is of course just a quick thought and I do not want to "order" new features. I just wanted to address the user experience aspect and make a suggestion how it could be improved.

I have a strange issue with a page's modified property. I am using the following code to get the timestamp of the last modified page's last modification: $selector = 'parent.template=artworks, template=artwork, pj_kub_published=1, pj_kub_images.count>0, include=all'; $last_modified = strtotime($pages->getRaw($selector.", sort=-modified", "modified")); pj_kub_published is a checkbox. It is used to determine whether a page should be visible or not. When the checkbox is changed on a page and the page is saved, I expect $last_modified to represent the modification timestamp of the page with the latest edit (timestamp of page save). This works if I check the checkbox (pj_kub_published=1) and save the page: $last_modified = 1714047595 But if I uncheck the checkbox and save the page, the timestamp in $last_modified becomes some time in the past: $last_modified = 1714030794 The date/tim shown in the settings of the page edit dialogue is accurate though. This is really annoying because I am caching some output in files and use this timestamp to determine whether the cache should be renewed. I have found no explanation for this behaviour. Already tried diabling $config->dbCache without success. Without the selector the result is as expected and changes on every page save: $last_modified = $pages->getRaw("sort=-modified", "modified"); Is there anything I am missing here or any other way to get an (accurate) timestamp of the last modification of certain pages using the api? Is there some kind of query caching involved?

Why would it? The page status is handled by PW. Why would your module need to change values if I publish a page manually?

@Juergen, thanks for your quick reaction and taking care of the issue! I would appreciate a solution that does not populate dates automatically (e.g. setting a "from" date not for unpublished, but only for published pages). In my opinion the module should only read and interpret these values.

Hi @Juergen, unfortunately I have a problem again or maybe I am just really confused on how the module should work or might have worked in my case before. I have JkPublishPages enabled for one template only. This is an article page (news_article). Editors should be able to schedule publication of articles by selecting a date and saving (as unpublished). I would expect that JkPublishPages works in the following way: If no date (jk_publish_from or jk_publish_until) is given, the page status stays completely untouched (unpublished in my case) If jk_publish_from is given, JkPublishPages changes the page status to published on the first execution of LazyCron (after the selected date) If jk_publish_until is given, JkPublishPages changes the page status to unpublished on the first execution of LazyCron (after the selected date) Please correct me, if this is not the intended behavior. In my case whenever I create a new page or change an existing page, the jk_publish_from field gets populated automatically on page save with the current time, although I save the page as unpublished and keep the field empty. This in turn results in an (unwanted!) publishing on the page on the next execution of LazyCron. I think that the problem is in the following part of the code (lines 412ff): protected function setPageStatusManually(HookEvent $event): void { $page = $event->arguments(0); // check if jk_publish_from field is present on the given page if(!is_null($page->jk_publish_from)){ $from = true; bd($page->jk_publish_from); if ($page->jk_publish_from) { $from = $page->jk_publish_from < time(); bd($from); } else { $page->jk_publish_from = time(); bd($page->jk_publish_from); } $to = true; if ($page->jk_publish_until) { $to = ($page->jk_publish_until > time()); } if (!$from || !$to) { $page->addStatus(Page::statusUnpublished); } } } If jk_publish_from is empty on page save, it gets populated automatically. Is this intended? Shouldn't the module only act if a value has been (explicitly) added by the user? The editors brought up this issue because they often draft new articles without knowing the puplication date in advance. The drafts shall of course stay unpublished until they are ready to publish and explicitly scheduled or published manually. Your clarification is highly appreciated! Best Flo

+1 for uptime-kuma. Setup as a docker container is really straightforward. I have it running on a Synology NAS and use Pushover for push notifications to my iPhone. The only downside is getting data out of uptime-kuma. It stores everything in a sqlite db and you have to get that out of your docker container and use some other tool to generate CSVs for example. Possible, of course, but not as easy as the UI of the frontend might suggest. ?

Hey @teppo, I occasionally noticed some PHP Warnings when editing pages that use repeaters: PHP Warning: Attempt to read property "type" on null in .../modules/VersionControl/ProcessVersionControl.module:668 Could be changed to the following to suppress the warning: // before if ($diff && wire('fields')->get($field)->type instanceof FieldtypeFile) $diff = ""; // after if ($diff && wire('fields')->get($field) !== null && wire('fields')->get($field)->type instanceof FieldtypeFile) $diff = ""; Maybe something that could be addressed in a future release?

Any news on this? I was also having this problem for a while now and disabling TracyDebugger helped a little, but the error messages still find their way to my mailbox. This is happening on a virtual server running PHP 8.1.27 and mariaDB 10.11.4 with PW 3.0.229.

It's a pity that I did not make it. Is there still a chance to participate? And if there is, how? ?

This seems to be a bug in the core that is still present in the current release (3.0.229, main branch) and has to do with the query generation for the next page. For superusers there is no problem because of PageFinder.php:2230 (getQueryAllowedTemplates()), superuser just skips the checks for allowed templates in the query completely: Comparing the database queries for the superusers with the one for other (logged in) users showed the error in the query. Query for superuser: Query for other (logged in) user: It is quite obvious that there is an error in the SQL syntax. The problem has to do with the number of templates that a user is allowed to edit. In this case, the user (editor, no superuser) is allowed to edit all templates (inheriting page-edit permissions from the homepage). As soon as I add a template that no user is allowed to even view, the „Save + Next“ action is working as expected and—obviously—the query changes and everything is working: Query for editor after adding a template that nobody (except superusers) can access: Maybe @ryan can have a look and dig a little deeper? This might be an edge case that almost never happens (because in most cases template access might be restricted for every role to some extend) and adding a template without access is a workaround, but it would be cool to have it fixed nonetheless. Cheers Flo

Perfect! See you then! ?

Hey @bernhard, I have used AdminStyleRock multiple times and also really liked being able to adapt it to a client's corporate design in no time. I am (as usual) really busy at the moment, but willing to at least give some input (if you want me to). The main problems I see with AdminStyleRock are the ones that I also have with the standard AdminThemeUikit. Many of my clients have complex forms in the backend and while the general theme is simple and quite minimalistic, UI elements take a lot of space, editors have to scroll a lot and that is something that makes up for a bad user experience. A good backend should feel like a tool that supports you in doing your job as efficient as possible. For me and a lot of clients AdminThemeUikit never felt this way, the Default theme, however, feels outdated. AdminThemeUikit might be fine for a simple blog page or forms that consist of only a few fields, but for more complex things I still prefer the default theme. I would love to have more configuration options in AdminStyleRock that make it easy to not only adjust colors and maybe how shades are calculated (could be nice to have, if you want to adjust contrast or the general feel of the style to an existing corporate design without overcomplicating things), but also be able to adjust margins and paddings (or choose between 2 or 3 optimized and battle-tested variations) to be able to create a more compact/dense/tool-like experience. I hope, that makes sense? If there is no pressure involved in the development and sporadic feedback is appreciated, I'd be happy to help. I should be able to join in on Friday, but me and my family are struggling with Covid at the moment, so don't be mad if I have to cancel it last minute. Flo

@poljpocket I had already solved that here, but used it in the (at least for now) final solution here. ?

@da² Thanks for your input! Regarding save vs. saved: This is why I chose save, but both should work. I was aware of the 'noHooks' option, but thinking it would prevent the page updating after the rename action. I finally found a solution that serves all my needs and works well so far. I outsourced the renaming part to a function: function renameApplicationEntryFiles($page){ if($page->parent->template->name == "application_entries"){ // only do this for application entries $fileFields = $page->fields->find('type=FieldtypeFile'); $page->of(false); $renamedFiles = false; foreach($fileFields as $fileField){ $fieldname = $fileField->name; $pagefiles = $page->get($fieldname); $index = 1; foreach($pagefiles as $pagefile){ $newFilename = $fieldname; // if there are multiple files, add index to filename if(count($pagefiles) > 1){ $newFilename .= "-".$index; $index++; } $newFilename .= '.'.$pagefile->ext; // only rename if filename is not already set if($pagefile->basename() != $newFilename){ $page->get($fieldname)->trackChange('basename'); bd("renamed: ".$pagefile->basename()." -> ".$newFilename); $pagefile->rename($newFilename); $pagefile->save(); $renamedFiles = true; } } } if($renamedFiles === true){ $page->save(['noHooks' => true]); return true; } } else { return false; } } This function gets called on save and through the conditional Pagefile::install hook which covers all of the cases I need to cover: $this->wire->addHookAfter("Pages::save(template^=application_entry)", function(HookEvent $event) { $page = $event->arguments(0); $fileFields = $page->fields->find('type=FieldtypeFile'); $empty_pagefiles = false; foreach($fileFields as $fileField){ $fieldname = $fileField->name; $pagefiles = $page->get($fieldname); if($pagefiles->count == 0){ $empty_pagefiles = true; } } if($empty_pagefiles === true){ $event->addHookAfter('Pagefile::install', function(HookEvent $event) use($page) { renameApplicationEntryFiles($page); $event->removeHook(null); }); } else { renameApplicationEntryFiles($page); } }); Maybe this journey can be useful for someone, I had a hard time finding forum threads dealing with hooks related to Pagefiles. And of course I am still open for suggestions on how to optimise my solution. ?

@poljpocket Thanks! Wanted to delete that (stupid) post, but since you referenced it, I'll leave it where it is. ? My problem with saveReady is that this only works for pages (and files) that have been saved before (so files are already present). I think I got a lot closer to what I want to achieve with this: $this->wire->addHookAfter("Pages::save(template^=application_entry)", function(HookEvent $event) { $page = $event->arguments(0); if($page->savedByThisHook) return; bd("save hook triggered"); // get all fields of fieldtype file $fileFields = $page->fields->find('type=FieldtypeFile'); // bd($fileFields); $page->of(false); $empty_pagefiles = false; $renamedFiles = false; // loop through all file fields foreach($fileFields as $fileField){ $fieldname = $fileField->name; $pagefiles = $page->get($fieldname); $index = 1; // bd($pagefiles); if($pagefiles->count == 0){ $empty_pagefiles = true; } else { foreach($pagefiles as $pagefile){ $newFilename = $fieldname; // if there are multiple files, add index to filename if(count($pagefiles) > 1){ $newFilename .= "-".$index; $index++; } $newFilename .= '.'.$pagefile->ext; // only rename if filename is not already set if($pagefile->basename() != $newFilename){ $page->get($fieldname)->trackChange('basename'); bd("renamed: ".$pagefile->basename()." -> ".$newFilename); $pagefile->rename($newFilename); $pagefile->save(); $renamedFiles = true; } else { bd("not renamed: ".$pagefile->basename()." -> ".$newFilename); } } } } if($empty_pagefiles === true){ // $pagefiles still empty, not yet installed? // add hook! $event->addHookAfter('Pagefile::install', function(HookEvent $event) use($page) { // trigger page save again to rename files bd("conditional hook triggered, installed file". $event->arguments(0)); bd("is_file: ".is_file($event->arguments(0))); $page->savedByThisHook = false; $page->save(); $event->removeHook(null); }); } if($renamedFiles === true){ $page->savedByThisHook = true; // prevent infinite loop $page->save(); } }); The key to finally having the database reflect the filename changes was $page->get($fieldname)->trackChange('basename'); This works fine for pages that have been saved before, but I can only rename files that are already present in the filesystem, which seems to happen while/after save() has been called. Is there any method I did not find (maybe it's too late) that I can use elegantly that fires when alle pagefiles are already present? My strategy was to add another conditional hook when I recognize a $pagefiles->count of 0 after Pagefile::install, save the page again (and in consequence trigger the renaming process). This works almost the way it should, because it triggers the renaming for 2 of 3 files, but the 3rd will never be triggered automatically (without saving the page manually again). This is what happens: Although this does not look as elegant (and short) as I thought it could, it does almost what I want. As I feel very close, I'd be really thankful for help. Maybe there is a completely different approach to this problem? Or maybe just small changes that make it work the way I want?