Leaderboard

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?

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

Lots more Adminer updates in the last couple of weeks, but the key things are: 1) Shift-click on the DB icon links will now open Adminer in full mode rather than with the Tracy panel 2) Page, template, field, etc ID within Adminer table views are now linked - note the page title (and path) and the link to edit that page - this comes from hovering on any of the id, parent_id, templates_id, created_users_id, modified_users_id, etc. These sorts of links are present throughout including linking to modules from the "modules" table, hanna_code, pages_meta, etc. It also works for all Page Reference field's page IDs in Profields Table "field_table" tables, Profields Combo, repeater, RM fields, etc. Hopefully you'll all find this as useful as I am.

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

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

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

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.

Hello Flo, thanks for reporting this issue! You are right - the automatic population of the "from" field should not happen if a page is unpublished at the moment of saving. I will not add a quick fix inside the Hook function only, which is responsible for this behaviour. Instead I will test the module functionality more intense before offering a new update. I guess (hope) I will offer a new update solving this issue til the end of this week. For the moment, please overwrite the "from" date with a far date in the future to prevent the page from beeing published. Best reagards Jürgen

Me too! This is now default in all my installations for all the reasons you mention. But I feel this sort of update would be a PW4 thing?

Here's one place this was talked about in the past: https://github.com/processwire/processwire-requests/issues/142

You installed it manually... so I would check first if you can also uninstall it manually before you move or delete the files. If you instructed PW to use the /wire version beforehand, that should be safe.

Thank you, that enabled me to save the page again.

Try pushing the max_input_vars value in the server.

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.