All Activity

@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! 🙂

That's a cool idea! Very interesting

I always used simple plain-text signatures cause I thought they didn't matter. However, after using corporative signatures I noticed that they grab my attention more often.

Hello Flo, should it look like this: At the moment the icon will be displayed if a start and/or an end time has been set, but id does not take care if a change will happen in the future (publishing or unpublishing of the page)

Sure 😊 https://processwire.com/docs/fields/select-options-fieldtype/#multi-language-translating-options

I didn't think about that, but it could be. I don't want to make assumptions about ease of implementation. Breaking changes could be mitigated with fallbacks- use the env if it's available, and fall back to config object if not. I think what would be a true PW4 change would be full adoption of .env and deprecation of config.php. A case could be made that fallbacks now can introduce gradual adoption and make a breaking change in PW4 less impactful. I hadn't seen this discussed there in a formal repo thread before, but good to see interest elsewhere. IMHO, the initial framing of the request around 12 factor apps could have been simplified to just benefits and good practice. Conversely, the argument that not everyone is building 12 factor apps isn't a case against it. All said- I don't want to be critical of a conversation that happened that long ago, I mean- who would I be to talk? I wasn't using .env files in 2017 🤷‍♂️ I do want to share a thought on this specifically in ProcessWire context. One of my favorite things about PW is the file structure philosophy where core lives in /wire and templates, styles, additional modules, assets, etc. live in /site. Site is a living breathing volatile folder and the domain of the developer to extend ProcessWire as a project demands. Replacing /wire is one of the most frictionless upgrade concepts ever and it's flat out elegant. It would be great to see the /site folder adopt that- a true "drag-and-drop" self-contained application directory that can be deployed anywhere ProcessWire exists. The /wire directory wouldn't be dependent on /site, and (aside from core version) /site wouldn't be coupled to /wire. Consider that the root directory is already environment specific. The .htaccess file, node_modules, vendor, .git, etc. are all in environment context. The use of .env fits here. This may come off as an esoteric or abstract argument, but think about how much time you spend naming things in programming and tell me that's not the world we live in 🤣 To address a point in that Github thread as to considerations made inside /site for environment, such as an 'if' statement whether on dev or production, I think that's great for application logic that responds to the environment but does not alter it. It would be great to see this adopted into core, but as always with a project like ProcessWire it's up to the people doing the great work of maintaining and improving it to determine priority. Even if it's not implemented in core, I hope to have made a case for adoption in individual projects.

Thanks for the insights @bernhard, so about the loading order That's the part I was wondering about, since it used to be the other way around in earlier version of RF, as far as I remember. I was wondering if that was an intentional change. Just autoloading the UIKit CSS and JS files (without defer) in the current build gives me pretty bad FOUC and Firefox complaining If I reverse the order by disabling autoload and rendering the assets manually those Firefox warnings disappear, and I feel like the pages render a lot smoother in FF. As for other libs I'm using on a regular basis, at least Leaflet is pretty specific about the loading order of CSS and JS, see here https://leafletjs.com/examples/quick-start/ But I guess that too could be handled via the "defer" method you described earlier. Just need to keep it in mind 😄

@ryan - just following up on the comment by @Denis Schultz - now 4 years on, are you still planning on adding that "Unique" checkbox for Text and Integer fields?

Just curious, does anyone know the approach @ryan uses to minify module JavaScript files? For example, how is he minifying this: https://github.com/processwire/processwire/blob/dev/wire/modules/AdminTheme/AdminThemeUikit/scripts/main.js to this: https://github.com/processwire/processwire/blob/dev/wire/modules/AdminTheme/AdminThemeUikit/scripts/main.min.js Ideally I want to use a CLI-based tool (Linux-based), but I want to avoid using a Node-based solution (such as https://github.com/terser/terser).

Hello Flo, I have pushed the module version now to 1.3.6. This version does not auto populate the fields. I have removed all the Hooks which are responsible for auto population. So this is the one, which fits your requirements and you can use it until the other additions have been implemented. Best regards

I tried accessing your website (and the problematic page) last night and also encountered the error. The error message that I received was about a proxy server having issue, however. Is the current host using nginx or Apache? If there's a proxy server somewhere in there (if not nginx) then it's going to be beyond my experience/capabilities to know how to help. Otherwise, maybe look into why that particular page section (Newsboard) seems to cause trouble when other pages mostly load rather quickly. ProDevTools' ProfilerPro might be useful here, if identifying problem areas on your own ends up being difficult to find.

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

Great idea! I will try to publish the new version as soon as possible, but I cannot say when it will be happen.

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).

Making a visible alert/info about the current status and the future status too seems to be a good way and I can agree with it too. I will implement this feature and update the module after test runs.

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.

Maybe I'm missing something but isn't your selector returning another page then? If you uncheck the checkbox then you have pj_kub_published='' for that page, but you are selecting =1, so your page does not match and it will find another page having =1 and that obviously has a modified date in the past?

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?

It is more consistent, if a page is published and the date and time of publishing is visible in the published from field too. Otherswise, it may seem a little bit strange to some users, if the page is published, but the publish from field is still empty. But you are right, if you mean the visibility is handled by ProcessWire only 🙂

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

Hello Flo This is not so trivial as it may seem at the first sight, because there are use cases where automatic population makes sense: For example: An auto population has to take place if your page is unpublished and you push the publish button, but you do not have entered a date into the from field. In this scenario the current date and time have to be set (auto populated) inside the from field. I will test some other scenarios as well and I will provide another update, if there are some use cases not covered by this version.

@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 webguy, Unless your client wants to be able to entre their Google Tag ID themselves, no need to create a field for that. As markus-th said, just hard-code it in a partial template that is included on every page (the one that contains the <head> part of your pages).