Ivan Gretsky

Good day, @adrian! Today I am having some large traffic on a project. And there stated to appear a lot of 500 errors like this: Error: Exception: Unable to obtain lock for session (retry in 30s). I have found this thread, turned off Tracy (which was id Development mode, but limited with tracy-debugger permission) and it seemed to help. Could you please explain if that is expected. Do we need to fix Tracy? Or the best practice is to have it off/in PRODUCTION mode on prod? Thanks!

We need to think about pros and cons when choosing. The pro arguments for 1 is that you have all data in a page tree visually related and that you can easily delete all related data deleting the corresponding order branch. As always, these pros are also the cons for the the opposite solution (3). Choosing 3 you can more easily see the lists of payments and fulfillments records. You can delete orders without deleting connected payments and fulfillments records if you need, but you also have to deal with the housekeeping when deleting by yourself. If you build the dedicated UI for all that in admin it might not even matter. As for me, feel inclined to go the 3rd root and do not see any arguments going the 2nd.

Good day @teppo and all the Wireframe fans! I am creating an authorization system to restrict some pages from unauthorized access. It should work like this. At some point in the page rendering process the code should check user auth (not PW native) and either proceed with normal page rendering process or show an authorization form. The auth form should render at the same url as the normal page and should have access to this page's data and custom methods. But it looks completely different and should have custom methods of its own. That's why I want to take the page object and render it with another Wireframe controller/layout/view. This controller should not be connected to any PW template and should have some independent name. How can I do it? Please help! P.S. I have some templates working under Wireframe and some with their own template files. But the authorization system should be based on wireframe and work for both of these. That kind of limits the possible options (like having a common trait in all Wireframe controllers) if I understand it correctly.

Hey, @wbmnfktr! Thanks for taking care of this project. Hope under your governance it will grow and thrive! I spotted some issues with responsive design. You get a horizontal scroll on some pages like this one. Take a look when you got time.

As far as I got it, it is just by convention. Nothing prevents someone to move the 1st item to another position. That was what I was asking about. In this case just maybe you can move the fields that should hold the data for the 1st item to the main template (maybe group them in a fieldset for convenience). Or do as @BitPoetwrote and move those fields to a FieldsetPage field instead. And only use repeater items for other entries that are all the same? Not what you've been asking for, but still an option.

@entschleunigung what if the 1st item is moved to another position? Should it still have the select option hidden? Or it should be unhidden as soon as it is not 1st anymore. If the latter is the case, it seems like there is no built-in solution (but you can inject your own js and still do it). But if you're looking for the former, there are probably some ways to implement it.

Good day, everyone! I am happy (and a bit scared) to announce the release of a long awaited new maintenance version for this module. @Mats blessed me to take control over the module. In fact, the repo is moved not to my github account, but rather to an org called Friends of ProcessWire in which there are some brilliant devs already, and maybe more will join. But that is a story for another post I am planning to write soon (a little intrigue))) As for now please test the new 3.0.4 version. It has some code merged from @ukyo (big thanks to him!) and a few lines by myself. I hope that this release does fix a few issues and hopefully not introduce new ones. But I can't be sure here, so changed the stability tag to Beta. Here is the changelog: Now the module uses https://nominatim.openstreetmap.org for all geocoding. Before it still used Google geocoding API in places. Fixed the issue with the map display in admin when the field is in the repeater or in the collapsed fieldset. There is still a problem with ajax tabs. Fixed ProcessWire namespace declaration. Fixed markup in README.txt. Executable bit is removed from all files in the repo. Git branches are renamed to be more familiar. The latest released code is now in the master branch again instead of PW3. The dev is used for current dev. Previously used branches are renamed and kept for now, though will be probably deleted in the future. Updated the module page in the modules directory.

Thanks, @bernhard! That was also the 1st thing that came to mind. But I need to cancel autoloading of 3rd party modules, I cannot modify. And I need to have this conditional disabling to happen in another module, not the one that is being disabled.

Good day! I am in the need to disable autoloading of a certain module on certain condition. I am looking for a way to do it via API probably in a hook. Please suggest how to do it or is it even possible.

