ryangorley

Thanks @wbmnfktr! Yes, these are using ProCache. I forgot to mention that one, though I worked very hard to ensure uncached pages would be fast upon first visit, which I'm very satisfied with ProcessWire they are.

Hey All, I thought I'd jump on here and share my first 3 ProcessWire sites! LatticeWork (https://www.latticeworkinc.com/) - This one is live but still being actively developed in preparation for targeting an international audience (so current translations need auditing and it's not yet GDPR-compliant). The multilingual capabilities offered by ProcessWire, in contrast to WordPress, were the catalyst for starting my PW journey. The added performance that will be necessary as we deprecate some international sites and push everyone here was another decision driver for choosing PW. Obviously many thanks to @ryan and other core contributors for such an incredibly refined core product that regularly surprises me with features and functionality that I didn't know I was missing. Additional thanks go to @FireWire for the Fluency add-on, @Mike Rockett for Jumplinks, @Wanze for SEO Maestro, @teppo for Search Engine, and again Ryan for Pro Fields. These were invaluable. The Mart Group (https://www.martgroup.com/) - This site was my second to build with ProcessWire, though it was completed first due to its smaller size. In addition to all the prior thanks, I really appreciated RockFrontend by @bernhard while working on this one. Lori H. Cole (https://www.editsbylori.com/) - I probably wouldn't mention this single-page site I built as a favor, except to point out that PW is so lean and easy to work with I was able to give the client the ability to edit their own site without much server overhead or added development time. I did the front-end development work on these, which as a designer/animator hasn't historically been an area I'm comfortable in. ProcessWire has been such a delight to use that it has re-kindled my interest in working more with code. So, in time I hope to get more creative with the front-end coding as well. Thanks!

I'll add, perhaps for @ryan to consider, that an equally good solution would be for ProcessWire to borrow a behavior from elsewhere. In WordPress if I want to reset a slug I just clear the field and save the post. It then auto-populates that field from the post title as it does when the post is first created. In ProcessWire clearing the slug fields and saving the page just reverts the fields to their prior state. A small, but nice feature in WordPress I'd love to see in PW. :)

So, I've bumped into something worth considering. When I added more languages to my client's site the existing pages inherited the untranslated URL slugs from the default language. So I've got to go to the Settings for each page and manually click the translate from English button for each language to pull a translated slug. That's burdensome, but it seemed to be working... until I had to start translating a bunch of blog tags, then some slugs wouldn't translate. I couldn't figure it out until I realized that Fluency must be pulling a DeepL translation from the English slug, not the English title. You'd think it wouldn't matter, but it does. Here's an example: English > French: AI App > Application IA ai-app > ai-app It turns out DeepL translates ai-app to ai-app in every language. I don't think it knows what ai-app means so it just returns it. I don't know how commonly people will run into this problem, but I've been running into it a bit. Sometimes DeepL will return the slug unchanged, sometimes it will provide a slightly different translation than it did for the title. My suggestion would be for the slug translation prompt to use the default language page title when calling for a translation. I could see where pulling the title could create other surprises, such as when someone has the page title "Contact Us" but the slug "contact" they'll be getting longer slugs returned. Still I think that would be preferable to DeepL just silently failing. Maybe others feel differently. It's worth consideration though.

@FireWire Got delayed on my end, but I've uploaded and tested the update. It's working great. Thank you!

Thanks! I'll be able to test that tomorrow afternoon.

Okay, so I'm a little late on the testing side. I love the update! I'm having one issue, which probably has nothing to do with 1.07. The site I'm working on needs to be translated to Traditional Chinese for Taiwan (zh-tw) which isn't currently supported by DeepL and will have to be done manually. However, if I try to use Fluency when this language is added to the site it breaks with a console error: Uncaught TypeError: Cannot read properties of null (reading 'engineLanguage') at HTMLAnchorElement.<anonymous> (fluency.bundle.js:2812:110) Now, I presume this is because the language isn't mapped to anything in the Fluency module config. The behavior I would expect from Fluency is to just skip translations for languages not mapped, but that's not what it appears to be doing. Is that actually the problem, and is it something easily changed?

@FireWire At first glance, this looks great. I'll pull that dev branch version down and test it out as soon as I can. Thanks! Hopefully someone here has a good idea for the second issue. [fingers crossed]

@FireWire I'm still loving the convenience of this module, thanks! I've got a couple questions: When we add new languages to a site soon we're going to have empty language fields all over. If we use "translate to all languages" again to populate these blank language fields any manual edits to existing languages will be overwritten. How easily could the "translate from English" button be added back to co-exist alongside the "translate to all languages" button, so we could just pull individual translations without altering others when needed? Currently when a page is created and I translate the title, I'll have to add a space at the end of each translated title to prompt the page URL to reflect the translation. Would this be difficult to trigger automatically? If these are non-trivial changes, let me know what it would cost to sponsor the work. Thanks!

@FireWire This plugin has saved me so much time with a site I'm building for a client. Is there anywhere I can sponsor you or a way to send a few bucks your way?

@teppo I just wanted to let you know this plugin saved my life today. Thank you for building it! I just became a sponsor :)

@elabx @7Studio Thank you both for these in-depth suggestions and explanations. This has really helped a lot! @ngrmm Thank you also for pointing out this feature as well. What a great a community. I really appreciate you all!

Hey all, I'm coming from WordPress land, where blog posts, categories, tags, and publish scheduling are baked into the platform. ProcessWire is so amazing and flexible, but I'm kind of unsure about best practice for handling this. I'm migrating a site over with 100 blog posts, so I don't want to have to do it twice. This is how I expect things to work: Posts (pages) would be assigned to just one category (e.g. News, Guides, etc.) Posts could have multiple tags (e.g. iPhone Backup, Cloud Storage, etc.), and these would be shared with other posts across categories. An archive page would exist for each category (/blog/news/ or /blog/categories/news/) and each tag (/blog/iphone-backup/ or /blog/tags/iphone-backup/) listing all content. A copy writer could ideally add their own tags and see other tags have been used inside of the tag selector on a post. Categories will be predefined. A date can be selected for when the content becomes visible on the site, and a logged-in user can preview that content prior to that date. Categories: So I would imagine that the best way to handle categories would be to create sub pages of the blog page for each category and then create the posts themselves as children of the relevant categories, right? I'm mostly okay with that, though it's going to lead to longer URLs (/blog/news/this-is-a-somewhat-short-blog-post-title/). Not great for SEO, but acceptable if it's the best solution otherwise. Tags: This is the one I'm lost on. I haven't played with it yet, but I know there is a tag input field. I don't know if it is aware of existing tags so we don't get too much duplication (e.g. iphone, iPhone, Iphone, i-phone, etc.). I know I can figure that out, but if someone knows already and can share it would save me some time. The big question is how do I go about automatically generating archives of all the blog posts that share each tag? Tags need to be shared across categories, so the sub page method wouldn't work as a fallback. Someone must have figured this out, but I can't find anything documented. Publish Date: So I get that I can add a date field and build some logic into the queries to not show pages if today is prior to that value. I imagine I would use the $user ->isLoggedin() method to display the page content if today is prior to that date value as well. I don't love doing things this way because my sitemap (generated by SEOMaestro) is going to list these pages, and they are going to get indexed by crawlers as empty. I'm wondering if there is some better method for handling this functionality. -- Thanks in advance for the advice here!

@FireWire It is working great. Thanks again!

@FireWire Yes! That seems to have removed the error. Do I need to format those exclusions differently, perhaps?