Jump to content

FireWire

Members
  • Posts

    153
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by FireWire

  1. That was something I considered after I posted that message. I use Docker for development and for some reason if I am connected to a VPN then DeepL fails to connect and it causes PW to not load admin pages. It is probably a networking configuration in the Docker image. This may be an issue that could exist with some dev environments, but that's just a semi-educated guess haha. Glad you are enjoying the module! Please let me know if you experience any issues. The next version is coming out soon and it will be going from alpha to beta version and have a bunch of new features. Any feedback is greatly appreciated!
  2. Next would be to check the ProcessWire logs under Setup > Logs > exceptions, and Setup > Logs > errors to see if there are any PHP errors since it looks like Fluency is able to connect to DeepL.
  3. Hey there WireDevelopers. I've updated this module with new features and stronger performance. If you are using the old version, an upgrade is strongly recommended. If not, see if it works for you.
  4. Hmmmm, interesting. Can you confirm the following: The "DeepL API Key" field has your API key entered and that it says "API key validated" below it? Under "DeepL API Account Usage For Current Billing Period" it shows values for Character Limit, Characters Translated, Characters Remaining, and Total Usage? (It is OK if Characters Translated is 0 and Total Usage is 0%) The Source/Destination Languages are taken from DeepL so this is the first step to make sure that module can connect to their service. I haven't tested this on the dev branch, but I don't believe there are any changes substantial enough to affect Fluency.
  5. That's a pretty rad idea as well. The API endpoints are all set virtually using URL hooks so the process comes up as ProcessPageView in that context.
  6. I think your solution works for a bigger context of where a lot of data on a page would be dependent on the context it was created in. I just needed to make sure that the hook for one field can determine at runtime whether the field was filled by a user in the PW admin or the Page API. Your solution from the PW admin side did make me think bigger picture which is also a possible solution for my application. This field is being used on pages that can be created/edited in the ProcessWire admin, but they can also be created/modified by a website REST API that other systems- in our case Salesforce- can use to create/modify data on the site. Calls to this website API are authenticated using ProcessWire users which have an API key assigned and a role of web-api-access. So rather than focus on verifying where the the page was created at the field level, I could check that the user creating the field is an API user at the page level. I got a little more into the weeds with that description, but your idea helped me think of a different approach.
  7. This would be a good idea if I knew the context ahead of time but the content on a field could be entered/edited from anywhere after added to a template.
  8. So there I was diving into a technical hole and the solution was so simple to begin with. Excellent.
  9. Hey all, I have pages that can be created two ways, in the PW admin and via an endpoint where JSON data is sent. I have a hook that checks field data on page save and errors if it is not correct. I would like this to create an error in the PW admin using $this->errors, but if the page is created via the Page API in the script that handles JSON requests I want to throw an exception I can catch and handle accordingly for the JSON response. This also allows for setting a user friendly error message for the PW admin, and machine friendly data for API use. Trying to figure out how to detect which context that the page is being created in. A script, or in the PW admin and act accordingly. Is this possible?
  10. Solved the issue. Found the following issue in a post from 2015 using some Google search that described a similar/same problem. I was able to solve the issue by logging in as a different user, checking the checkbox, and then saving the page. After that the superuser role was then allowed to set/save the checkbox. Odd issue. I created two fields, one text and one checkbox. I was able to set the value of the text as a superuser but not the checkbox. Solution is to log in as a different user with access to this field, set a value, then logout and then login as the superuser which will then allow the value to be saved.
  11. Like the title says. I've added a checkbox field to the User template, checking it and clicking save on the page doesn't store the value and the checkbox is always unchecked when the page loads. I'm creating a hook that works with this template and checkbox value for addHookBefore Pages::save. Accessing the value is always 0. Setting the checkbox value inside the hook doesn't save either. Inserting values into other fields in the same hook does save. I'm using $page->checkbox_field_name to access the value, and $page->checkbox_field_name = true when testing to try setting the value via API. More info: I'm editing this user profile under the Superuser role which shouldn't present any permission issues. I've enabled the checkbox under "What fields can a user edit in their own profile?", but shouldn't matter because I'm editing another user's profile. Checkbox value fails to save whether hook is present or not. PW v3.0.184 halp.
  12. Really appreciate your help as always! This was just a little bit of a deeper dive than usual and I was doing a lot of thinking out loud so to speak. Just putting the big questions out there. As for the `$http->error`, that property is only available after it tries two times.
  13. Got it. This introduces something that isn't noticeable even when reading the method documentation. In HTTP terms a 404 status isn't a failure, it's a successful response from the remote server that should be interpreted by the application making the request. When I read fallback, I assumed that it's because the request attempt failed, for example if CURL isn't available on the system it falls back to fopen. A use case I have is to check that a page exists and then let the user know, so a 404 is useful because the user is shown the error, they can fix the URL, and then the new URL is tested. Sending via 2 different methods the user must wait 3x longer. The immediate solution is to manually add parameters to every WireHttp call to disable the default configuration, but that seems like an extra step to keep WireHttp from ignoring a valid response. All that said, does this have some sort of benefit I'm not seeing? When should a 404 be treated like a failure rather than an informative response to a successful request? First time using WireHttp. I've always written my own CURL methods, just trying to make sure I'm not missing a benefit that this has.
  14. That's right, it's a 2 for 1 special. I am using WireHttp to make a GET request but it is actually making 2 requests when calling WireHttp::get() only once. It doesn't matter where I make this call, it always sends 2 requests. I stripped this down and wrote the request code in init.php to test with the bare minimum of ProcessWire booted. Here's my code: <?php namespace ProcessWire; /** * ProcessWire Bootstrap Initialization * ==================================== * This init.php file is called during ProcessWire bootstrap initialization process. * This occurs after all autoload modules have been initialized, but before the current page * has been determined. This is a good place to attach hooks. You may place whatever you'd * like in this file. For example: * * $wire->addHookAfter('Page::render', function($event) { * $event->return = str_replace("</body>", "<p>Hello World</p></body>", $event->return); * }); * */ if (!defined("PROCESSWIRE")) die; $http = new WireHttp; // Create unique URL with random number to track method call vs. requests made. $url = 'https://renovaenergy.ngrok.io/processwire/test/init/' . rand(1, 9999); $http->get($url); die; Here's the requests I'm receiving after loading the page once: That test was done with all modules removed from the modules directory and the module cache cleared. I can't think of what is causing one get() call to create two requests. Running PW v3.0.184
  15. @monollonom Good observations on that. I think the regex section could use an example like the others on that page. I just wasn't able to visualize that. Many many thanks for your assistance an insight on this!
  16. @dotnetic I picked it up after developing our API in Slim and looking at some best practices. It would be really great if this was the ProcessWire default.
  17. Some follow-up thoughts. Even though @monollonom had a more elegant Regex string that works, I still wanted to find out if I could make my ugly string work since technically it should have and there might be a case where an alternate isn't possible. I found some curiosities that may help some other people if they run into a similar problem. Original string: '/api/v1/offline-events/{eventId:#(?=.{15}$)([A-Za-z0-9])\w+#}/?' First off, I had to remove the # regex delimiters at the start/end. Then I had to replace the {eventId:regex} curly braces and apply parenthesis (eventId:regex) then it worked with the ugly regex. New String: '/api/v1/offline-events/(eventId:[[:alnum:]]{15})/?' This was a little confusing because in the URL hooks documentation I just noticed that /route/(variable) and /route/{variable} are used interchangeably. The second issue is that the documentation states the following: Using any of the !@#% characters at the beginning/end of the regex expression caused it to fail whether using {} or () to surround the route argument. So long story boring, I'm not sure if the documentation could be clarified or if there's a bug somewhere (or if I'm just reading it all wrong). Documentation I am referring to here for reference. Something @ryan should review?
  18. @monollonom HECK YEAH! If there's anything that demonstrates my complete lack of regex abilities... it's this post. Excellent 404 fix. First time using the URL hooks and didn't know if there was a "URL Hook way" of handling.
  19. You're 100% right about the DB storage of keys for modules. My use case for the credentials in .env is for non-module related needs that are necessary in various scripts around the codebase. Some of which aren't in the ProcessWire namespace so wire() & $config aren't available. A good example is where I work I've built a company-wide REST API to interact with our systems so those keys are in .env. It makes it very easy to work with at a glance. With clean variable names I haven't run into any $_ENV pollution/collisions. Two custom variables that we do create are $config->envIsProduction and $config->envIsDevelopment to help alter code behavior when needed, we use that to do things like switch scripts in markup (like production/development Google Tag Manager/Analytics). Here's a more robust (dummy) example of our local development .env, ENVIRONMENT="development" # Either production or development # CMS CMS_DEBUG="true" CMS_CHMOD_DIR=0755 CMS_CHMOD_FILE=0644 CMS_USE_PAGE_CLASSES="true" CMS_USE_FUNCTIONS_API="true" CMS_PREPEND_TEMPLATE_FILE="_init.php" CMS_USER_AUTH_SALT="d5e3ac4deba1e382255bbd8755d7e713" CMS_LOCALE="en_US.UTF-8" CMS_TIMEZONE="America/Los_Angeles" CMS_DEFAULT_ADMIN_THEME="AdminThemeUikit" CMS_INSTALLED=1580677417 CMS_MODULE_INSTALL="true" # CMS Database - Development CMS_DB_HOST="127.0.0.1" CMS_DB_NAME="pw_website_db_name" CMS_DB_USER="db_user_name" CMS_DB_PASS="hB99kVrqS444VZlrrr" CMS_DB_PORT="3306" CMS_DB_ENGINE="InnoDB" # Renova Energy API - Development RE_API_URL="https://secure-tunnel-url.ngrok.io/" RE_API_KEY_WEBSITE="d5d891e204f5473990bb533cf7fca22f" RE_API_KEY_EVENT="531706b9837744ecbbf2b008bc11a681" # Mailgun MG_KEY="5af07ec6-315c-48d9-b615-f1cfb3d75820" MG_DOMAIN="mg.ourconfigureddomain.com" # Forecast.io FORECAST_IO_KEY="5fce4a3251f711ecbf630242ac130002" # CallTrackingMetrics Webhook Auth Token CTM_WEBHOOK_AUTH_HASH="227040707a1b4e13bc88facf928defe0" # Web API Authentication Keys WEB_API_KEY_SALESFORCE="84f13985-77f5-4521-9c2d-1567ddb9bf2e" WEB_API_KEY_APP="e7051f6e-5905-47f6-9108-93d2f02a53b8" Also, thank you for the kind words about Fluency, looking forward to the next big (biggest yet) release soon!
  20. I'm a little late to the game on this but wanted to throw out what we use on our PW sites. We keep all credentials in .env files in the root directory and then loaded using a package called phpdotenv. The .env file is loaded and then the credentials can be accessed at runtime via the $_ENV global. Some further details on this setup: .env files are automatically protected system files in Apache and will not be served (unless someone actively overrides this, but that would be bad). These files are not added to the Git repository and never stored. We have .env files for local, staging, and production. The contents of each file are stored in whole as a secure note in our password manager. The dotenv library is loaded once in config.php and the values are available globally. We also store credentials for external APIs and services. This allows us to store not only credentials, but any values that differ between local/staging/production. We store all of our config.php variable values in .env so that the config.php file is environment agnostic and we can always be sure that the .env is the single source of truth for the entire CMS configuration. We use Git to deploy to staging/production servers so using .env files allows us to push all of our code while knowing that sensitive information and data that changes between environments never gets mixed up. Also makes it very clear to anyone looking at the code that these values are stored in a dedicated system dot file. Here's the package, can be installed with composer https://github.com/vlucas/phpdotenv This is what a config.php file looks like with it in use: <?php namespace ProcessWire; // Load env variables from .env in root directory $dotenv = \Dotenv\Dotenv::createImmutable(__DIR__ . '/../'); $dotenv->load(); $config->debug = filter_var($_ENV['CMS_DEBUG'], FILTER_VALIDATE_BOOLEAN); $config->usePageClasses = filter_var($_ENV['CMS_USE_PAGE_CLASSES'], FILTER_VALIDATE_BOOLEAN); $config->useFunctionsAPI = filter_var($_ENV['CMS_USE_FUNCTIONS_API'], FILTER_VALIDATE_BOOLEAN); /** * Database Configuration */ $config->dbHost = $_ENV['CMS_DB_HOST']; $config->dbName = $_ENV['CMS_DB_NAME']; $config->dbUser = $_ENV['CMS_DB_USER']; $config->dbPass = $_ENV['CMS_DB_PASS']; $config->dbPort = $_ENV['CMS_DB_PORT']; $config->dbEngine = $_ENV['CMS_DB_ENGINE']; // Etc... Hope this might be useful to someone!
  21. Hey all, I've been building a new feature on our PW site and the URL hooks are exactly what the doctor ordered. I am developing a RESTful web API to allow external platforms to integrate with our site. The API endpoints are namespaced at /api/v1. I am having trouble making use of the named route parameter using regex. I have a hook for /api/v1/offline-events that gets all Offline Event pages. The next route to be defined is /api/v1/offline-events/{event ID}. The event ID is using a custom string (not the Page ID) that is a 15 character alphanumeric string like this: E4LxQRXZadgjstw. However when I use a PCRE compliant regular expression (tested on regexr.com) I get an error. Here is my hook code for reference and the error produced: <?php namespace ProcessWire; $wire->addHook('/api/v1/offline-events/{eventId:#(?=.{15}$)([A-Za-z0-9])\w+#}/?', function($e) { // ommitted for brevity }); // Error thrown: Warning: preg_match(): Unknown modifier '(' in /wire/core/WireHooks.php on line 1170 I've tried using all delimiters in the documentation (!@#%) but no change in the outcome. The second question is how do I create a wildcard capture for all 404s that occur after the /api endpoint? Currently it is loading the website 404 page. Many thanks!
  22. I am finishing the next release right now and will be pushing a new version. In this version you can customize all Fluency UI strings for any default language, using the translation service if desired.
  23. Okay now I got it. That is the URL that needs to be in the JS file I mentioned. In that JS it does it's best to parse the URL, get the admin slug, then build the request URL. If you revisit that code in fluency_tools.js set the value of requestUrl to where it should be able to send requests to the module. It should look like this: var moduleRequest = function(requestData, callback) { var winLoc = window.location, params = [], requestUrl = 'https://domain.com/_tmp/processwire/fluency/data/' // requestUrl = winLoc.protocol + '//' + // winLoc.host + '/' + // winLoc.pathname.split('/')[1] + '/fluency/data/' // ... ommitted for brevity ... } If you move to production and ProcessWire is being served from the root directory then change this back.
  24. Go to the Fluency module configuration page, then click on the "Translation" link in the menu bar. What is the URL of the page that loads?
  25. Added a fix for the PayPalm img. Thanks for mentioning. Will be included in the next release. I hadn't anticipated an installation in a subfolder. The module creates an admin page when installed and that page's URL is an endpoint for the JavaScript on the page to make AJAX calls to when getting/sending translation data. The JS assumes that this URL will be at the root level. The JavaScript can't tell if the site is in a subdirectory. I don't know how to code the JavaScript to figure that out since it is separate from the CMS and the module which can tell what the full proper URL is but the JS doesn't have a way to get that info. There is probably a way to solve this problem but it will take a little investigating. There is a quick and dirty solution that would fix this issue for you right now. That would be to go into the module directory, navigate to /src/js/ and then edit fluency_tools.js to point to the full URL you need by changing line 32. From this: winLoc.pathname.split('/')[1] + '/fluency/data/' To this: winLoc.pathname.split('/')[1] + '/_temp/fluency/data/' That will let the JS know where to get/send translation data. If/when you need to move your PW site to the root directory then change it back to the original value. Let me know if that works for you.
×
×
  • Create New...