FireWire

Great share. I thought I searched hard enough... but apparently not. Looks like some really bad decisions all over again. They removed all of the ModSecurity issues but now the admin just hangs and never gets a response from the server. I was able to upload an image, but the client re-contacted me and said there's another issue with images again so I'm back to looking into it again.

Hello all, Sharing some issues that I've had with Dreamhost that I've seen over the last week for ProcessWire sites. This doesn't seem to be caused by ProcessWire itself or it's code. Wanted to let others know in case anyone has sites currently hosted with them. I have several sites on a VPS through Dreamhost (both PW and non-PW). I've been overall happy and have had very few problems over the ~10 years I've used them. Their support team has been great and they are currently working on the issues. Recently it appears that some server config changes made by their admins broke image uploads within ProcessWire. Uploads fail with the UI continually showing the upload spin animation over the image. I initially contacted support regarding one of my client's sites after they told me they were having issues. I then tested this on a different ProcessWire site hosted on the same VPS to check that this wasn't a code issue specific to that one site and it appears that this may affect multiple ProcessWire sites (maybe just on my VPS, not sure yet). The server would return HTTP 418 (cute) and the upload would fail. All other functionality appears to be unaffected. After testing the second site I thought to throw it out here on the forums to see if anyone else hosts PW sites on Dreamhost and have been experiencing this, or give a heads up to people who may want to check on their sites.

...I thought I knew what love felt like...

I want to give a shoutout to the work that @bernhard is doing with his page builder- and all his modules really. He took the time to share the progress he's made on RockPageBuilder. It really does nullify so many issues that I shared above in my 9 WP examples above. Once again, the quality coming out of the PW community continues to take things that exist on other platforms and do them the right way, just like PW itself. Outstanding work! It's a module, so I'm going to count this as PHP related 😁

These videos are fantastic. Very enjoyable and always make me excited for the new things we have to work with!

At the request of @kongondo, I threw together a dive into my business approach. It's long because I talk too much, but maybe someone will find it useful! The Business of Web Development

