szabesz

Hello, Maybe this can be a good starting point: https://processwire.com/talk/topic/21756-field-access-on-runtime/?do=findComment&comment=187094

@MarkE I rephrased your post above a little bit and fed GTP-4 with it. This is what I got: Circular dependencies can indeed present a challenge when dealing with database migrations. Your proposed solutions are viable and could work depending on the specific situation. Let's delve deeper into each approach and discuss their potential benefits and drawbacks: 1. Performing the database migration in multiple steps: This approach is generally safe and effective, as it ensures that all required objects are present in the database in the end. However, it may require careful planning and sequencing of migrations to ensure that each step has all its dependencies satisfied. This approach is encouraged by your module and is also recommended in Django's migration documentation [Source 2](https://django.readthedocs.io/en/stable/topics/migrations.html). 2. Including an item twice in the migration: This approach involves initially adding the class or field without the dependency, then adding the dependency after the referenced object has been added. This method can work, but it may be complex to implement and maintain, especially for large databases with many interdependencies. Your module currently doesn't support this approach. 3. Running the migration process twice: This approach relies on the hope that the second run will resolve any missing dependencies from the first run. While this may work in some cases, it's not a guaranteed solution and could potentially lead to inconsistent results. Therefore, it's typically not recommended unless you have a strong understanding of the specific dependencies and migration behavior in your database. Another approach worth considering is the use of **"swappable" dependencies**, as mentioned in Django's migration documentation [Source 2](https://django.readthedocs.io/en/stable/topics/migrations.html). This allows you to declare dependencies that can be swapped out with different implementations, which can be useful when dealing with circular dependencies. Hmmm....

I can confirm all this... and I also in favor of a solution that works the way @MarkE designs it. As soon as it is ready for testing and I have the time, I will surely try it out as well.

+1 as I am also longing for that.

Related tutorial is located here:

Hello, Maybe this thread can help as a starting point:

Last time I needed to use JS to modify stuff after each AJAX request to solve a similar issue I used this: https://stackoverflow.com/questions/10783463/javascript-detect-ajax-requests/#answer-67250545 stackoverflow.com can still rock. I would not be surprised if OpenAI swallowed a lot from there...

Promising technique indeed, thanks for posting about it! I will explore it when starting my next project.

@mpdude Using the hook like @ngrmm posted above you can fulfil this requirement: "certain users may make changes to existing pages and preview those, but the changes will not yet be published (is that the right term?) and visible to anyone else. Only when another user with more permissions (say, a reviewer) approves a certain change it will become visible for all website visitors?" And you could use Robin's module to also let clients review a page before it is published by the reviewer.

Another and free option is this module https://processwire.com/modules/access-by-query-string/ from @Robin S It is not comparable to ProDrafts but might do what you need.

This is what people call incredibly useful! Thanks for sharing, as always!

If you are concerned with file size like that then you can use CDN (https://unpoly.com/install/cdn) conditionally: load local files when CDN is not available. Unpoly also have advanced caching, so by using that properly your site can behave more like an application then a website by providing (almost) instant responses. (As a related side-note, I also agree with this certain forum user on this forum: https://forum.bootstrapstudio.io/t/bootstrap-css-and-cleanup/10578/2?u=szabesz) As for my own experiences, I have not yet implement the conditional usage of CDN but the e-commerce site I developed using Unpoly for its frontend JS magic is loved by customers, partially because of the easy to use user interface I crafted for them, and partly because of the speed of the site, even though it loads full Bootstrap 5, full jQuery and also Unpoly (plus my CSS and JS, of course). Sure, browser and Unpoly caching helps a lot! About half of the users use their mobile phones to place orders and they are equally satisfied. I just cannot showcase the site because currently it is for contracted customers only. There are plans to open it up for the average retail customers as well (on a different domain) so when that is in production, I will probably provide this forum with my very first showcase. (In 1 or 2 years... as I have loads of other projects to finish before I can start working on that.)

Yea these is how I think about it as well. HTMX is less opinionated and I like it that way. However HTMX is not the "JS sprinkles" (it's more for HTML over the wire requests) so that's where Alpine.JS comes in. While Unploly is definitely more opinionated for sure, that's also its strength and weakness at the same time. If someone starts using AlpineJs along with Unploly, then that person should use HTMX + AlpineJS instead in the first place. While Unploly is definitely more opinionated, it does not mean that based on Unploly is not possible to implement the same features that one would implement using HTMX + AlpineJS. You just need a completely different mindset when using either this or that. By using HTMX + AlpineJS one gets a sort of "lower level" solution while Unploly provides "higher level" tools. Using high level tools has the benefit of also dealing with documented conventions out of the box, while building upon a low level tool requires you to put more work in your documentation. High level tools has the drawback of sometimes having to find workarounds for different use cases, while low level tools introduces less of such issues. I don't want to persuade anyone to use Unpoly, but I want to mention that I use and love it, particularly because upgrading to major versions is always backward compatible. (Backward compatibility support extends to the previous major version.)

If Unpoly was non existent I would sure use AlpineJS + HTMX these days. However, https://unpoly.com/ does exists and to me, having to use only one technology instead of two (or more) is very important. The fewer I have to deal with the better. More importantly, easy upgrade path is essential, so no wonder I am not willing to leave ProcessWire :)

Can't wait! :) +1

No access from Hungary or many other places form the globe either. US and Canada based VPN access works. I suspect that only North America is allowed.

It is definitely not, I agree. I think even the introductory blog page does not make it clear what the purpose of DefaultPage actually is: https://processwire.com/blog/posts/pw-3.0.152/ And a lot more could be documented and supported, see my old thread, for example:

Interesting but I find it hard to digest this chart as being a useful overview. I keep looking at it and fail to "keep anything of it in my brain". I find the following "cheat sheet" much more informative and therefore usable: https://addyosmani.com/blog/script-priorities/

Yes, I refactored my code by using URL hooks which is much cleaner anyway. Maybe. I could dig up the old code to take a look at it but the issue is not important anymore. Thanks for you support!

I should have checked first if there is new version of the module or not, I was banging on open doors... Thanks anyway, the new hookable method is very useful, and not just because I can now save custom data but because I can also skip logging saves performed by hooks only (by setting $event->return to null when a field is only changed by a hook and not by a person).

Yet another pretty useful module from New Zealand. Thanks a million!

That's strange as it does work for me. Did you double check everything?

@teppo It's me again :) I wonder if you could somehow make it possible to optionally log more data in "$details" via hooking into the process, by more data I mean some filed values that has been changed. if (!empty($fields_edited)) $details['Fields edited'] = implode(", ", $fields_edited); https://github.com/teppokoivula/ProcessChangelog/blob/49c35bb65ae5642401df062168fa6f4a69dfbf75/ProcessChangelogHooks.module#L595 My use case is that such a feature could make it possible to do detailed debugging. If I could store some additional key data change, then I could reproduce what exactly happened, so that I can replicate the exact issue. Of course, I could just put logging all the data I need in my on code, but having your module do that instead would make an integrated solution.

@franciccio-ITALIANO Can you please also wrap your code in the "Spolier" block as I requested? Very long posts make it pretty hard to see through a thread. The "Spolier" block hides its content in an accordion so that we can manually open it at will.

Hello, You should paste in here the exact code of your _main.php, preferably hidden in a spoiler block of this editor (use both the "eye" and the "code" icons of the toolbar). That way we can have a better understanding of the issue and ask further questions.