Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


FireWire last won the day on October 25

FireWire had the most liked content!

About FireWire

  • Birthday January 1

Profile Information

  • Location
  • Interests
    Writing code. Writing more code. Refactoring. Writing code.

Recent Profile Visitors

3,199 profile views

FireWire's Achievements

Sr. Member

Sr. Member (5/6)



  1. New version pushed to the dev branch with fixes for InputfieldTable and FieldsetPage elements. Please let me know if this solves the issue @monollonom https://github.com/SkyLundy/Fluency/tree/development Thanks for everyone's patience. Work has been crazy (and a long-ago planned vacation didn't help). Thanks!
  2. Hahaha- those are great. This is what I'm putting on the invoice line item. That's it. Also, new DJ name.
  3. @monollonom Big help! This problem was caused by my replacing <button> elements with <a> tags for the translate triggers under fields. The fact that my links don't have an href="#" was an oversight because I always add those, but either way that would have caused an issue. I did that so that links could match any custom styles that were done to the admin, which was something that isn't possible if I used a <button> element. I could revert to using a button, but it would be a welcome fix the JS could be patched with more specificity since the # href is very common. In any case, open to input from @ryan In the meantime you can use the previous release as the only changes after this were for cosmetic reasons. Tables will work here: https://github.com/SkyLundy/Fluency/releases/tag/v0.9.0b I've identified the culprit, my code wasn't accounting for hidden template elements that InputfieldTable uses to create new items. I haven't nested a table field in a repeater before, so I'd never have seen this coming. Working on a fix. Thanks for the bug report and the assistance!
  4. Don't be fooled! This reporter has published propaganda to make people think that strategic and intelligent thinking will lead to a successful WordPress update. In reality, there is no logic or reason that can prevent disaster, you are at the mercy of chaos and a hateful god determined to destroy your will to live. To describe this in more depth, one of the plugins simply wasn't able to be downloaded without paying for another license which prevented the entire site moving from PHP 7.3 to 8.1. There was another plugin for forms that showed a "This form is temporarily unavailable." error to website visitors. This plugin author has decided that not only will it stop working- it will break your site's functionality. After running a standard plugin update in the WordPress admin- it removed functionality and demanded additional payment. The plugin did not indicate that a new license would be needed before updating, and thanks to caching- you couldn't tell the form was broken on the front end! Also- let's talk about caching! Caching for WordPress is a complete mess. Sure this is not exclusive to WP, but it takes the cake. Why? Because hosting companies' "Managed WordPress" plans which are an attractive option for hosting companies because it lets them set very aggressive caching policies to squeeze more capacity out of cheap crappy shared servers. This is why "Managed WordPress" hosting is almost always run on shared servers- even WPEngine, one of the more well known and much more expensive services, is all run on shared servers. I confirmed this via their sales team who was harassing a client about their website's monthly traffic limit. They said that the overages cause "performance issues". After confirming the server isn't a VPS (although they price it like it is), I asked if "we should be worried about other sites slowing down our site because WPEngine uses shared hosting". They left the client alone after that. WP is frustrating, but I take a deep breath and think about how that WP money is helping pay for an upcoming vacation. So... thanks WP?
  5. Oh, what's this? Another completely different site borked itself? Performed an update using an automated tool through the web host where the core and all plugins are updated at the same time. Is there a right way to update WordPress? The world may never know... This update has has rendered the Admin unusable and inaccessible. Time for a server rollback! Okay! We're back... oh boy... Did you know? Deactivating plugins in the wrong order can make the plugins page hang on a redirect loop every time you try and access it. Time for a server rollback! (Before someone says "that was a caching issue", no it wasn't) Okay! We're back... oh boy... Did you know? In WordPress, a commercial theme or plugin you've purchased and installed may install other commercial plugins that require their own license. When that license expires, you may have to pay for a separate license for the plugin that the plugin/theme you already purchased installed when it comes time to upgrade. PROTIP: the commercial plugins that were installed by the theme or plugin you purchased are not easily recognized as a dependency or indicate what plugin/theme installed it- so, when working on WordPress, keep a shovel handy in case you have to start digging!
  6. Oh heck. Gotcha. I just remembered I hadn't pushed all of the new features to main- so you can ignore that. I'll take a look asap. What version of ProFields are you running?
  7. Okay- I'll take a look. Unfortunately I am completely overloaded with work right now so the fix may be a little delayed. Can you switch between the button styles (translate from default vs. translate to all) and see if there's any difference? Really appreciate the help!
  8. This is an oversight on my part- if the field is empty, it shouldn't translate. Problem solved. The following two issues are solved by a translate to all button on non-default languages, and the translation button type is still an option on the module config page 😎 The real point for a "translate to all" button is to make it easier for the end user and to prevent content deviation, where one language says one thing and another language says another. It's very easy for an end user to forget to translate content- so there is no translated content, or the translated content becomes out-of-date. I've seen both of these issues in sites I've built that had people doing SEO work, or just managing content in general. The "Translate to all languages" and the content change indicators are the best way that I can think of to help people enter content, click translate, and complete their work with the highest amount of accuracy. In my experience non-web people aren't as engrossed in the process of maintaining websites as much as developers are, so unless you make it as simple as possible it increases the likelihood that the website will be poorly maintained. Also just realized that the new "Translate to all languages" button doesn't work when translating the page's URLs. Will push a fix for that.
  9. Bonus! I've added an option to enable "Translate to all languages" for each Inputfield 😎 Enable the new translation button on the module config page. The old style of translation (translating each language from the default language) is still available for those who want to use it. Translate to all languages at once from the default language Translate to all languages at once from any language. This is where the tab indicators come in really handy to indicate the tabs that have received updated/translated content with one click. This is on the dev branch as well, so give it a try and tell me what you think.
  10. Links to ProcessWire pages in translated content now point to the localized URL. I'm pretty sure this is good to merge into a release, but extra testing would be the best idea. @bernhard Pushed to dev branch https://github.com/SkyLundy/Fluency/tree/development @jacmaes I saw that like on @bernhard's post if you want to take this for a spin as well.
  11. Impressive. I was thinking about some of the higher latency I've seen in databases that aren't located on the same server that is hosting ProcessWire. I'm sure it will be fine. I'm sure someone will come back and let me know if it's too slow πŸ˜‚ Started working on this but have been super busy with work. Will report back here when the release is ready.
  12. Completely agree, glad you brought this up. Working on this now. I might have you take a look at what I put together on the dev branch to get your opinion. I wanted to give it a shot since it presents a few challenges that I'd like to try solving, one of which is this: <?php ProcessWire\PageFinderSyntaxException OR values not supported for multi-language 'path' or 'url' at wire/core/PageFinder.php:3684 3680β–• * @throws PageFinderSyntaxException 3681β–• * 3682β–• */ 3683β–• public function syntaxError($message) { ➜3684β–• throw new PageFinderSyntaxException($message); 3685β–• } 3686β–• } 3688β–• /** Trying to keep this efficient so if there's 5 (or many more) links in a translated text, then it would be preferable to make one $pages->find('{selector}') call rather than looping over them and making multiple calls. Do you think this can be done in one? Will this need a raw SQL query (if that would present a solution)? I think another downside to multiple calls would be that this is querying the "name" column which isn't a MySQL indexed column, so a site with many many pages might experience additional slower performance. The only thing we have to work with in the <a> elements is the href value... Whoa there cowboy, we're really stacking up new features here and I can't keep up 🀣
  13. This is a great case for including a "Translate to All Languages" button on all language tabs! I didn't think about that. This is a great real-world example. I'll add that to the roadmap. Very awesome to see that feature solve an immediate need!
  14. Last time it did, but I guess not being a complete failure this time is something to celebrate. Kudos to WordPress for doing the bare minimum! Here's a gold star ⭐
  15. Translate to all languages is on the roadmap. Very desirable feature but a lot of new code separate from the existing buttons/translating UI/error handling. I have an implementation in mind but didn't want it to hold up releasing the module, especially since it was so long overdue. I know this can be really annoying and I want to have this feature implemented as well. I had plans for a "Translate to All Languages" but not buttons for individual languages since it could lead to content that doesn't match between languages. Also want to keep it dead simple for the end user. Open to thoughts on this. I think that the way that tabs show that content has been modified is a good way to know that the content for another language has been updated. Some thoughts about switching to a tab after translation: The person translating the content likely doesn't know how to speak the language they are translating to If they need to go back and edit the content again there's an extra click to get back to the language they do speak The change indicators on the tabs are bound to the state of the Inputfield independent of the translation function, so you can trust that the content has been translated When the "Translate to All Languages" button is implemented, all of the tabs will show that they have been updated so it will be easy to see The flip is a great idea. I left that second select open since it's a "global" translator that provides all of the languages. I don't have any issues with it being pre-selected. Are there instances where you need to use the translator tool rather than on the fields themselves?
  • Create New...