I posted a (rather lengthy) comment about some of the ways I work with my clients. I'll be posting some of that here where reading it in context can help the message as a whole. I've been a web designer/developer for ~15 years in many capacities like freelancing, in-house employee, and now at my own one-person company (I'll get into why that's different than freelancing). I've been the new guy on the bottom rung of the ladder, and a director at an ad agency. I don't think that I'm special or that I have it all figured out! I feel this comes from a culmination of experience, long hours, mistakes, and trying my best. I'll group some topics together and give some briefs on each: on being a web professional, building value/client relations, and yeah things don't always go well. Building skills in these areas may help boost performance in things like getting clients on board with ProcessWire, differentiating yourself from other web services, being confident in what you charge, and building both a great reputation and long-term relationships. Get on the bus, we're leaving our comfort zones. Here comes the disclaimer. How and where you work matters. The market you operate in matters, competition, local economy, etc. That's why I'm not going to say "here's how to come up with what you should charge" or "this one neat trick will change the game". These are my experiences, I think some of what I share will be things you can implement yourself, some may inspire you to think of something different, and other stuff might just be rubbish. I also think that knowledge unshared is knowledge lost- so please share your critiques, experiences, and suggestions below. Your opinion and experience matters! Onward! Note- my language will tend to lean towards freelancers and individual operators but if you're a formal employee this all 100% applies to you as well. Take a moment to envision the company you work for as your client. It becomes relevant very quickly. On being a web professional Being a web dev isn't easy. Taking anything you love (going to make an assumption there) and doing it professionally means doing what you like and slapping on a bunch of stuff you don't to make it work. It also means you need to up your game in places that involve things that "orbit" web development. It is always a good idea to break focus and bring in new skills that complement and increase your expertise. This is necessary so you can be more than a really good developer- you can become an expert. An expert professional proactively learns as much as possible, they can speak with authority in many areas related to their work through verifiable fact and with consideration for others and their needs. A professional works to be good at what they do but also has skills in multiple areas that allow them to do that. It means the difference between building a website and building an effective website. A professional values: Being a clear communicator. Always #1. Being an educator Being a solution Being a student Some of those seem obvious, so let's unpack 'em. Being a clear communicator means more than speaking well. It means conveying your ideas in a way that others can understand and appreciate. It also means working to understand others because that will affect what you say next. Communication requires translating your technical knowledge into layman's terms and rather than stop at stating a fact or good idea, following up with why. This helps others value things as much as you do and shows respect for others in that you believe that they deserve to know. You are a translator you modify your attitude and approach based on how other people are engaging you by being aware and paying attention. Being an educator means bringing others in on your knowledge. Education helps avoid arguments and shows that other people deserve to know more about what you do. I told a client the other day that there are a lot of people who do technical work that don't take the time to educate those around them, that means what you're doing is just a black box of mystery to them. How can they value what you do if they don't understand it? People have become comfortable with "well I'm not smart enough to do that" or "that's too complex for me", I start with the idea that everyone is capable and it is up to them to find their limits. We aren't teaching them how to program, but we should let other people in on things they might care about. This has to be done in a way that the person you are talking to feels like they are being elevated and not become embarrassed or have feelings that they are ignorant for not knowing something. Example: A client in a meeting started reviewing the mockup and picking it apart. "I don't like the color of that button, and why is it located there? Maybe we should move X above Y. I want the form over here not at the bottom." I addressed each of their concerns. I explained that the button is located there because we know from studying user behavior that it is more likely that people will engage. The color of the button is also a UI strategy, if you look across the entire site you'll see that buttons that do something we want them to do are the same color. The "Menu" button is the same color as the "Sign Up" button, we'll have encouraged interaction by normalizing the experience and by mentally associating that color with action. The background of the call to action form at the bottom of the page is the same color as the button- because it indicates an action that you should take. Being a solution means either providing the solution, or if it isn't possible, brainstorming an alternate option. My least favorite situation is the "yes or no" decision. I try to provide a "yes or yes", where we have two options that can address a concern- even if one isn't as good as the other, or isn't what someone had in mind- you have shown that you are here and ready to work on overcoming a challenge. That makes you and your client a team. A "yes or yes" situation means that you have "become the solution", because that's how people will think about what you bring to the table. This one is worth an example from an experience I just had the other day: The client puts together events and sells tickets online. It's a reasonably large event that means a lot of people buying tickets. A lot of people were buying at the last minute, tickets sell out, and people rushing to buy may need help under pressure, both mean unhappy customers. This means a big influx of customer service requests that are difficult to handle. So: "We are trying to think of a way of how to change the shopping cart system to fix this issue but not sure how." Yes/No - "We could work on that but it may be complex work and will be a challenge to solve the problem by the next ticket date. It's up to you whether that's worth it." Yes/Yes - "Yes it's certainly possible to work on the store, we could also consider having an email sign up form on the website and then send an email when tickets go on sale, then reminders so that it can make it easier on everyone to space out the purchases and prevent last minute pressure. I'm open to both, what do you think?" I worked on a Yes/Yes solution, and they felt a lot better, and they no longer have to worry about it. I also communicated and educated by pairing my suggestion with a clear "why it's a good idea", and then I invited their input after sharing. They're signing a retainer contract with me this week. Being a student seems obvious, but it means being an effective student. We learn how to code better and try new things but it's important to get out of your box. This allows you to be more of an authority on web overall and others will see that as something they can and should trust. It's easy to study what you like, but sometimes you gotta take the classes you don't like to graduate... Here are a few: Get to know how to design websites that work. Learn UI best practices, learn about what parts of web design actually drive conversions things like speed, the number of fields on a form, effective calls to action, the difference between a web developer and a web professional is knowing how to merge what you build with what it has to accomplish. I don't do SEO services, but I have taken a lot of time to study it and understand how my work can be the absolute best when it comes to future performance. It goes beyond semantic HTML. Be familiar with what Google ranks by, the things that matter, and understand what is more important than others. It will affect the structure of the site, it means you will be doing things like creating pages that you probably wouldn't think to. Be good at technicals! Sure you've got a good looking site, but have you truly taken time to study typography? Off the top of your head, do you know what the most effective width of paragraph text on a page leads to more reading by visitors? Do you know an effective length of copy? Learn human/web psychology. How do colors affect perception? What if animations aren't just for making things pretty and cool. etc. Read and study stuff from great people like Mike Monteiro's "Design is a Job" because it will open your eyes a lot to the work you should be doing to support the work you're already doing. Also go watch his video titled "F*ck you, pay me" (spoiler: bad words) Before every project I assume that web design changed and it's up to me to check in on the latest information. Google "web design best practices 2023" before designing, head over to Stitcher.io to check out the latest that PHP has to offer and great tips- using new features may save you time, make your code ready for the future, and keep from using something that will be deprecated (WHY IS MY SITE BROKEN? YOU JUST BUILT IT!). I'm serious. Every single project. I assume my knowledge is out of date in some way. Remember: being honest and saying "you know, I'm not sure but I'll research that and get back to you" or "I'm unfamiliar but that's not something I can't figure out" is a hallmark of a trustworthy professional. Do not be a snake oil salesman, do not lie to get the job, don't be a know-it-all. Learn to defer to others who have more experience than you, for me those are SEO specialists, SEM specialists, and sometimes graphic designers. This shows respect for the work others do and you may get some partners to work with in the future. I have SEO and SEM people I trust and can recommend at the drop of a hat. This also makes you a solution, because you have others ready to help you solve problems. If you get caught BSing your way through something, you won't get away with it. Eventually they'll find out and you won't work with them again. I know people who have dropped off the map because of their arrogance or inability to be humble, you know who gets the phone call for work? Me, not him- and some of the people I work with have known him longer. Building value/client relations If you've made it this far in this ridiculously long post, you'll guess why this section comes after being a web professional. Using communication, education, solutions, and a student are pretty much the only way you can build value. Building value validates your hourly rate, or the price for a project. Those skills create intangible value, "my web person is more expensive, but they're honest, open, and always works with me to get what we need done even when I'm not sure what to do." Be mindful that if you wish you could charge more, consider starting from the basics and build more value. Keep in mind that your clients have a job. They have a business to worry about, they probably need to go pick up their kids from school, payroll is due, and why are sales down this month?! Doing your best to make their experience working with you low stress and relieve them of extra work is invaluable. To build value and establish strong client relations you have to stop thinking like a developer and start thinking like a business- PLOT TWIST: not your business, your client's business. Your work needs to reflect that this is more than a website or web application, it's going to solve problems and be a net gain for their organization. You need to think as if you had an office down the hall, act as if their deadlines matter, through the way you work with clients they should feel like worrying about a website is off the table and they can get back to what their real job is. You know what matters to you? Their profits. What else matters? Their employees effectiveness, their customer satisfaction, etc. Your website/app may highly impact all of those things (and probably will). I had a manager tell me after a presentation for a new product page on a website "I was really impressed, you think like you own a business". Mission accomplished. My response? "I really appreciate the compliment, but it really is a culmination of the work you, me, and the rest of the team have done. I really appreciate you helping move the project forward." Most of the following about initial client meetings and writing a proposal is taken from my other comment so you can skip it if you've read it already. Building value starts from the first time you talk about a website. When we first meet I work to lead the conversation in a way that gets me as much information possible to do the best work I can, to let clients know that I'm here for the "big picture", and to get them to think about what their next website means for them and how much it's worth. In my initial meeting I type a lot of notes and I always discuss the following 7 topics: This may sound odd, but what does your business do? I've looked at your current website, but would like to hear that from you. (There's a chance they haven't updated their current website due to reasons we've talked about here, or that the content doesn't do a good enough job). What are your plans over the coming year? Do you plan on expanding to new locations? New products/services? (Not always, feel the client out to see if they're positioned for this- it also lets you think about whether you need to consider this for the site architecture/code) What do you want visitors to do when they get to your website? What does success look like? Filling a form? Calling? Getting them to your online shop? Visiting your location in-person? Stick around for ad revenue? Explain that websites are supposed to do things with purpose. Open up the conversation about how a website is not a brochure, it's a live business asset that establishes brand strength, is often first impression of a business, and because we just discussed what conversions look like in the previous question- a tool that works 24/7 on their behalf. What do you like about your current site? What don't you like about your current site? Is there something that you want your website to do now that it doesn't now? Get everyone in the room to think about how this isn't a replacement website, we're leveling-up here and it's time to get strategically creative. You'll see that all requires communication, education, solutions, and a being a student. After this, I talk about my values and what is important to me when working with clients. Think about the typical idea that "programmers are hard to work with" or "the IT guy is a jerk and is abrasive". We need to overcome that with new potential clients because it's safe to assume that they've had some not-great experiences. I talk with them about these things that matter most to me: Communication. Always #1. They already know that I've taking the time to communicate, now they know that it's my priority and it makes them realize how much we've been talking about them. This is another thing that I can almost guarantee has not been said to them. Ownership. Businesses/people should own their properties and assets. True ownership means being able to use and update it. If there are services along the way (like maybe Google Tag Manager) or a new hosting company then it should be an account their business owns and I'll guide them through any process to do so. If I were to be unavailable someday- you won't be stuck with a website that was dependent on me. Performance. Re-iterating the need to aim for conversions. Adhering to accessibility rules for legal and user friendliness reasons. Making the site 100% (like Google Lighthouse 100%) SEO ready when it comes time for a specialist to optimize. These questions almost never fail to get potential clients to go wide-open with you. Every single thing we have talked about has now built value and price follows value. This is where we end the first meeting and I tell them that I want to review my notes and put a proposal (I never call it a "quote") together for them and that we can meet/call next. This first meeting usually ends up taking 1-1.5 hours, an initial meeting I had last week took 2. My proposals run 2+ pages. The opening paragraph is the introduction to the project and the approach- if they said they want to expand then the website "will be built with your goals for expansion in mind". The next are bullet points that now re-iterate much of what we talked about in our initial meeting (the 7 questions). Next I talk about timing, to head off "how long will it take"- that this project is a collaboration where we depend on each other to get content, approve designs, consider the features that the website is going to have, etc. We're all in this together, and I am invested in this with them. You're now thinking about their concerns before their questions and you've worked to control that conversation. If I'm asked for more detail, I say that we will set timelines for each stage when we get started- so when design starts the timeline is X, when that is approved we set the next timeline, etc. Then comes the price but I close with the terms of payment. It's usually 40% to get started, 40% on design approval when we go to code, and 20% on launch. Now the client is looking at the price in terms of affordability over the coming X amount of time. Here's what this process has done: my language says "I'm an agency" not "a person who does websites". The client has probably talked to me more than they ever have to other web people. They've shared the good and bad, we have a relationship, and now you have absolutely everything you need to do your best work and they know that. They probably also haven't encountered someone who wants the website to achieve conversions. They now know me as an expert. When you establish relationships with clients consider these items: Don't talk about other clients too much unless you're building rapport and talking about wins before they sign a contract. After that it's like a husband talking to his wife about his girlfriend. You can break this rule if you're talking about a success they've had that you want this client to have and correlate- because you're making it about the client you're talking to. Don't let a client feel like you're too busy or rushed. If an existing or past client needs help with something and it's small- consider what's worth more to you: the money you can bill, or the value of a client relationship. Only consider this if it's small and you can afford it- there is never anything wrong with billing a client. Be selective of who you do this with, don't do it often. Don't create a pattern and expectations. If you do this, be explicitly clear in an email (document it) with something like "I took care of that issue. This on is on the house so we'll skip the bill on this one. Let me know if you need anything else!" Make sure these are small, it makes a client feel like you aren't nickle and diming them. Do not overdo this. Don't do this to win over a bad client. Keep it for your best customers. Yeah, things don't always go well If you're still reading this ridiculously long post... Sh!t happens. You miss a deadline, you got a flat tire, your dog ate your homework. You misconfigured someones DNS and took their site down. Whatever. I would argue that if something goes wrong it's almost always the best opportunity to show how good you are. The only thing that people remember more than a problem is how you handled it. Be honest about it, admit fault, own it. If it was due to an error on someone else's part, I generally try to stay tame on blame and explain what went wrong rather than who did it- unless it was a) something egregious, or b) the person that did web work for them previously. You're not trying to dunk on them (be diplomatic) but you are there to solve problems and making sure they understand why you're now working with them and the other person isn't can be positive. Did a potential client reject your proposal (surely you aren't calling them quotes, right?) Try to negotiate if you're in a position to do it. If you've built value and it really does come down to cost, then look to have the value you've built help in negotiating. Etc. Random stuff I don't send invoices, my billing platform does. Built in document emailing, automated reminders for late clients, time tracking, reporting, expense tracking, customer portals, online payments through Stripe (and others), customizable branding, etc. If you don't have one, check out InvoiceNinja. It's open-source, built on Laravel, has an API, and you know how to put stuff on a web server, right? 😎 Create a subdomain like billing.yourdomain.com and it's pretty much ready to go. An update email describing less progress on a project than a client may want to hear is better than saying the same thing after they had to ask because they haven't heard from you. Keep communication open and going, let them know that you are thinking about them. Consider offering web hosting to clients when you feel like it's a good fit. Easy and inexpensive, I use StatusCake to monitor all the sites I host so I know if anything goes wrong. So my hosting is "private, exclusively for my clients, and monitored 24/7" Spin up a VPS at a reputable place. For managed hosting I use Dreamhost, for unmanaged Digital Ocean. I have a Dreamhost VPS and a separate managed MySQL DB VPS It's not really an "income source", you don't have to charge much, but it pays for all of my hosting and domain fees (including for my billing platform). They're happy, I'm happy. Very convenient to work on client sites when you don't have to juggle passwords for GoDaddy or some service they've set up. Should you be a company or a freelancer? Up to you. Historically I was a freelancer, then this year I formed an LLC. You don't have to do it but there are benefits Professional image, taxes, a more formal business interaction, legal protections Shows my clients that I'm as serious about what I do for my clients as they are. Consider creating a "marketing deck" Agencies create these to display their services and offerings. They're usually tailored to a specific client, but having a general one to provide people I'm interested in working with is a great professional document. Make it look nice, you don't have to print it, just create a PDF to have and mail. What else can you do? Can you offer more services beyond websites? I provide "web services", so design/build new websites, update/maintain/optimize existing websites Offer building integrations between platforms, provide CRM work where needed if possible Analyze business practices to help optimize workflows Research and provide recommendations for software that solves problems Help manage existing platforms, and train others to use them Think about how a developer gives you the tools for analysis, problem solving, and fast learning. You may learn software faster than other people- I've offered to learn software and then teach it to people who already use it. Think about what you can do that solves a problem while at the same time lowering the bandwidth for employees at a company. This went on waaaaay longer than I thought it would but I just shared whatever came to mind. If you are interested in seeing the deck I put together for my services (and have a reputable account with a history here in the forums) PM me. I don't want to share it in the open since it contains PII. If you found any of this useful, shout out to @kongondo for encouraging me to share. Would love to hear everyone's thoughts, critiques, and suggestions! As always, I am 100% open to being wrong about things that someone else could help me be right about.

