alexm

@kongondo 👍🏼 keep well, cheers for the update

Just a note on this as I'm just playing around with this. For me, adding to admin.php in site/templates/admin.php doesn't work, however ready.php does as expected.

👍🏻 let's wait and see what he says. If it's going to be a while before it's released, we'll get it sorted!

@Spinbox Here's some screenshots to show the UI and roughly how far I got.

@Spinbox if @kongondo isn't going to have a release for that feature soon, I'll finish working on the module I was creating ASAP and share it. I was/am 80% there with it, but got sidetracked with a large project. But happy to set dive back in and get on it. I'll await his response though before I spend time needlessly 🙂

Not that I can recommend. I’d just be doing a google search and suggesting tools that I’ve not used to be straight up honest. Sorry!

I’ll be intrigued to see what someone more knowledgable than myself finds if and when. The only other thing I can think of is if you have a page that accepts url parameters, say for Ajax requests or something such and those values that get processed aren’t sanitised. But that’s all I’ve got.

What @wbmnfktr said

Interesting! And you’re certain it’s not your hosting that has in fact been compromised? Be it your login details to access cPanel or similar, or if you are on shared hosting that they’ve not managed to exploit a vulnerability on that side of things? You could ask your hosting provider if there is anything interesting in your access logs etc. Do you have forms on your website and if so, are they sanitising the data? Is there any old modules or JavaScript libraries? Is ProcessWire up to date? I’m no security expert, but these would the key areas I would be asking questions about that come to mind right off the bat.

I'm in a bit of a fork in the road with a foot in both camps with a situation for something I'm working on. I have an instance where I require perhaps one, or in some cases many different types of data to be store on a page which I would suit ProFields Table. Now... I started by using tables as this keeps fields to a minimum and also is ideal for the purpose, however, there might be an instance where on one page there may be 20 different types of items which more or less follow the same data structure. So with this logic, I then have to create a table field for each type of item so I can split them out and keep records of them easily. Now, the various item types could be in the hundreds+. So then the unique field for each type route becomes bad for scalability and performance. This is where I skipped the idea of using PageTable and having one ProFields Table field that handles all types, as I would still have to create a template for each item type if I want to clearly consolidate and store the different types separately on one page. So then I settled logically on using RepeaterMatrix as I can create the various types and use the same Table field for the various type but have lovely separation on one page for the various types of items that should be grouped together. To the best of my knowledge, this would be the best way in terms of keeping things maintainable and also would scale better in general. Even though I have to descend another level to grab the data when I need it, there are means and ways to optimise this, such as joining the data I need in queries or even having fields on the parent page that are updated/recalculated (at intervals via cron or when one of the items table row's data changes). This would likely be much faster for calculations and saving lots of selectors?? Now.... Herein lies the question. Is there any impact (putting aside having a super long list of item types to manage and look at) performance wise to having LOADS of item types as ReaperMatrix item types so I maintain the separation? This leads me to my last thought process, whereby I have one table field and add another column that is called category or type as the first column for instance and this stores the various item types. Then I end up with one field (though it won't be as some data structures are different enough that I think it wouldn't make sense to add loads of columns for those lesser common cases, as I'm just storing loads of empty columns then potentially) and potentially a couple of others for the edge cases where the data warrants a different Table field with the extra columns required. The thing I don't like about this though is that it offers less separation for easily querying just what you want as you have to iterate over potentially a very long table and get a certain type every time you need to get that data from various pages based on type and also it will have loads of different types recorded within it. Also it's worth mentioning that there may be thousands of child pages of a parent. The child pages being the page that will store the data for the various item types, which is why I want to try and find the happy medium between the most performant route vs the most structured, but with a strong inclination to lean towards it needing to be the best route for scalability performance wise. Your thoughts are greatly appreciated! Edit: I should add that I’ve read this thread: but although it appears to ask the same question, there is the intrinsic difference with the number of types of data being the key focus for me. Cheerrrrrs all!

Not sure if this is still a thing that people require, or this should really be posted here for security reasons, (if so, feel free to remove) but here's a solution that is tested and works. It relies on both instances using the same user salt. $usersArray = []; foreach($users as $user) { if($user->isSuperuser() || $user->name == 'guest') continue; // Skip the admin and guest user $roles = []; foreach ($user->roles as $role) { $roles[] = $role->name; } $usersArray[] = [ 'username' => $user->name, 'email' => $user->email, 'roles' => $roles, 'pass_hash' => $user->pass->hash, 'pass_salt' => $user->pass->salt, ]; } $usersJson = json_encode($usersArray); echo $usersJson; Then copy the output JSON array and then drop it in $json variable in the next part on the other end. $json = ''; $importUsers = json_decode($json, true); foreach ($importUsers as $iUser) { $userExists = $users->get("name={$iUser['username']},email={$iUser['email']}"); if ($userExists->id == 0) { echo "{$iUser['username']} should be added<br>"; $u = new User(); $u->name = $iUser['username']; $u->email = $iUser['email']; if (count($iUser['roles'])) { foreach ($iUser['roles'] as $role) { $u->addRole($role); } } $u->pass->hash = $iUser['pass_hash']; $u->pass->salt = $iUser['pass_salt']; $u->save(); echo "User: $u->name added successfully<br><br>"; } } Obvs add any other field data you want to export and import.

Long and short of this is thank you @kongondo for helping me to rectify the issue with my custom addon (which I will happily share) once done. It was due to me not correctly setting up the necessary methods and properties before installation, so one I knew that my custom addon's main class file was correct, per @kongondo's advice, I simply de-activated and re-activated the module and I am able to access the addone page and fieldname as expected. Big thank you as always dude!

@kongondo I did indeed. The first couple definitely ended up in the ether!! 😂👍🏻

@kongondo Hmmm, one still doth not follow. I'll private message with further deets I think. There is no rush or obligation to help if you are busy (which I know you are), but I think you'll see what I'm going for 🙃

Good evening @kongondo, just a quick one (hopefully). Sorry in advance, I'm not much cop with module development etc. I'm just wondering how I access the addon page and 'padloper_settings' field name from the TestAddon class. I note the setAddonPage() method in the custom addon docs but not sure/understanding entirely it's purpose or if this is used to retrieve them? But effectively I've created a method saveConfigurations() which gets passed the fields array and JSON encoded ready to save to the 'padloper_settings' field. Now I just need to figure accessing the page object and field name in the right manner rather than hard coding. Thank you in advance for any assistance as always.