Ivan Gretsky

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!

Good day, community! I have found another great opportunity to support PW ecosystem - just look here! This is @teppo's sponsorship page. He is doing such a load of super cool and useful things, that sponsoring him is a sure must))) Please start throwing your money at this fine gentleman)) Pitifully I cannot do it myself now easily, but I'll find a way. I almost feel guilty for not paying for Wireframe)) I've updated my other post with the modules' authors accepting donations list - just in case. You can check other great sponsorship chances there.

I guess we're going back to TinyMCE)))

Live Server Extension for VS Code + a browser extension for it are a tool to refresh any page in the browser when the watched code in VS Code changes. It can work with php-generated content - see here on how to set it up. Nothing unique to ProcessWire though.