This is the de-facto method of increasing our profiles as developers. Wide open communication- especially up front. Set expectations. You can make some pretty safe assumptions that people who have gone through the website process before and have experienced frustration due to lack of communication or transparency. Even just making that statement to protect yourself shows a client that you're engaged. I'm going to take an opportunity to outline my process to fight against this. I'm certainly not trying to say you or anyone else here is doing anything wrong. There are so many factors to take into consideration- including your local market, the businesses available in the area, the number of competitors, etc. I do not advocate for taking what I do as cookie-cutter advice. I'm not going to tout myself as a biz-wiz, but I've learned from freelancing, ad agency work, and being an in-house developer (when I'm in-house, I treat the company I work for as my client) it's about proving to clients that my first concern before fingers-to-keyboard is their business and their success. This is how I go full plan-of-attack against the "1.500€ crowd" because after your first meeting a potential client should be left feeling "whoa- those people who want to sell me a discount website seem like they are a bunch of parcel carriers". My intention is to make every discount chop shop (regardless of CMS) feel like they're slapping out half-assed sites to cash a check- because they are. My first client meeting always covers these points, and never over email. I take notes like a fiend, I want them to know that everything we do next (and the price) is completely dependent on their wants and needs- this is also not a "gimmick", they're giving me my marching orders. This may sound odd, but what does your business do? I've looked at your current website, but would like to hear that from you. (There's a chance they haven't updated their current website due to reasons we've talked about here, or that the content doesn't do a good enough job). What are your plans over the coming year? Do you plan on expanding to new locations? New products/services? (Not always, feel the client out to see if they're positioned for this- it also lets you think about whether you need to consider this for the site architecture/code) What do you want visitors to do when they get to your website? What does success look like? Filling a form? Calling? Getting them to your online shop? Visiting your location in-person? Stick around for ad revenue? Explain that websites are supposed to do things with purpose. Open up the conversation about how a website is not a brochure, it's a live business asset that establishes brand strength, is often first impression of a business, and because we just discussed what conversions look like in the previous question- a tool that works 24/7 on their behalf. What do you like about your current site? What don't you like about your current site? Is there something that you want your website to do now that it doesn't now? Get everyone in the room to think about how this isn't a replacement website, we're leveling-up here and it's time to get strategically creative. Then I talk about the things that are important to me when working with clients. Communication. Always #1. They already know that I've taking the time to communicate, now they know that it's my priority and it makes them realize how much we've been talking about them. This is another thing that I can almost guarantee has not been said to them. Ownership. Businesses/people should own their properties and assets. True ownership means being able to use and update it. If there are services along the way (like maybe Google Tag Manager) or a new hosting company then it should be an account their business owns and I'll guide them through any process to do so. If I were to be unavailable someday- you won't be stuck with a website that was dependent on me. Performance. Re-iterating the need to aim for conversions. Adhering to accessibility rules for legal and user friendliness reasons. Making the site 100% (like Google Lighthouse 100%) SEO ready when it comes time for a specialist to optimize. These questions almost never fail to get potential clients to go wide-open with you. Every single thing we have talked about has now built value and price follows value. This is where we end the first meeting and I tell them that I want to review my notes and put a proposal (I never call it a "quote") together for them and that we can meet/call next. This first meeting usually ends up taking 1-1.5 hours, an initial meeting I had last week took 2. My proposals run 2+ pages. The opening paragraph is the introduction to the project and the approach- if they said they want to expand then the website "will be built with your goals for expansion in mind". The next are bullet points that now re-iterate much of what we talked about in our initial meeting (the 7 questions). Next I talk about timing, to head off "how long will it take"- that this project is a collaboration where we depend on each other to get content, approve designs, consider the features that the website is going to have, etc. We're all in this together, and I am invested in this with them. You're now thinking about their concerns before their questions and you've worked to control that conversation. If I'm asked for more detail, I say that we will set timelines for each stage when we get started- so when design starts the timeline is X, when that is approved we set the next timeline, etc. Then comes the price but I close with the terms of payment. It's usually 40% to get started, 40% on design approval when we go to code, and 20% on launch. Now the client is looking at the price in terms of affordability over the coming X amount of time. Here's what this process has done: my language says "I'm an agency" not "a person who does websites". The client has probably talked to me more than they ever have to other web people. They've shared the good and bad, we have a relationship, and now you have absolutely everything you need to do your best work and they know that. They probably also haven't encountered someone who wants the website to achieve conversions. They now know me as an expert. This has been pretty successful for me over the years. I also have a reputation for engaging and caring about clients- the biggest thing is that people trust me. Right now all of my work is referral/relationship based. I really want to help people out there who struggle with pricing and the "doing business" aspect of the process. If anyone reads this and some of it seemed out of reach- I encourage everyone homework and learn on how to speak to these points confidently. Learn UI best practices, learn about what parts of web design actually drive conversions (things like speed, the number of fields on a form, effective calls to action), if anyone is interested I'd be happy to start another thread and share what I have learned and implemented over 15 years of business-oriented web development via ad agencies, freelancing, in-house developer, and now my own company. Now, go find me a WordPress developer that slaps together a plugin site and remotely does any of this. Time for hard numbers! This is a CRM report of the number of sales leads generated by the website at a former company I worked for (employee). They are now generating the number of sales leads year round as they are in the worst weeks of the year- even worse, the number of leads should have been trending up as the summer months are the strongest sales season. To understand the impact here- the product they sell costs $40,000+ so they are dumping opportunities (and the money that comes with them) back into the market- effectively destroying their revenue. And guess who is a client of mine now... (that's right) a competitor. The leads before that purple line? ProcessWire 😎 I very much can identify with that sentiment. It's difficult to overcome and not always possible. I went into more detail about my process above because I try to head off so much of what may happen like this- and I don't always win- so I really don't want to pull a "HEY EVERYONE I SOLVED THE PROBLEM!!!" on this haha. I really try to communicate that if I've done my job well then the amount of work they should do shouldn't require that level of customization on their part- BUT you may not be able to win over those that demand it anyway. I can say confidently though that if they want a business driving site, then they should go study UI and UX and become a damn web designer. That's another thing WordPress has done- made people think that web design is easy and made people absolutely ignorant on how their ideas have consequences. From a business point of view, I would be bold enough to say it's outright risky. We all know that good web design is hard, clients should feel the same way- it should make them actually feel uncomfortable doing what page designers let them do. I want them to feel like anything beyond what a RepeaterMatrix field can do may not be a good thing. I want my clients to know that they hired me to do everything in my power as an expert on their behalf. If I walk into a bakery I don't start telling the chef how to bake his bread. My entire approach is not to scare people, it's to educate them. When I show them a web design for approval and someone says "well I don't think the button should be there" or "maybe this should be a different color" we then talk about how xyz actually changes people's behavior, that every component of their site design was placed with intention. My design is intentional, their ideas are opinions. If you feel that your opinions outrank the experience you're hiring me for- there's a $1500 parcel carrier down the street who loves letting you do his job for him. This is why I've never had to show a client more than one design. Sure, there may be tweaks, but by the time we get there we have buy-in from everyone at the table and there's confidence that we've worked together to make the most kick-ass thing possible. I stress the word "collaboration" at all possible points in client relations. I've got my native screenshot tool on Linux ;) I didn't think of a video, good idea! Big thanks for the info @wbmnfktr & @bernhard. This thread has some fantastic stuff going on here. Also I wasn't trying to say that you don't know how to "do web business" but I wanted to share my process out in the open for others to see. So, not a direct critique or aimed at you. I need to check this out to have it in my repertoire. I heard of it but as you can guess didn't make it a priority haha.

