Jump to content

Ivan Gretsky

Members
  • Posts

    1,400
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by Ivan Gretsky

  1. Most of us have been through this. You start not knowing anything and do most of things by trial and error. But at the end you come out stronger and more knowledgeable. I do not think there is a shortcut here. To learn something is to find yourself in the place of ignorance first. You should solve your tasks one by one, searching the forum, reading the code, asking the community if you get stuck. I do not think anyone is "too beginner". But everyone has to start from where he is at. There are a lot of docs, great forum posts and other resources spread around. but there is probably not a single tutorial to complete and become a ProcessWire master. Take you time, be patient, have fun along the way)) P.S. And just to address you specific questions a bit, I would recommend you this link... and many more here - just search for "create form")))
  2. That is just awesome! Why did I never seen it in the docs? Is it even there?
  3. Any would do for me) But maybe a border from one side could be enough? Top or left. Another option would be a warning sign icon to the left of the TRACY label with a popup, describing why it is here (kind of like Server Type Indicator).
  4. Thanks for making this video @Jonathan Lahijani! There is a lot to study from it. Let me ask one question right away. How did you changed the block colors? Is that already build in like Ryan said it would, or is it with custom css for now?
  5. Thanks, @adrian and @teppo! This is great way to handle it, as we can override this setting in config-dev.php. By the way, where can we find all the config options available for Tracy? It could be beneficial to have some kind of color indication for this in Tracy bar, so we won't forget to change the setting if we're on prod. Something like a color flag. What do you think?
  6. Welcome to the forums, @Shohan Arafat! If you want it in admin it must be a custom process module. You can learn how to make one here (for example). But I am not sure I really understood your needs. This is your 1st post, and it might be you meant something very different. Please explain your needs better if my link above is too much or completely irrelevant.
  7. By the way, @bernhard, could you please provide an example)
  8. Hey, @teppo! I am back at this great module. Trying to make everything work as it should. I've read your conversation with @bernhard a number of times and think that a lot of issues discussed should make their way into the docs somehow. And answering the question quoted above (about the usage of custom page classes and controllers in Wireframe) would make another great page for Patterns and practices . The great docs are one of the main things that make Wireframe so attractive, as we can easily point to them when working in a team or passing a project to someone else. So keeping them up to date and adding more info is definitely as important (for someone who didn't write the framework in the 1st place))) as adding new features. I would participate in this process if there was a way to. At least I would fix some typos. But as cool as PW backend is it is not as good for open documentation. Is there a chance we can move the content creation to github and populate/update pages in PW via a script? I think someone already done this before...
  9. Here is the way htmx recommends to deal with it. I was thinking, maybe it would be possible to deal with it by emitting document ready on each htmx.onLoad. But that would probably run lots of things that shouldn't run)
  10. There are a few ready-made ways to have composable components in PW: https://processwire.com/api/ref/wire-file-tools/render/ (native built-in) https://wireframe-framework.com/docs/view/components/ https://processwire.com/modules/twack/ https://github.com/wanze/TemplateEngineFactory/blob/master/DOCUMENTATION.md#controllers But they are probably not exactly the same thing as in NuxtJS as this is PHP.
  11. And, by the way, polling should be ok too, if SSE will turn out to be too hard)) I guess this way live preview can be implemented really fast.
  12. Just to make it clear. htmx has SSE client built in, but the SSE server part is still to be implemented. @netcarversuggested ReactPHP for that purpose. There are other options to choose from. Or we could invent our own) I didn't quite grasp the "/path/to/page/?change=body" thing. Who is to request that? When doing the SSE thing we send something to the preview without it requesting anything. So it is the SSE server function to generate partial markup depending on the changed fields and pass it to the view. And htmx can handle not the full markup, but parts of it and swap just the piece it receives (with something like this). But it is a on step ahead - we need to have it working with full page swap first? as @ryan said.
  13. Thanks, @ryan! This year's end seems to be even more interesting than its beginning) If that is required for the live preview it should be in the core, IMHO) If I understand it right, the core of what we need to build is something listening to a page save event and refreshing the preview page when it happens. Now we have an autosave to generate the events. The other part is reacting to that autosave. I can see 2 ways of doing that: ajax polling and sse (we probably do not need WebSockets as the preview doesn't need to send anything to the server... yet?). The latter (sse) seems to be a better fit, as it should use less server resources, but might be harder to implement (maybe not). Anyway, htmx supports sse (and even ws to an extent), which makes it a better fit than unpoly that doesn't (at least it didn't not so long ago when I checked). Actually, we could go without htmx, just taking inspiration from the principle it is based on. Though taking the ready-made library could be easier. The other part where htmx (or unpoly, or turbo or...) could help, is refreshing not the whole preview page, but only a part of it. Regenerating the whole page markup could be a long process (those 2 seconds in the OP are way too optimistic for many of the sites I have seen). For example, we could regenerate only one PM block markup and sent it to the preview for htmx to swap. But that would require either some standardization of the frontend or some hookable architecture for a developer to implement. The former would break the core PW principle of leaving frontent to the developer. The latter should be possible and would work nicely when rendering RM based content builders the standard way or with a Wireframe. Unpoly is complete framework, which could be used to upgrade PW admin as a whole, but would probably require to do everything its way. For a one place thing or for a more-work-more-customization htmx is a better suit, as it is lower level, as both of you @Craigand @kongondoagreed. If we bring in unpoly, we need to be ready to slowly redo all the admin area with it (which might be a nice thing in the long term). But for one task htmx is lighter solution. And we could even go without it only getting inspiration from it.
  14. Love to see those PW related tutorials appear in YouTube search results) Great one, @Jonathan Lahijani! It seems you are using PHP 8 and MySQL 8 for development. Are you using those in production too? I was waiting for something to make a move to PHP 8, but the forum says it is too early. What is you experience?
  15. Love this! If you stay up late enough on Friday night (it is almost midnight here), wonders will happen!
  16. I just re-read the previous post. It is what i did ask for not knowing we already have it) Could you please consider also allowing to put color code in that item headers string, so we can also define a per-type color? That would make different types really stand out)
  17. Super cool! Just amazing) This is what we, the Repeater Matrix lovers are waiting))) Are those type icons already present in the new version, or are you saving them for now?
  18. I do not think they are mutually exclusive. And htmx is adding only 11kb True. Another way to deal with this could be using front-end editing. So RM blocks would get a border on hover with an edit button somewhere. All the configs could go in the popup with the repeater item fields showing on click. This could be probably done with htmx even without changing the Repeater Matrix core. But this is also not a solution for everyone, as it is not in admin. Meanwhile @Robin S recently released a module that changes the RM UI kind of in the ACF Extended direction. It adds colors to the RM types chrome (that is only part of this module's functionality). If we could change the items chrome in some easy way out of the box (like adding color + icons + per type labels) that would already bring us forward a lot. Just a possible 1st step))
  19. I think I remember @ryandid write about implementing something like ProDrafts' live preview in the core everywhere, so we can change a page in one part of the screen and see it dynamically update in the other. I think this might be another way of doing UI for this, maybe even a better one (or complimentary to the one mentioned before), as we can see the changes not in some pseudo-markup, but in a real one. And do not have to create this pseudo-markup and styling in the 1st place. By the way, I can see how htmx can help here too.
  20. I was too, but @Jonathan Lahijani's explanation cleared things up. We only have to look at the thing inside a screen mockup (see my screenshot). We can interact with it create new blocks and toggle the edit/render state of the blocks. This thing can be a better UI for a RM-based content builder, but when dealing with a lot of blocks it can get in the way taking too much space. Anyway, I think there is a rather not-so-hard way to implement it not changing everything in PW admin (not rewriting it as a SPA) - using something like htmx (see example in the end of the linked page). Htmx is getting a lot of attention in Django and Flask communities lately. Maybe we could use it for these kind of things.
  21. Thanks for the great suggestions! Will make my mind around it and try. If anyone has other ideas or experience on the topic, please share. I did not consider REST API for using $user data from the main registration site on the other installations (and do not have expertise in this). Are there other (simpler? more PW-ish?) ways to do it?
  22. Maybe there could be an easy solution? Like adding a list of ips and/or domain names that should be treated like a localhost to the config?
  23. Cool stuff, @Rudy! May I ask a few additional questions? Do you limit the ability to login/register to only one installation? How? You do not re-create users on all installations, do you? Are you using user info from one installation in all the others? I mean something like $user->hasRole() and things like finding users? How? Are you using API call to other instances?
  24. Great additions! Have not tried'em yet, but my next week will be full of fun) Thanx, @ryan! I was amazed to see my name in the blog post, but I need to say that all the credits for those images should go to @David Karichas they were taken from his fundamental video. By the way, everybody caring about the future of PW and its infrastructure please ??? donate to David as a creator, who shapes the things we use (and dream of), so he feels even more motivation to keep doing his thing. He asked for the support. And of course, go get your copy of ProFields if you have not already, as that is one of the coolest ? things you can get for your PW site and supports PW development as a whole. Sorry for the emojis, but it is late friday night here where I am at and I feel exited)))
×
×
  • Create New...