kongondo

Found this: https://itsfoss.com/windows-like-linux-distributions/ Chalet OS looks nice

Hi all, I'm looking for a quick suggestion on Linux OS. My genuine Windows 7 OS has suddenly decided to be 'not genuine'!!! I've wasted time Googling and tried all sorts of things but it has refused to even attempt to reactivate. I now have the black screen and the 'key's icon popping up every time telling me to 'click here' to activate windows. The 'click here' takes me to a 404 page on MS site!!! I tried a couple more things and now it is telling me my product key is blocked! Joy! So, I call MS and after going through a few hoops, the contact centre is just taking me round in circles! I haven't even spoken to a human yet! I'm pretty certain a recent Windows Update caused this but I can't be bothered to find out which one. So, I think it is time to say bye to my beloved Windows ?. I think most of the tools I use have Linux versions or alternatives. I'm not sure about my PowerDirector though. I've been down this road before and I always come back to Windows. I'm just looking for a distro that looks like Windows 7, to be honest. If it can run Visual Studio Code without issues (that's the priority) I'll take it. Any suggestions? I'm tired of Googling and would really like to get back to 'normal' ASAP. Thanks. PS: I'm not interested in a mac ?

?

Spot on!

Sorry, still doesn't work.

And it is really messing up the interface...I'll try and Google the issue when if I get a moment..

I wasn't clear. I meant customer addresses, emails etc should not be editable in the order. However, I now see your point about the need to edit an address, e.g. a customer entered the wrong details and phoned in to amend. If I get you correctly, as for order states, yes, we have that. I posted a few details in this post. Yes, manual order creation is already available. The API is finished. I'll post details soon, hopefully by tomorrow. I just need to finish testing a few other things first. So, manual order creation will be possible for whoever you want. You can take orders over the phone, at the POS, accept cash payments, invoices for goods delivered, etc. The interface is not ready but the API is. This means you can even use the API directly to create orders, not that you would want to do that if you have a GUI ?

I can confirm same warning on Win 7.

Yes, this will be the approach. I've edited my earlier post to be more clear.

Oops, thanks. Post edited.

Seeing the warning here as well. Tested on Win 10. Will try tomorrow on Win 7 but I don't think there will be a difference. Issue seems to be session_use_cookies, whether 0 or 1 and/or not ob_start() and ob_flush() at the very top and very end respectively...

I can't recall atm, but I tried Adminer in the past and something didn't work so I ditched it. Aha. Keenly watching this...?

Customers discussion: I've had a bit of a think and I think I'm probably complicating matters. With your input and a bit more thought, for now, I'll go with this approach: Registered customers are ProcessWire users. We'll give them some role to distinguish them from other users + they never see the backend. The will have a record of their details in User template (address etc). These records are editable, e.g. change of address, etc. Guest users will only have a presence in their respective orders, their records saved together with their order For registered users, their orders will reference their ProcessWire user ID as well. To satisfy legal requirements, their data (the minimum required) will also be saved with their orders. As was pointed out, if their ProcessWire user account gets deleted, we still have their data in respect of their orders The backend will have a dashboard/page for managing users, both registered and guest customers. For guest customers, the data shown will be what is in their orders. They will be clearly marked as guest customers. There will be a global shop setting to allow either both guest and registered customers or registered customers only or guest checkout only Shop owners will indicate what information they want collected from their customers. It will be their duty to inform customers why they need the information Registered customers will have frontend login and customised dashboards Orders will still be filterable - unpaid, abandoned, etc. Orders will have records of customers, both guest and registered customers. These records are permanent and un-editable (and decoupled from any other similar/identical records in the case of registered users) ONCE AN order has reached a finalised state. Before the finalised state, the order can be amended, e.g. an address was entered wrongly and needs editing, etc.. Order statuses and any changes made will be accompanied by chronological order notes (same as we currently have them). I hope I haven't forgotten anything...

No. An external table means I avoid creating pages for each customer. That is not going to be possible. Erasing users will not erase the order data. I am not using page fields or similar. The only thing that would happen in such a case is that a user id stored in a customer database would point to a non existing user ?

Great that you got it sorted ?. Your solution is a bit ironical though since you previously stated this: ...yet your example does not really do anything with the variables sent (except echo it back verbatim) ; Since you've posted this in the forums with the aim of helping other people who may not be well-versed with JavaScript and/or PHP, I feel inclined to point out two things, lest newbies pick up approaches that may not be best practice (some of which may potentially break their sites): ProcessWire has an $input->get() method (and related ones) which has some advantages over using PHP $_GET. There's two problems here: One, you are not sanitizing your $variable and secondly, you are echoing it back directly to the browser as received by the input. As I pointed out earlier, we have $sanitizer->entities() for such uses.

That's easy enough to implement. The only decision I was struggling with is how ?. My original idea (which I have now discarded given the feedback here) was to have customers as normal ProcessWire users. The advantage of that is that we would't need to have the same data stored in two different places; as ProcessWire Users and also as customer data in our Orders field. Using that approach, a simple customer id in Orders field would reference the user. Now we can do it the other way around, maybe incorporating this idea: We were always going to have a 'separate dashboard' for users/customers, albeit, referencing ProcessWire users with a certain role, like 'pad-customer' or similar. I'll write more about this later. Give the previous comments, we can instead have this dashboard backed by its own Field OR external DB table. We already have a Customers Fieldtype. It will just need some tweaking or conversion to a separate db table outside ProcesWire . We'll use the field to store customer data in relation to their orders or abandoned carts, making sure we fulfil our legal obligations (if required). The only tricky bit is if those customers decide to get registered. Maybe it's not a big deal. We'd let ProcessWire handle their normal user stuff, like login and permissions and we handle the rest, i.e. their shop related stuff. In this case though, the customer id (from customers table) will be different from their ProcessWire user id. However, the customer Field would reference the User's ProcessWire ID, so no big deal there. For unregistered customers, their ProcessWire ID would be 0. Alternatively, our order Field could store user/customer data directly but I'd rather have them as separate entities due to various advantages, e.g. being able to send newsletters to your customers, sending them promo/discount info, engaging most loyal customers, etc. Just thinking out loud here, at the very least to see if it makes sense to me when I read this again some hours later ?. Thoughts?

Then you are going to love the next progress update :-). ?

That's a tick then ?. It's already implemented ?!

Definitely. The plan is to build on and extend the powerful PW/Padloper API but also providing an easy to use and friendly interface with most useful functionalities for a shop within easy reach. Apart from promotion (we can think about that in the future), the rest of your list is tick, tick, tick, tick + more... It's a great project to work on, thanks! ?

Really? Does this ring a bell? ..... What about this one?

Thanks for the insight. I think I'll let Padloper take a passive role on this. Shop admins will decide what data they deem 'required' and what data is optional. Padloper will store what they want to be stored.

We've tried this previously. It didn't work great.

@arjen, Thanks for your input. So, for digital products, an email and names (first + last?) would suffice? For physical products, the least required should be a full address + full names and I think an email for order status updates, no? In both cases, this data has to be stored somewhere though. Only difference is an account is not created. Thanks.

OK, let's have a think.

Not sure yet. I want to balance ease-of-use/user-friendliness and flexibility. I wouldn't want shop admins bothering about roles/permissions, at least not directly. We could maybe prefix our roles and permissions with pad-. If ProcessWire allows it, then OK. I seem to recall such a discussion but I don't know what became of it. Thanks. We still have some time ?