So I made a flippant remark about WordPress vs. ProcessWire yesterday, but I'll elaborate here because it's very true. These are just 9 instances where I've helped with WP sites. Different sites, different end clients. All happened within the last 12 months. 1. I have a friend in digital marketing who I contract with sometimes. A client's WP page builder causes her problems with its complexity. Users shouldn't have to worry about things like padding, margin, responsive columns, a visual editor that switches between preview screen sizes, etc. She's asked for my help multiple times because some very front-end CSS properties just have a UI slapped on them but that doesn't make the user a web designer. Felt like using 2005 Dreamweaver in 2023. 2. The same friend manages a different client WP site wanted to create an accordion for content- the markup-esque plug-in text she had to enter wasn't working. So I had to log in and check her code and fixed it for her- there was a symbol that somehow got entered (no idea how, very obscure) that looked like another regular letter or symbol that broke it. She never would have figured it out and not her fault. Not even sure how she would find that off-keyboard symbol. Someone could say "well it was her fault because she screwed up the code", I say why is someone using code-like text in an editor to generate an accordion to begin with? 3. The same friend manages yet another WP site that completely went down due to core and plugin updates- probably the wrong order between the two. I had to log into the host, roll back both the code and the database. It worked until the next day when automated updates just broke it again. They gave up and had another WP site built. Stuck with WP because they "know it" but effectively in practice not really and it's because of the wild variations between plugins and the lottery back-end quality. Also, rolling back to an earlier version just blows the WP vulnerability door wide open, so then you're back to doing emergency dev work on a site that never should have gone down. Since every WP site is different it's now time to enter the "which one of y'all plugins just took this site down?!" jungle. 4. I had a different WP site passed to me by another person I work with where I had to fix a WP plugin and write new code outside of the plugins directory to get it to work. At some point something started blocking execution of some code in the plugins directory. There was no way to fix this without a workaround. Users really don't care how the problem happens or why, and I only saw that their WP site broke. It was for an animal shelter and that plugin listed the animals available for adoption, so again because that's core to the operation of their organization- it's an emergency request. 5. After I had fixed their plugin, the client fires back at me angry because "now we can't update the home page slider!!!". They accused me of breaking it. I think everyone here will agree that modifying a plugin to list animals on interior pages has absolutely nothing to do with a home page slider plugin, or me. I log in and learn how to use this slider plugin where you create it in a completely different location in the admin and then shortcode it into the page. The plugin technically worked but the process was so complex that they forgot how to do it. I went through the process, screenshot the steps, and designed a step-by-step PDF with notes to walk them through the process. This sounds easy but clicking through WP, taking screenshots, photoshopping/writing out instructions, and creating a PDF takes more time than you'd think- but there's no way in hell I could write them an email describing it. I emailed it to them with my invoice. 6. That same person passed yet another problem to me on a different website. Couldn't get the page to update. There was caching involved in two different places, one was in the plugin area of the admin, and another one was in WP bar at the top. Neither of them cleared on page save so the page on the site would just not update. The admin was also really really slow. Editing a page was massive work as plugins loaded and made a ton of AJAX calls just to get parts of the UI visible. You could blame the dev but WordPress has promulgated itself so far into the world and deceptively been marketed as "easy", but it really isn't. 7. My partner is a digital marketing manager for a company, they use a different page builder which after a while got used to using with my help. It was much easier for the dev they hired to push out the website, but a pain to manage. I've had to edit CSS and HTML to fix pages (in the plugin and in the page editor) which is a massive no-no for end clients. What is the value of a CMS that stymies users and my partner only got fixed quickly because I do a webz? 8. Another project with my partner- I don't have the bandwidth to build a site for one of our friends casual softball team, so I created a WP install with a different page builder at their request, then came more problems figuring out why "blocks" weren't working as expected. What I had to do just to get a full width hero image was frustrating. We don't have to go into the other plugin issues. 9. A different WP site had a plugin reg key issue (previous dev may have reused it). This shut down all the forms on their site which were critical, so they decided just to just spend the $30 for a new key. I sat on the phone with this person through the process and they were concerned that if they enter the key the plugin will reset and they'll lose all of their forms. Why should any end user worry about plugins/registration keys and data loss?. I communicated well, and listened to his concerns, everything came out alright. Next day had a meeting with him, the organization president, and a board member want to work with me now. I'm writing a proposal for a very nice monthly retainer contract this weekend and they want to get started next week. Shout out to WP for the boost 🙏 (They have also said that they are in no way married to WP, surprised?) All of these people spent hours before calling me because it can't be that hard, right? WP makes them feel dumb. I billed for each of these and it's part of my income (except my partner...). I'm in a client meeting 2 weeks ago talking about a new site. Someone mentioned WP and before I said anything, 2 people talked about how "every WP site I log into is different and difficult to use". They are currently on a PW site which they've outgrown- but they never felt "this CMS is bad". I adjusted some fields and they're happy. Did it require a dev? Sure did. But they've been using a site that I built back in 2017. I've only really upgraded PW core to keep up with PHP version changes. Not once did a module break. That's when I said in that meeting "I love WordPress, I make a lot of money off of it". Also, none of these websites were fixed by the people that built them. I have a reputation for solving problems and they may be cultivating an image that they create them. I also had a meeting with a bona-fide marketing company to possibly do contract work. I suggested PW and that it doesn't have the problems WP does- the owner of the company said "yeah, but that's something we make money on". Lost an opportunity to do business because profits are baked into the product's problems. So at what point do we acknowledge that there's a difference between saving time in our work and offloading it onto our clients? I use PW to define the client experience. No layout builder, they just enter content and it works and looks like it's supposed to. The sites look nicer longer because non-devs don't design a layout for new pages. We plan ahead for what pages they'll need and occasionally I'll make a "custom template" using a RepeaterMatrix field- but it still ends up fitting the design. Custom sections, no layout builder- 100% satisfaction. The training time to use a PW site is around 15 minutes with "wow, that was a lot easier than I expected". Does it take a little extra dev time on my end? Sure, but I've gotten faster. I have boilerplate Sass that I use to speed things up, and it's easy to reuse blocks of other code between projects. A PW win that I didn't need to split off to a new site or app stack. I used URL hooks to create a basic API on a PW site that my Salesforce Apex components called to sync in-person events for an iPad web app that consultants used to send leads back to Salesforce. That was a faster task thanks to the ProcessWire API, and it let the team and I get strategically creative on how to drive business performance. I credit ProcessWire for having been a revenue driving component. Full stop. $20m -> $70m in 5 years- nonlinear increases, much of that came from pushing the website, digital marketing, and rapid post-launch feature development. The numbers didn't lie. It's also because I designed a website UI optimized for conversions that people who handled content couldn't screw up. All that isn't for every website/client, BUT when I meet with all clients I ask them "what are your business goals and how can your website help achieve them?". I wouldn't have the confidence to ask that with WP. I'm not dragging WP devs or people who choose it, I'm sure there are places where it makes sense. I also recognize devs who take the time to make the experience better regardless of platform (I imagine like @zx80 above). Kudos. It's not just about choosing the right WP plugins or something though. There are non-tangible issues as well, how many people/businesses don't update their site as often as they should because it's difficult? Downtime? Off-hours emergencies? Those are all business strategy and revenue issues. People want to save time and money up front- and please do, they'll eventually pay me and it buys concert tickets and Friday date nights or whatever. Ironically, one of the 9 examples above happened while I was writing this comment. I'm not even lying.

