Ivan Gretsky

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 🤩