Jump to content

bernhard

Members
  • Posts

    6,268
  • Joined

  • Last visited

  • Days Won

    314

Everything posted by bernhard

  1. Thx @Robin S I definitely didn't have that on my radar! Do you have a suggestion what to use if I just want to make sure to get the images' field data as array independently from the template context but not showing temporary or unpublished items?
  2. Totally agree. ProcessWire is so amazing I wish I could grow with it in larger scale projects. Totally disagree. At work we are 3 devs at the moment working on the same projects all the time and we have fully automated deployments both to staging and production. And it is easy to review and merge pull requests. And I've shared all that is necessary with the community. For free. And so has @LostKobrakai @MoritzLost Please stop stating your points in a manner that discredits the work of others or the way how others are working. Thank you. We have wire shell. Why don't you take up this project? You are obviously in need of such tools. Why do you keep bashing around and do not help improving the tools that we already have or help to make new tools being created and - also important - being shared with the community? I like that you bring up all those points, but I really don't like the way you are doing this. Imagine someone evaluating ProcessWire and somehow finding your thread or reading it by coincidence. Even if that person will likely not read it with the same emotions that I do he/she will still get an - in my opinion - wrong picture. I think it is in the interest of all of us to promote the things we have and to encourage everybody to take part.
  3. And if you want to make things a little more obvious to anybody reading your code (or simply to yourself) you can use getUnformatted() to return the array version of the field no matter what the current outputformatting is: <?php $images = $page->getUnformatted('imagesfield'); if($images->count()) { $img = $images->first(); ... }
  4. Sarcasm (scnr): I've noticed lately that the most valiant defenders of the opinion that PW lacks support for migrations are the ones that have never given https://processwire.com/modules/migrations/ (which dates back to 2016) and https://processwire.com/modules/rock-migrations/ (which has it's 3rd birthday next week ? ) a serious try ? ? Personal note: While I did not read your posting as offending as Ryan seams to have read it I can totally understand his reaction. I have not put a fraction of the time into ProcessWire compared to Ryan but still I was confused about some statements you made. And I know how it feels if you talk about things in a way you did in this thread and in a similar way you did in this thread and in this thread. It might not have been your intention, but it seems you are a bit quick in stating "how things are" and how they have to be... Back to topic (and I try to keep objective): -- Selectors -- Ryan has already answered here. I just want to add that I'm using array syntax for selectors a lot and I really like it ? BTW: Just noticed that it's also a birthday for selector array syntax: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support Happy Birthday and thanks for being with us and being a reliable tool in my everyday work for the last 6 years ? Could you please explain the vulnerability here for others to learn from your example? -- Features -- I just wanted to share that I've had quite the opposite experience with a lot of tools that I've tried over the last view years. At first sight there was a lot of bling bling and shiny cool things, but at second sight I found limitations here and other annoying parts there. Maybe I've just tried the wrong tools but with ProcessWire my experience was exactly the opposite: My first impression was that it is by far too simple for what I need. Several years later I feel like I'm just scratching the surface ? -- Twig -- I'm SO happy that we don't have such a layer by default in ProcessWire!! I've not worked much with template engines but I've used smarty back in 2004 so it's not that I don't know that such tools exist or what they are for. Though what I do a lot is keeping my template files as clean as possible. How I do that? I use custom page classes everywhere and if I need just a little bit of logic somewhere I put that logic into the page class to keep things simple on the frontend part. What I really like here is one of the biggest benefits of PW of all: It keeps simple things simple and makes complex things possible (and fun). If you have just started (with PW or with web development in general) you can simply echo some page properties and see the result on the screen. No additional tools. No necessary build chain. No template engine. Just PHP and HTML. Great ? In my opinion ? I've recently had to try another open source CMS. That CMS has native support for migrations as everything goes into YAML files. It has fancy backend editing for everything. Fancy, yes. But that adds another layer of complexity to the whole thing as well. Imagine how long it took me to understand how I can create a single field and display the content of that field on the frontend? Long. Very long. I don't want to tell you how long. ? Because of all that fancyness that system uses a custom language for rendering all the fields. It was a terrible experience for me and I felt really bad that I as a quite experienced PHP developer was not able to achieve simple things in a PHP based content management system. One user commented on one of their youtube tutorials that it's another perfect example of a german product developed by a few geniuses but impossible to use for the average dev. I agree with him and I'm happy that ProcessWire takes another route! -- Documentation -- I agree that lots of information is scattered around somewhere (in the forum, in the docs or in code), BUT (and that's the part you didn't mention and which is just another example of why things might be taken personally): In my opinion ProcessWire (or Ryan) does a lot right in that regard and is way ahead compared to other tools I've used (maybe tried the wrong tools again). For example the docs in code are absolutely great! Nearly every method that I need to inspect has some explanation directly in code so I can quickly jump to that place in my IDE or even get helpful pieces of the docs instantly as tooltip: Next, the forum: WHAT A GREAT PLACE!! I've been on another system before I discovered PW. They had a forum as well... But I simply did not get help there. I posted a question and did not know if I'll get an answer in one week or two, if ever. That was such a pain and PW is so great in that regard! It might be a small community but the support is outstanding. I've also seen other products that have a discord channel or something similar. Maybe forums are old-school, but in my opinion they are still great and will be for a long time. You have an archive where everybody can find answers to their questions and learn from posted answers. And one other great thing is that 90% of those answers will likely still just work if you apply them today even if they are several years old. -- Version numbers -- What I'd pick up from that point is that some of the strengths of PW might look like weaknesses for others on first sight. Just as the simple and clean backend for me looked like PW is not capable of complex things the used version numbers and the fact that the github master branch might not see any updates for several months can give the impression to others that the project is not actively developed. It's a matter of everybody's perceptions and expectations. ProcessWire could to more in that regard. But on the other hand I really appreciate that it (or Ryan) does not care as much about that as other systems do. The downside of this is that it can be hard to sell to other devs and/or clients... -- A word to Ryan -- I don't agree with you here and I think that's a blind spot on your end. ? When I started developing my first custom Fieldtype it took me quite long to understand how things work. Learning from the events fieldtype was really hard! It is obvious and simple once you know how all the pieces play together (you basically just need an inputfield and a related fieldtype for sleep() and wakeup(), right?) but it was really not easy to start with a blank screen in my IDE without having this concept in my head and then put all those pieces together one by one trying to understand what they do and then making them do what I want. I guess we didn't even have TracyDebugger back then. ? (By the way - how great is Tracy?! Another invaluable tool in our Ecosystem that I don't want to miss!) I think it's similar to what happened when I first discovered the PW backend. This was one of the most liked posts in the forum so I think it was and maybe still is not obvious to many how easy it actually is to work with and customize the PW backend. As a side note I think that might be one reason why PW is still underestimated in regards to being not only a wonderful tool to create websites but also a wonderful tool to create web applications. And I have to do it again: I think RockMigrations is just another example of something in PW that looks more complex than it actually is. And an example of something that looks less powerful than it actually is. I've taken that learning from the other threads and already improved the module greatly. The next version will make it a lot easier to get started with. Maybe that will open some eyes. And maybe Ryan will also revisit this thread one day and will recap and pick up some of the things that were mentioned. There were some good points in it and the amount of reactions shows that, I think. So thanks for bringing those topics up @MoritzLost and thanks for the insights as always @ryan.
  5. Browser cache? Logged in vs. not logged in? Copy the markup from "else" (the one that shows up) to "if" and see if that makes a difference. Maybe you have an error with some closing tag or quotes that the browsers handle differently...
  6. That <p> tags come from ckeditor: https://processwire.com/talk/topic/10999-ckeditor-remove-wrapping-from-in-source-code/ The easiest solution would be to change your code to this: <div style="color: white;"> <?=$faq->faq_answer?> </div>
  7. Why do you want to have an ampersand in your urls? It's a special character used for defining get parameters so I don't think it's a good idea to have them in urls and I guess that's at least one reason why the sanitizer removes it from page names. Why not just use "blick-and-docker" as url segment?
  8. One solution could be RockCalculator so that the client can easily calculate net from gross: So in austria they could enter 120/1,2 and would end up with the net value of 100. I really like to have that feature in some of my systems. Very simple yet very powerful. Another option is to hook the inputfield and add another input and some JavaScript: <?php $wire->addHookAfter("Inputfield(name=title)::render", function(HookEvent $event) { $field = $event->object; $field->appendMarkup = '<input type="text" name="foo"> <script> $(document).on("input", "input[name=title]", function(e) { let val = e.target.value; $("input[name=foo]").val(val); }); </script>'; });
  9. Yes, that's possible. Create an autoload module and in the init method set the config options so that it uses different css files for different roles: https://github.com/baumrock/AdminStyleRock/blob/main/AdminStyleRock.module.php#L32-L47 $role = "get users role id"; $style = "/path/to/your/style-$role.less"; $compiled = "/path/to/your/style-$role.css"; PS: Just realized that you might not be able to access the user role in init() so maybe you need to use ready() instead. Hopefully that's not too late in the process but I think it should work.
  10. $sanitizer->pageNameTranslate($page->getUnformatted('title'))
  11. You can set that in the module's settings of InputfieldPageName:
  12. Your usecase FAQ sounds like it would be a good fit for a repeater field. Add two fields to the repeater "question" and "answer" then you can add 1 to n items of FAQs to your page.
  13. That's why I was asking for a generic example. I'd not be happy if lazyLoading was disabled by default. It's imho much better to add one single setting to old installations when needed (and I have not had any issues until now) than to have ProcessWire not use it's full performance by default. And don't forget updating old setups is a one time thing. I don't know how this feature works internally but I'm sure Ryan has made that decision thoughtfully.
  14. @7Studio I don't understand. Which property can you not access? Can you give a generic example?
  15. You are not dreaming - this is already possible using RockMigrations: <?php $rm->migrate([ 'fields' => [ 'myfield1' => [ 'type' => 'text', 'label' => 'My field one', ], 'myfield2' => [ 'type' => 'text', 'label' => 'My field two', ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'myfield1', 'myfield2', ], ], ], ]); If you don't like PHP arrays for whatever reason simply use json_decode( _your_fields_and_templates_as_json_string_ ) instead... I'll release a new version soon that makes it a lot easier to get started with RockMigrations though the API will 99% be the same as in the old module.
  16. v1.0.1 removes the pw logo from the mobile offcanvas nav. before: after:
  17. The truth lies in the middle of both code snippets ? If using Pages::saved you need to use setAndSave because if you only change the page property there will be no later save that actually saves it. If using Pages::saveReady as 3fingers showed you can use setAndSave but it's actually not necessary. You can simply use $page->yourfield = 'foo'; as the page IS actually saved right afterwards. Also I prefer to use early exists rather than a lot of if ... if ... if ... but that's a matter of preferance ? <?php $wire->addHookBefore('Pages::saveReady', function($event){ $page = $event->arguments(0); if(!$page->hasField("my_checkbox")) return; if($page->my_checkbox) return; $page->another_integer_field = 0; $this->message("This should have worked"); //for debugging only });
  18. The backend is basically just a uikit navbar + content: https://getuikit.com/ You can simply include the backend theme files and use them for your frontend. You can even use the Less module and you get all the power of Less and variables etc. See https://github.com/baumrock/AdminStyleRock#how-adminthemeuikit-styles-work for details
  19. I think the next step for debugging this would be to setup a new project without any modules other than tracydebugger and see if you can come up with a reproducable example. You can then share this custom page class with us and we can see if we get the same results and can help debugging.
  20. Hey @ErikMH I haven't read everything in detail and I don't know what's going on here but my first recommendation as always would be to install tracydebugger. Once you have tracy you can do this: bd($this); bd($this->parent()); Then see what is shown in your debug bar (right bottom corner). Can you share that output with us? Are you maybe in a method that is called from a hook? Then $this would not refer to the current page so $this->parent() could lead to nowhere. Not sure why it would work on older versions of PW though, but at least that are some ideas.
  21. Just released version 1.0.0 which makes it possible to set both the main color plus the logo url from within the module (without going to AdminThemeUikit settings): AdminStyleRock Easily style your ProcessWire backend with two simple settings: Or via RockMigrations: $rm->installModule("AdminStyleRock", [ 'rockprimary' => '#0069B4', 'logo' => '/site/templates/img/kollar.svg', ]);
  22. No. All migrations will run again, but if you don't change anything they will likely not do anything. The good thing about this is that if something changed for whatever reason, the migration will change things back to the state that is defined in code. So for example if someone changed a field setting by hand, the migration would revert this change to what is stored in the migration. To make it more obvious that it might not be the best idea to change field or template settings by hand the new version stores a trace of the migration for every field and template and shows a warning on the field/template editor:
  23. Somehow this does not work for me... I had to change the fieldtype to text which is less than ideal but as it's a private project I'll leave that for now... If anybody finds out something please let me know. I think it might also have something to do with locale settings. Dumping the value showed 1,23 but the value was not stored in the DB (sql error data truncated...). Weird.
  24. Only option I know is plain SQL: <?php // populate test value $pages->get(1)->meta('foo', 'foo'); // find pages $result = $database->query("SELECT source_id FROM pages_meta WHERE name = 'foo' and data = '\"foo\"'"); $ids = implode("|", $result->fetchAll(\PDO::FETCH_COLUMN, 0)); db($pages->find("id=$ids")); If you use this with user input be sure to properly sanitize the data and maybe use prepared statements!
  25. Ok sorry about that. I try to explain it in other words. What I meant was that if your system is blocked and does not respond to new requests it is likely that you have a process that is still running. This can happen quickly while testing SSE because you can quickly get into an endless loop and the process will run and run and run and block your system until the process is killed because it reaches max_execution_time for example. That's why I suggested to add a hard break while testing so that you exit after 30 iterations and the system will get ready for the next request. Hope that makes sense now? I'm not sure I understand. My usecase was simply trashing multiple pages or updating multiple pages via RockGrid (bulk editing). The user selects multiple rows and then clicks on an action (trash, update, ...). The user is then asked to confirm the action, which triggers the process of updating/trashing pages on the server. Now the only difference to a traditional approach is that this request is kept open using SSE and it keeps waiting for the server to receive the progress (eg trashing page 1 of 10, 2 of 10, 3 of 10... etc). Until this action is finished the system will be blocked for other requests of the same user (I don't understand how that works technically, but I think that other users can still request data from the server in the meantime?!). When the server is done with updating/trashing all pages it will send "DONE" to the client and the connection will be closed which makes the server ready for the next request. So it's a very special use case but it's also a quite common need! The example you are describing can not be solved using SSE as far as I understand. I think one would need sockets here. But I don't have any knowledge about them so I can't say anything here but I am happy to hear how that would work even if that is not really on topic any more ?
×
×
  • Create New...