Them: "So what about using WordPress for the website" Me: "WordPress is great, I make a lot of money helping people who own WordPress sites use it."

Thanks to @teppo for the ProcessWire Weekly shoutout! I wanted to share some updates to show I haven't been a lazyass some more detail and information since my last update post. Caching is optional and can be cleared. Translations are persisted for 1 month which helps even out month-to-month API usage, but also expires so if DeepL improves their translation then you still get the latest and greatest. I haven't formally timed it but cached translations feel near instantaneous. Modified content? If the content of a field has changed since the page edit screen was loaded- then the tab text is italicized and an accent is added. This tracks changes whether you typed the text, or if you used the translator to change the content. It's stateful so if you return the content to the original value, the accent is removed to indicate that the content has not changed. Oh, and this is tracked independently for each field, and separately for each language. So it is now much easier to see if there are fields that weren't translated. Heck, it even helps users make sure they didn't miss anything anywhere before they hit Save. Table fields are now supported. I forgot to mention that before. Fluency has been tested with all ProFields and is 100% compatible. TinyMCE is ready to go and, as promised, CKEditor regular and inline are also supported Error handling! Fluency is aware of all errors that are possible to be received back from DeepL. It's also smart enough to know if the DeepL service is unavailable or if you lost connection to ProcessWire (what wifi?). This helps make it very clear where the error happened, which may save you some headaches during development (and maybe emails from your clients/users later). In my case DeepL rejects requests when I'm on a VPN even if my internet is workin' alright. Localization is here. Every single aspect of Fluency is translatable using one central file in the admin language configuration. That's it. No chasing different files in the module to translate things. English is the default language in these pics, but it also shows the proper language if your default isn't. Achtung! Even the errors speak your language. I got you, international friends. For the nerds... One field, one file, full documentation. Each field adheres to standardized public interface methods so they are modular and completely independent of the rest of the codebase. If the old code was structured like this TinyMCE would have been ready the day after it was announced by Ryan. Not every inputfield needs its own module because some fields just use others- a repeater containing a textarea still just counts as a textarea. Less module updates, more translating! All of these are core Fluency features. I'm prioritizing this over any work on a Pro module to get this out for testing and into everyone's hands sooner. Still work to be done, already 3x more code than the last version, but we're bringing the 🔥 More updates to come!