Good day! Some inputfields/fieldtypes need to be saved before you can continue to work with them. Here are examples: In Combo PRO field one subfield can be used as a source of select options for another subfield. ImageMarker Fieldtype needs to be saved after the image is added before you can add markers. there are probably other cases (and surely a lot of plans to add new ones in my head))) That is not convenient for the end user. I would like to find a way to dynamically update the field in admin without the need for a page reload. The one thing to do this I could think of is using Page Autosave + Live Preview but it does save the whole page, which might be too much. And it is a paid module, so not for open source fields. And I would like to keep this in the fieldtype/inputfield module so no dependencies. My friends, do you have any solution and/or thoughts how this can/should be implemented? Maybe there should be some common mechanism for that in the corresponding base classes? P.S. I guess the reload should be made in such a way that hooks attached to field save could be avoided.

Sounds great already! But hope some more info is coming))

Hi, @gerritvanaaken. Thanks for checking it out. I've merged and added a bit to it. Made a little housekeeping also - renamed a few branches. You can download and test the dev branch. Please report back if you do so I feel more confident merging it into master.

@BrendonKoz, please create an issue on github if there is none yet. I will merge the mentioned pull request later this week. I know about it as I did my best to engage @ukyoto work on it. I am sure he did a great job!

https://processwire.com/docs/selectors/#sort

We are working to fix exactly these issues. But it is slower than I imagined) Hope to get all this fixed some time soon, as we do need it. The Address field use here is different comparing to FieldtypeMapMarker. It is for storing the object address returned by geocoder, not for storing address data you enter. That's why I think it is better to have another field to store the actual address, and Leaflet Map to only set and store a point on the map. Maybe we could find a way to connect them via js, but now it is impossible. By the way, storing address in a a separate field is better for ML environment anyway.

Hey, @Joss! It's amazing to se you back ?

Great! Hope it will be early December)

Good day @BitPoet! This module doesn't seem to work with latest FormBuilder. Are you planning to maintain it and fix issues? Maybe there is already a newer version, just not in the repo?

@Mats, would you allow someone to take it over? We need this and looking for a way to make it maintainable.

Good day! @Mats, are you still maintaining this module? I can see rather old issues in github unanswered, so decided to ask first before creating other ones))

That's quite an expressive post, @bernhard! I am actually a pretty slow driver. My Renault is no racing car, and that's because I never wanted to race) And when I need to go a long way (like, to the mountains), I actually try to take a train, so I can have some (root?) beer and yes, chips, along the way and not exhaust myself driving. So you're right - at least in describing me) To my defense, I can say that I actually did install your... car... in my remote testing... garage. And now I am testing how it is showing itself in a... no load situation. But you're right - I (we?) could go faster out of that garage to the mountains (I would rather go to the sea, but nevermind))) Getting rid of those comparisons... yes, I am kind of picky here, as migrations / versionable config is something that can easily break things. ProcessWire is a really author's project, so I am used to be inclined to choose 1st party solutions. But I've already read the source code and tested in a few different ways. Long things short - agreed, I need to get in you car and step on the gas))) Will do so and report back! Still this topic is about something similar, but a bit different than migrations - another way to store configs. So it interesting to me see how things go here. And, as always, Ryan's say on this is a big thing to me. And he still didn't answer in that issue).

Just a few days ago upvoted this github request. Everyone interested please do so too) I am quite interested in @bernhard's take on this (RockMigrations). But it doesn't work with RepeaterMatrix and other Pro fields, as far as I know. And this is essential to me. And just maybe a core functionality would be a better solution? Anyway, RockMigration is what we have now and I really appreciate @bernhard's effort on this. I still yet need to get my head fully around how it works though))

Great news! I've just installed the new Inputfield on a testing installation. It seems to work well. I've tried both standard and inline modes. Pwlink and pwimage are working, same classes are added for alignment as before. I can't see HTML Purifier. I guess content managers will be happy now inserting all the pink h1's everywhere they love so much) Is it planned or will this be abandoned? As @cb2004 said migration instructions from CKEditor are indeed needed. Hope they are planned. And I guess we should politely ask (beg?) the CKEditor-related module authors to create new versions for TinyMCE. I am talking about: @Robin S and his HannaCodeDialog, @FireWire and his Fluency Translation... Please, please))

I cannot say that I am stuggling... But those automatic things make me a bit nervous. I would much prefer to run those migrations manually. Another thing is I need to work in the environment where some changes to fields and templates are still made in the admin. And that red notification there is no way to deal with that,

Hey @teppo! I am running circles around this module for a long time. And last week did install it on a dev env for the 1st time. I am not quite sure how to integrate it in my workflow. And not sure my workflow fits it (not the other way around))) Please write back about your experience with RockMigrations if you progress with using it. Your opinion and feedback are a really valuable!