Jump to content

FireWire

Members
  • Posts

    128
  • Joined

  • Last visited

  • Days Won

    2

FireWire last won the day on November 4 2020

FireWire had the most liked content!

About FireWire

  • Birthday January 1

Contact Methods

  • Website URL
    https://www.skylundy.io

Profile Information

  • Location
    California
  • Interests
    Web development & server stuffs.

Recent Profile Visitors

1,911 profile views

FireWire's Achievements

Sr. Member

Sr. Member (5/6)

105

Reputation

  1. ProcessWire definitely shines in the security department and the login page does have throttling. I don't know what your threat model is but usually sites have to deal more with bots than individual bad actors, but that depends on the purpose/use for your site. I've built many PW sites over the years and not one has ever been compromised. In my opinion, your biggest threat as far as hackers go would be a person that came into possession of one of the users' login credentials or much more common automated attack scripts with other vectors like requests containing data that the code isn't prepared to handle, or MySQL injections in your forms. Here are some additional thoughts on your login URL. If you don't want bad actors to know the login URL then it should be changed it to one that is practically unguessable like /clientname-admin-login or something easy to remember but hard to guess. Consider that your /processwire login URL is not unknowable because it's the default. Someone intent on getting to the login page or knowing what CMS you are using could analyze the markup and see that your images are being served from /site/assets/files/{page id} and any assets like JS may be served from the templates directory like /site/assets/templates/scripts- the file structure consistent across ProcessWire sites. When you load a page on a ProcessWire site, the server returns the request with the header "x-powered-by: ProcessWire CMS" unless you've disabled it and that will let someone look up what the default URL would be. Using /processwire in JS isn't really the issue. All that aside, it's not automatically a disadvantage to have your login URL known. Most of the PW sites that are built probably keep /processwire. My take is that if you have the opportunity to change it and reduce the chance non-authorized people would see the login page to begin with, why not? If this were my project I would change the login URL and create a dedicated /api page in the admin then use a hook to hide it in the page tree on render for non-superusers. It would keep the main site tree tidy as desired, allow for a clean semantic URL to work from, and not hard code in references to a part of the website that isn't content-related. If you want to take security against bots into consideration I would look into adding some bot blocking rules to your .htaccess file, I use 7G Firewall. Bot blocking prevents bot HTTP requests from requiring ProcessWire to boot up, analyze the URL, determine that it doesn't exist, and then serve the 404 page- this improves performance by reducing server load. Blocking bots also takes care of many other automated malicious requests as described above. I kinda blew this open a bit, but I think your question about security being limited to hackers and the login page could benefit from a wider scope.
  2. I had initially written off mass translation because after seeing the time it took to translate one or two fields I thought it could be a big holdup for the user. Have you run into any situations where a whole page runs into problems? This is really awesome work!
  3. @Robin S Appreciate the help! I was also thinking about a possible conflict between the selector and the value. Will work with your ideas. Cheers!
  4. Hey all. I have a search feature built into our website but it won't match a whole word containing a character, in my situation the % character. When I look for "50%" it brings up results with 50 in it, but does not match pages with 50%. I've tried with several selectors including *=, **=, ~=, and attempted an advanced search with #=+50%, but no dice. I've also tried with and without sanitizers including $sanitizer->selectorValue(); Any insights? Thanks!
  5. I'm all about devdocs.io We need to boost those Github stars...
  6. It would be pretty complex to create settings for that in the module config on a per-field basis and I think it might be too much of an edge case to implement in the module directly so I think hooking would be your best bet on this. Using `addHookAfter();` is the way to go. Just remember to test the output of `___executeData()` as it returns different types of data depending on the request, see each case in the switch statement in the `___executeData()` method. Here's some quick info that might help you get up to speed more quickly. All of the return values from `___executeData()` have the same data structure for predictability when used. At the very least each return value has `data` and `httpStatus` properties/values. A good way to make sure you are dealing with a translation is to decode the JSON (we'll say it's assigned to $decodedResponse), and then look for `$decodedResponse->data->translations;`. If the `translations` property exists in `data` then you know it's a translation. You would want to append your string to `$decodedResponse->data->translations[0]->text;`, encode `$decodedResponse` again, then return the modified JSON.. I'm not sure how you would be able to detect what field has been translated though because the return data from `___executeData()` doesn't contain any field name so your hook would append to all multi-language fields. Let me know if you can't find a workaround for this and I'll see if I can help. Dunno if that is what you were looking for but hope it helps!
  7. New version released. Fixed issue when translating larger volumes of text. In testing I was successful in translating over 20,000+ words in one field. When you get to large volumes of content like that there is a very noticeable amount of time it takes to complete that request, but it does it. Download the newest alpha here: Fluency 0.3.2 This should solve your issues @B3ta, let me know if you experience any issues.
  8. @B3ta That was all totally wrong. I was improperly making the DeepL API call with the wrong method which was totally my fault. After working on the issue I've tested translations with a lot of content and have had success up to ~22,000 words (rich text in a CKEditor field). If your PW fields has more than that, I'm impressed haha. That will have to be the new ceiling and I'll engineer a solution if people start hitting that. When working with content up to those levels though I think DeepL may be being generous with their stated API request size limit so keep in mind that number could fluctuate- just hypothesizing though. You should be more than okay when translating 5000 words though. Will push a new version soon and let you know when it is ready.
  9. @B3ta Update on the errors with lengthy content. Unfortunately it's not an issue with the module from what I can see. I was able to find out where the limitation on length was down to the sentence. When the API is used to translate it returns standardized responses that returns the translated content when it is successful, or errors that give instructions on what went wrong. Unfortunately the issue we are experiencing causes the DeepL API to return nothing (null) which means that their system experiences and issue but does not respond the way that they say it should. I'm going to be sending in a support request to DeepL detailing the issue and see what they say. Will report back with updates but as of right now it looks like Fluency can only handle medium amounts of text.
  10. I thought about building that out from the start but wanted to focus on getting the core of the module working first in a way that matched the way ProcessWire's multi-language setup works where there is a primary language and secondary languages. Including the general translation tool in the top menubar where any text can be translated from/to any language was a short term solution for that limitation. Once Fluency is able to mature and all of the bugs fleshed out then revisiting that would be an option.
  11. I've seen translations take varying times depending on length and language. Are you letting it work for a while? I will test more with longer content and look into how DeepL handles it.
  12. Many thanks! Let me know if anything else pops up.
  13. @B3ta New version pushed with fixes for the [[tag]] exclusion. All excluded strings set up in the module config should work now. https://github.com/SkyLundy/Fluency-Translation/releases/tag/v0.3.1 Still need to work on the large content translation though.
  14. That shortcode issue you're seeing was totally my fault. I will push a fix as soon as I can complete it. It will maintain the tags and all other excluded strings properly after that. 5k words! I haven't translated anything that long. As a little test I created a text file with ~5k words in it and the file size was 28kb. The API has a request limit of 30kb and this is almost certainly hitting that ceiling. I need to build out a way for Fluency to analyze the size of the translation, split it up into multiple requests to DeepL, and the re-assemble the multiple translations back into one. Unfortunately this is a hard limitation by the DeepL API so the workaround will have to come from me. I'll put that on the to-do list.
  15. Fluency now supports the new DeepL free accounts in the latest release (v0.3.0) which also includes some bugfixes. Now live on the repo. Thank you to @Mr. NiceGuy for notifying me about the new free accounts from DeepL. Very exciting to know that anyone can use Fluency for any project or to play around with at no cost. I hadn't noticed but since Fluency was released in November 2020 DeepL's supported languages has climbed from 12 to over 25 which is really awesome. Looking forward to seeing what languages they add next. Fluency will always offer all languages that DeepL supports as it pulls this information from the API, so no module updates are ever required to take advantage of these. Thanks everyone and bugfixes and feature requests are always appreciated over on the Github repo.
×
×
  • Create New...