So, I wasn't ripping on JS. I was expressing frustration that I think a lot of people have about the ecosystem. I don't use jQuery but I used it as an example of bloat growth. My point really is the JS-ification of everything and how that mentality has caused a high-intensity recursion of problems stemming from forcing a language written for the browser into a server. I remember when it was first announced that someone was got the V8 engine to run in a server environment and the first thing I thought was "well, that sounds like a box of headaches". The main point was to throw some extra things in about the point that the first video makes: traditional server side programming languages and their frameworks (like Laravel) are not only very capable, they're enjoyable to use. They're also incredibly stable and PHP overall is so much easier to work and upgrade over time. That's not a JavaScript problem, it's not a PHP problem, that's an entire internet problem ha! Angular is a front end framework. It's also a big example of a framework with a rough history of development. Used to introduce a ton of breaking changes regularly and went through a complete rewrite. It wasn't a great developer experience. I was learning it years ago, I watched a presentation by Google where they made a list of all of the breaking changes that would be happening in several months without a major release version. This was after they split it off from AngularJS. I walked away from it. This is a great example of great JavaScript and what a focused UI library can be. I was mainly using React as a punching bag because the video above it was talking about server side components for React. I'm not anti-JS! I mean, yes, but there are a small number of people that have to worry about speed at a scale that it would matter. Tons of applications and websites of all sizes run on "slow" languages and environments like PHP and Ruby, but in the real world the end user isn't going to notice unless something is really really wrong with the code or the server. Where NodeJS is really useful is handling Socket connections. It's really the only choice. I've played around with a tiny SocketIO server I built to it's pretty great. That said, I'm not changing my entire server environment just to implement that. I'm building an application that revolves around timers and control messages between clients and there are services that do this better than managing your own code/server, especially when geolocation is concerned. At that point network latency is a bigger issue. PHP8's JIT compiling will continue to push speed. Is it going to match Node? Nope. Am I worried about it? Nah. Should anyone reading this right now? I'd love to see what you're working on if you are... That was hilarious, but the story behind it also says a lot about the state of package management in JS. NPM was a massive jerk. Yes! I'm using InertiaJS with Laravel and Vue. The reason I chose Vue was pretty much just because it's very commonly paired with Laravel so it's good skill experience. Inertia is really great and simplifies a ton of stuff out of the box. Like I said- having a great server side application and a solid JS front-end is where it's at.

I'll go ahead and invite myself to share some JS thoughts nobody asked for... The don't-reinvent-the-wheel message in the "Do not use React Server Components" video is good, but I think there's a lot more to it when it comes to full stack JS overall. Not only are JS devs largely solving problems that have already be solved, the JS ecosystem is constantly solving problems that it causes for itself. Obviously new features can cause issues to address- but it feels like JS really takes the cake on this one. Hydration and rendering issues were pretty much inevitable when you start overloading the front end and forcing the browser to do so much heavy lifting. Wait... sending a blank page that waits for JavaScript murdered your SEO?! Rendering pages on the server is relatively simple, rendering them in the browser- boy howdy... So then the JS devs cheered when it invented server side rendering... for JavaScript. Then there's the bundle sizes, which is noted in this article about React Server Components: So now they're solving for asset sizes, another layer of complexity to solve an issue that didn't exist (at the level it does now) until massive front end frameworks caused them. We used to worry (showing my age here) about jQuery library sizes... React is excited about saving 240k while the entire jQuery library is 85.4k (uncompressed), and all you have to do is redesign your app architecture with server side JS! BRILLIANT! Before someone interjects to correct me, I'm not saying that React and jQuery are the same, or comparable in functionality and purpose. I am saying that the JavaScript-first approach allowed a lot of people to accept compromises to create the Next Hot Thing™ and a lot of problems with it. JavaScript on the server pretty much just made this more complex by providing increasingly complex ways to make itself more complex- lol, recursion. "But", the full stack JS dev will say, "you can use the same language everywhere so there's consistency." My brother in Christ, you don't even import code between files the same way in Node and and client side ES6. So when I read this in that video: This is from a developer who goes to bed at night thinking about how their Next.js application codebase might be outdated by the time it launches. Then I go back to feeling like this: I used to kind of stress about not pursuing full stack JS, then I realized that I'm happy. Having a front end (whether SSR or a JS framework) and a back end (CMF or non-js app framework) keeps me sane. I know where things go, what they do, and why. There's consistency between projects. It's easier to maintain best practices. My NPM headaches are smaller. My PHP doesn't need nodemon or pm2 to restart the server application if there's a JS error. The amount of documentation I read that has a big red box in the middle saying "Note: this thing that you've built several apps with and know well is going away. We're destroying it because someone on Github said we need to move to stateless functions. Soon there will be pain, and you will cry." is very limited. I made that one up, but you get the idea. I'm not dragging front-end JS frameworks per se, but making the case for why they should not pave the way to the JS-ification of all that is holy and aren't automatically better. Maybe putting JS everywhere has made SPA solutions worse because they didn't leverage how well traditional server side languages worked already. Went off on a tangent here, but I've had a few moments of zen this year about being a PHP developer and wanted to share the energy. All that aside, to answer your question @wbmnfktr I've wanted to pair up a front end framework with PW but haven't had the time or right project to give it a try with. I do like the idea of using PW as a JSON delivery backend in general.

I think that you make a good point about the frontend/backend crossover. Writing the same language everywhere introduces some comfort in mixing up what does what and where. Then there's the perception or need for performance, "how can we reduce API calls to make our application 'snappier'". There's an entire generation of developers that have only ever known full stack JS, massive front ends, and a browser-focused approach. Like the video above said "you're solving problems that were already solved". I think there's a great place for sane client side UI frameworks and server side frameworks. It does create a great opportunity for user experiences.

I'll share a bit of a sidenote on the language overall that I think may start to appeal to developers again who are giving PHP a try with or without a framework. PHP 8.0-8.2 has changed the way I write code significantly and features new and old like arrow functions, enums, union typed properties, nullsafe operators, named arguments, return type hinting, constructor property promotion, etc. are fantastic. Performance gains keep rolling in as well. I've enjoyed seeing the deprecations and cleanup in the language- even just committing to using typed properties and return type hinting make so much of a difference in how the language feels. I like the first video above where the person focuses on how enjoyable it can be and I'm always hesitant to give much weight to a JS developer who has some really outdated opinions. For example, these two sets of code do the exact same thing: I think that says a lot and the new features and style of the language are going to continue to boost frameworks as they adopt them as norms. Developers returning to PHP or trying for the first time are going to see something that feels really new. I've been building a Laravel/Vue application and InertiaJS feels like magic the way it marries the SPA front end with the back end. Really enjoyable.

The planning is 100% with an eye on the future. Thank you for the kind words and support!

I'm glad you asked this! This should be pretty much a drop in replacement. The only thing you'd have to do to upgrade to the new version would be setting the language associations again and transfer any settings (like global excluded strings and API key) in the module config. Upgrading later will not cause any loss of website content and the work for developers should be minimal. The new features are implemented behind the scenes, so you just get more cool stuff 😎. ProcessWire makes it possible to change editors between TinyMCE and CKEditor without re-creating the field, so using CKEditor editor now and then switching to TinyMCE later shouldn't cause any headaches. It really should be as easy of a transition as you can get with how well TinyMCE is concurrently being implemented (props to @ryan). As for the module, Fluency doesn't care what field/editor you use or if it's changed at any time because fieldtypes are detected and initialized by JS at runtime when the UI loads, not on the back end. So good news- I don't believe that there is anything that keeps you from using Fluency now and upgrading later. I've been working regularly on the module lately, my goal is this month or next. I think a wildcard will be testing but I'll be requesting help from the community here when it's time. I want this version to be the one that breaks out of alpha. Many thanks and I'll report back here when I have updates.

Hello all! I've compiled a list of features that Fluency will have on it's next release and currently under development. There are a lot of new features and, as mentioned, it's being completely rewritten. I want to share some notable features that I think will be some great additions. IMHO, I believe that this puts Fluency in a first-rate position to make ProcessWire easier and more powerful for multi-language sites compared to other CMS/CMF platforms. If you've tried to use translation modules/plug-ins for other platforms I think you'll agree. As you can imagine, the feature expansion makes the module very powerful but it also means a lot of extra work. There will be an upgraded version available named (unsurprisingly) FluencyPro. Before I get into that, my commitment is to make the non-pro version the real-deal when it comes to quality and features. No features will be taken away from the core Fluency module and moved to the premium module. As you'll see below, the majority of new features will be available in the Fluency core version. Every feature in FluencyPro is new and complements the Fluency module that is and will always be free. I also want to make the Pro version very reasonably priced so it can remain within reach for as many people as possible and an easy sell to clients. The price will help offset the time and effort it takes and the support is greatly appreciated. More details to follow on that later. I chose the new features based on feedback from the community as well as my usage for sites I've built. Here is a list of new features that are coming in the next version: Fluency (core) Continuity - All existing features will still be available Localization - All Fluency admin UI elements can be translated to all languages present in ProcessWire. Includes the translation trigger buttons on each field, the global translation tool in the menu, etc. Error Handling - Will indicate things like the DeepL service not being available, usage limit reached. All errors will be translatable. Improved Module Config - Cleaner and more organized module config screen Inline Fields - Support for inline fields TinyMCE - Support for the new rich text editor CKEditor - Continued support for CKEditor to keep the module backwards compatible with ProcessWire sites that don't/can't use TinyMCE Per-language change indication - When content is changed in a field, the corresponding language tab will indicate that the content has been changed. This makes it easy to see where content should be updated in other languages. Translation Caching - Translations will be cached so that additional requests for the same content will not require additional DeepL API calls. This can help keep monthly DeepL API usage lower where possible and make repeated translations lighting fast. Cache can be manually cleared in the module config screen Logging - Improved Remains free - Free forever and will be open-sourced FluencyPro Multi-Language - Translate any content to any language for a field. Multi-Language - Translate any content from any language for a field. One Click Translate All - Any language to every other language for a field. This makes using a wider array of languages trivial when editing pages Markup Companion Module - Optional FluencyMarkup module provides individual easy-to-use methods for markup output to the front-end. This makes Fluency a complete translation solution out of the box. Features: Render all languages as prebuilt `<a>` links to navigate between page languages. Render a self-contained prebuilt `<select>` element with one click switching between languages on the front end while needing no additional JS required in your code. Inline JS is optional for those who prefer to implement their own. Render all alternate language `<link rel="alternate" hreflang="{ISO code}" href="{alt language URL}">` `<head>` tags to indicate that the page has additional versions in other languages. Great for SEO and adhering to HTML standards. Output the current language ISO code. Useful for turning `<html>` into `<html lang={ISO code}>` in keeping with HTML best practices. All render methods are hookable for additional customization by developers Notable overall code improvements: Written using PHP 8.0 (required for use) JavaScript rewritten in ES6 to make use of newer language features, is transpiled to ES5 to maintain browser compatibility. Transpiling is pre-configured and included with the module. Modular per-inputfield JavaScript so that adding new field types and updating existing ones in the future is faster and easier. Standardized composition so interfacing with fields within code is uniform and predictable. Server-side module code is being rewritten with the future potential to add additional "translation engines". While there won't be additional services available now, there will be a more standardized interface to make adding others easier. Both versions of Fluency will have this feature and can benefit from new translation services other than DeepL. This won't be 100% ready on release, but it is being kept in mind now. Future translation engines will have access to a uniform interface to use the Fluency caching feature with no additional overhead during development. Improved RESTful style API within the admin which lets other modules or PW customizations implement separate translation features using AJAX requests Leverages ProcessWire's built in JavaScript config object (as opposed to a separate API request on page admin page load) to speed up UI initialization .prettierrc and .editorconfig files to make contributing easier Thanks everyone for your patience, really excited for the new features! Cheers!

Ryan has already responded to the Github issue and will merge the fix as soon as it can be confirmed. Passing along a PW API method call he shared that can fix this in case anyone that runs into this and wants to skip working in the DB directly.. $query->exec('RENAME TABLE tmp_field_body TO field_wvprofile_body'); Thanks @ryan!

Confirmed renaming the tmp field table to the original table name solved the issue. Many thanks for your work!

Fantastic work! That table does exist in my DB. As for DB table names being lowercase by default, that seems to conflict with the admin UI. If the field lets you enter uppercase names, but table names default to lowercase, I think this issue is pretty much guaranteed to happen. I think that because the UI has shown that uppercase letters are accepted and it's been that way for a long time then the solution would be for $config->dbLowercaseTables to default to false. That would preserve the behavior shown in the admin and fix the issue going forward. But, I too, have started to dig deeper. I did a quick search because I was curious about case-handling in MySQL itself and if there might be additional scenarios to consider. Database case sensitivity is dependent on the filesystem of the underlying OS. Windows is not case sensitive, Unix-like systems such as Linux are case sensitive, macOS is almost always the exception to that rule where it's a Unix-like system but HFS+ is not case sensitive and APFS can optionally be (but only at the time of formatting the disk) and is not by default. Even Docker on Mac looks like it struggles with this. So I'm wondering if this is an environment issue and having $config->dbLowercaseTables is true to mitigate potential issues. Regardless though, the admin UI/name field validation should reflect the current DB casing configuration. The better option would just be to eliminate using uppercase letters for fields in the future if it would act as a sort of protection for all environments.

There was nothing special in the setup, it's a very similar setup to what I usually use on sites. Really appreciate you looking into it and running some tests! This is it. It was the uppercase B in Body that I accidentally put into Name instead of Label that conflicted with another field named body. Really appreciate @Robin S @wbmnfktr and @iank working to figure out what happened, I don't have the time to troubleshoot right now (deadlines!) and you really helped out. If I didn't find out what happened I would be kind of uneasy about the website. Ideally I think it would be best if field names were restricted to lowercase, but that would be a big breaking change at this point. Many situations could cause this: Text intended for the Label could mistakenly be put into Name and all data is lost for that field (my case) A developer may be familiar with this bug, but not know or have forgotten that a field already exists with a name that will conflict Accidentally mistyping with a capital letter where a lowercase letter would have shown the appropriate duplicate field name error I have opened a Github issue for this bug.

This was on a production server so debug is off, no warning. I am familiar with that data loss warning and didn't see it. I've only seen that when attempting to delete a field or change its type. v3.0.165, so stable and not the latest. I was able to restore the data by pulling a table from an SQL backup and running a query to create the table and insert all of the data. Was the main text field on ~120 pages so there was a chance for a lot of catastrophic data loss. ProCache kept the content live while I restored this but it was a real not-cool moment... ProCache and Cronjob Database Backup can go a long way to save a site with no downtime. Just still really not sure if this is something everyone needs to keep an eye out for or if it was a one time glitch.

Like the title says. Accidentally renamed "wvprofile_body" to "Body" where I actually meant to change the label. Didn't notice that I had entered that into the wrong field, hit Save. ProcessWire destroyed the wvprofile_body table then showed me an error saying that the field "body" already exists. I have no idea what happened. I've never had this happen before, but I've also never accidentally renamed a field to an existing field name. Has this happened to anyone else? Doesn't PW check for a unique name before deleting data? Looked in the database directly, the entire wvprofile_body table is gone. Keep backups.

I've been following the news on the new editor and I'll be adding that to the next version of the module. The module is already getting refactored so I'll be able to plan for this much more easily. I'll work on posting some updates here with some details on what's planned!