Jump to content

gRegor

Members
  • Posts

    109
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by gRegor

  1. Related: a helpful lib I've been using for URL normalization and parsing is https://sabre.io/uri/
  2. 4.25.18 appears to still have the issue. It's in these lines: $info = parse_url($_SERVER['REQUEST_URI']); $parts = explode('/', $info['path']); I added some debugging and a proof of concept workaround (surely not correct) for the missing path: $info = parse_url($_SERVER['REQUEST_URI']); if (array_key_exists('path', $info)) { $path = $info['path']; } else { $path = '/'; } $parts = explode('/', $path); I think the more correct thing to do is ensure a full, valid URL is passed into parse_url() to ensure the path gets parsed correctly. I can file a github issue if that helps.
  3. @adrian Oh interesting, I had just updated it before posting, but I see there's actually 4.25.18. PW might have had .17 cached as the newest version. I'll update again.
  4. I'm experiencing this in production, not with Laravel. It appears to happen when the path has an empty segment, e.g. https://gregorlove.com//xmlrpc.php?rsd This isn't a valid URL on my site, I know it's just someone scanning for vulnerabilities, but I saw this error in the Tracy logs: Warning: Undefined array key "path" in /site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module.php on line 2865 Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /site/assets/cache/FileCompiler/site/modules/TracyDebugger/TracyDebugger.module.php on line 2865 ProcessWire: 3.0.210 PHP: 8.1.27 TracyDebugger: 4.25.17 Update: The issue appears to be that `REQUEST_URI` in this instance is `//xmlrpc.php?rsd`. Running parse_url() on that does not return a path segment because it parses `xmlrpc.php` as the host and `?rsd` as the query. The following explode() line expects that path. I think there needs to be some more sanitization before using the result of that parse_url().
  5. I've been loving BT's The Secret Language of Trees
  6. Hey all, I've looked at some other threads and github issues, but didn't find what I was looking for: https://processwire.com/talk/topic/21616-file-upload-inside-custom-module/ https://processwire.com/talk/topic/619-what-does-it-mean-destinationpath-is-empty-or-does-not-exist-upload_file/ https://github.com/processwire/processwire-issues/issues/885 I'm on PW version 3.0.165. I have a module using InputfieldFile to upload a CSV, then move it to a unique filename within a subdirectory in the module. Then it processes the CSV into a db table. That's actually all working smoothly, except I still get error messages on upload "destinationPath is empty or does not exist [field label]" and "Missing required value [field name]" Below is the relevant code. A couple notes: 1. I have both `required` and `requiredAttr` set because I wanted to avoid them clicking submit without selecting a file (it's happened, haha). I've tried turning those off and it fixes the second error "Missing required value" but not the first one about destinationPath 2. I can't seem to debug the $destination created by tempDir(), because I think it is removed when the request ends, but I presume it must be working OK because the CSV file ends up in the `/.uploads/` directory I specify, and is processed into a database table. 3. `/site/assets/cache/` directory is chmod 0777 and owned by "nobody" (yes, I know, I need to tighten this down :) Thanks for any assistance! Worst case I guess I can tell them to ignore the red message since it is actually working. <?php $destination = $this->files->tempDir($this)->get(); // debugging shows $destination = /site/assets/cache/WireTempDir/.ProcessMemberScorecard/0/ $form = $this->modules->get('InputfieldForm'); $form->attr('action', $this->page->url . 'upload-scores'); $form->attr('enctype', 'multipart/form-data'); $wrapper = new InputfieldWrapper(); $wrapper->importArray( [ [ 'type' => 'file', 'name' => 'scores_upload', 'label' => 'Scores File', 'description' => 'Select a CSV file to upload', 'required' => true, 'requiredAttr' => true, 'icon' => 'upload', 'extensions' => 'csv', 'destinationPath' => $destination, 'maxFiles' => 1, 'maxFilesize' => 10 * 1024 * 1024, 'noAjax' => true, 'descrptionRows' => 0, ], // additional checkbox fields, not relevant ] ); $form->append($wrapper); if ($this->input->requestMethod('POST')) { $form->processInput($this->input->post); $ul = new WireUpload('scores_upload'); $ul->setValidExtensions(['csv']); $ul->setMaxFiles(1); $ul->setOverwrite(true); $ul->setDestinationPath($this->config->paths($this) . '.uploads/'); $dt = new DateTime(); $tmpname = bin2hex(random_bytes(8)); $ul->setTargetFilename( sprintf('%s-%s.csv', $dt->format('Y-m-d'), $tmpname ) ); $results = $ul->execute(); if ($errors = $ul->getErrors()) { foreach ($errors as $error) { $this->error($error); } return $form->render(); } if (!$results) { // older, probably not needed since both required and requiredAttr are set $this->error('Please select a CSV file to upload'); return $form->render(); } // handle processing at this point, // then redirect to the next step where user confirms // the final result } .
  7. Well the table entries are simple enough, so I'm going to just try removing them. I'll report back if my site implodes, but I suspect it will be fine. 😄
  8. I posted in the release thread, but that thread is several months old so I'm reposting here to get more eyes on it: After upgrading to 3.0.210 and running Modules > Refresh, it warned: I don't think I've had InputfieldTinyMCE installed before unless it was from an early 2.x version (site's been on PW since ~2014). It's definitely not the new InputfieldTinyMCE. I don't recognize JqueryFancybox. I checked in db table `modules` and there are entries for InputfieldTinyMCE and JqueryFancybox, no date in the created column (0000-00-00 00:00:00), so I'm guessing these are quite old? I know the site hasn't had those folders in /modules over the last several years at least. Is it safe to just remove those entries from the modules table?
  9. Just upgraded from 3.0.165 and the process went very smoothly as always. Only odd thing is a notice when I run Modules > Refresh: I don't think I've had InputfieldTinyMCE installed before unless it was from an early 2.x version (site's been on PW since ~2014). I don't recognize JqueryFancybox. Doesn't seem to be causing any problems, but is there something else I need to update? Edit: I checked in db table `modules` and do have entries for InputfieldTinyMCE and JqueryFancybox, no date in the created column (0000-00-00 00:00:00), so I'm guessing these are quite old? I know the site hasn't had those folders in /modules over the last several years at least. Is it safe to just remove those entries from the modules table?
  10. Not ProcessWire-specific. $this-> is the way to access properties and methods within the object, as part of Object Oriented Programming. More: https://www.php.net/manual/en/language.oop5.properties.php
  11. Bump. This is now in the modules directory! ? The first post has been updated with current details.
  12. Ah, I hadn't considered it might be the repo name being different than the class. I might try that first. If flattening is required, I do wonder how to best organize modules like Webmention, which is actually a set of two Process classes, an InputField class, and FieldType class.
  13. Is there anything in /site/assets/logs/errors.txt (or exceptions.txt)? I will usually turn on error_reporting and display_errors in index.php or ready.php: error_reporting(E_ALL); ini_set('display_errors', '1');
  14. I build a lot of custom registration forms on ProcessWire sites and prefer to write the HTML directly, with some ProcessWire goodies added on. This seems quickest for authoring forms that match the site and doesn't require jQuery/jQueryUI. I prefer to make forms work even when JS is disabled, if possible. For CSRF, I manually generate a single-use token and put in the hidden form fields. I have a custom class that lets me set up a set of fields, their types, and validation rules. Parts of that leverage PW's $sanitizer and sanitized values end up in $input->whitelist() for easy processing and for populating form field values.
  15. Answered Below Short version: the git repository must have the .module.php file (and .info.php or .config.php files if used) in the top directory. It is OK to put any other files in sub-directories. ProcessWire will create the /modules/ModuleName directory during install and put all files in there, so there's no need to have folder ModuleName in your repository. --- Original post: I am trying to submit https://github.com/gRegorLove/ProcessWire-IndieAuth I get these errors on the first step: The module has the static getModuleInfo() function. My folder structure does put the files in a directory of the same name (ProcessIndieAuth), but I've not had issues with submitting modules like that in the past (Webmention -- granted, it's been several year ago now). Must I "flatten" the files by not having them in the sub-directory? I tried searching the forums and the documentation but couldn't find a definitive answer.
  16. Late reply here, but I have some PHPunit tests in my IndieAuth module: https://github.com/gRegorLove/ProcessWire-IndieAuth/tree/main/ProcessIndieAuth/tests bootstrap.php: loads the Composer dependencies and ProcessWire via its index.php ClientIdTest.php: I think this file is older and needs to be updated, but it still gives an idea how I load the module and test methods within it. ServerTest.php: newer file which shows testing additional classes in the module. In this instance, this is like any generic PHPunit testing since that class is static methods and isn't calling ProcessWire methods.
  17. Just pushed a bug fix: During install it now adds the role "indieauth". Assign this role to any users that should be able to authenticate / authorize IndieAuth clients. The README has been updated accordingly.
  18. Now in the module directory: https://processwire.com/modules/process-indie-auth/ IndieAuth lets you sign in to applications using your domain name and grant access to read/write to your site. This module adds IndieAuth support to your ProcessWire site, enabling two main things: Authentication: When you visit a site like indielogin.com and enter your domain name, you will be taken to your ProcessWire admin area to sign in and approve the request. If you approve the request, you will be returned to the site and logged in as your domain name. Authorization: When you visit an application like Quill, it needs to also get your permission to post to your site. You will be taken to your ProcessWire admin area to sign in and approve the request/scopes that the app is requesting (create, update, delete, etc.). If you approve the request, you will be returned to the app, logged in as your domain name, and the app will have an access token for your site. Features Browse the applications you have granted access tokens to. See when each one was granted, last used, and will expire. Revoke any application’s access tokens Set the default expiration period for new access tokens. The initial default is 14 days. Automatically remove expired tokens During authorization, confirm and change the scopes granted to the application. For example, an app may request “create” and “delete” scopes, but you can grant only “create.” During authorization, you can also choose to grant an access token with no expiration Installation Navigate to Modules > New. In the Module Class Name field, enter ProcessIndieAuth Copy the template files from the module’s directory /extras/templates into your site’s /site/templates directory. Verify that the plugin installed pages: IndieAuth Metadata Endpoint Authorization Endpoint Token Endpoint Token Revocation Endpoint IndieAuth page under the admin’s Access menu Look up the user(s) that you want to allow to use IndieAuth and assign them the “indieauth” role Update your home page template to add the link elements inside the <head> element: <?=$modules->get('ProcessIndieAuth')->getLinkElements();?> This should result in three <link> elements in the source HTML: <head> <link rel="indieauth-metadata" href="/indieauth-metadata-endpoint/"> <link rel="authorization_endpoint" href="/authorization-endpoint/"> <link rel="token_endpoint" href="/token-endpoint/"> </head> Sign In To test signing in with IndieAuth, visit indielogin.com and enter your domain name. Follow the prompts to authenticate and you should end up back on indielogin.com with a success message. Sign In and Authorize To authorize an application with IndieAuth, your site will first need a module that uses access tokens. I have a Micropub for ProcessWire module in development that does that. Micropub is a standard that lets you publish to your site using third-party clients. If you’d like to try it out, follow the instructions on GitHub to install it. After installing, visit Quill and enter your domain name. Follow the prompts and note the additional fields for “scope” and “expiration,” since you are authorizing an application to interact with your site. After successfully authorizing, try to post a short note from Quill. Quill should redirect you to the new post if it was successful. For a list of other Micropub clients you can try, see https://indieweb.org/Micropub/Clients. Admin and Options In the admin, you can see which applications you have granted access tokens to. You can see when each token was issued, last accessed, and its expiration. You can also manually revoke a token at any time. Navigate to: Access > IndieAuth. There are a couple options in the admin at: Modules > Configure > ProcessIndieAuth: Default access token lifetime (in seconds): This defaults to 14 days and is what appears in the authorization screenshot above. Automatically remove access tokens after expiration (enabled by default): When enabled, the site checks approximately every six hours and removes expired access tokens. Regardless of whether this option is enabled, the module will reject any application attempting to use an expired access token. Since access tokens cannot (currently) have their expiration extended, I recommend keeping this option enabled so the admin list stays tidy and current. Finally, this module writes some admin logs. Access those at: Setup > Logs > indieauth More About IndieAuth If you’re interested in more details about IndieAuth, I recommend the article “OAuth for the Open Web” by Aaron Parecki (or the video presentation). If you are interested in implementing IndieAuth in your project, see the IndieAuth specification. Originally published at: https://gregorlove.com/2022/07/indieauth-for-processwire-released/ Previously: 2021-10-07: This post was originally about alpha testing the plugin before I submitted it to the modules directory.
  19. In case you are still experiencing this, it appears it is related to the server upgrade, a mod_security issue, not ProcessWire. I just ran into this myself and my searching led to an acquaintance's similar issue in this post. I filed a support ticket with DH and expect they'll get it fixed shortly. It is probably a per-domain or per-account issue, so I'd suggest contacting support if you haven't already.
  20. Hi Robert, I just replied over there as well. The additional detail here of "Call to a member function render() on null" does point to a few possibilities that I'd check in order: 1) FieldtypeWebmention is installed? 2) Template has a field of that type 3) Field name matches what's used in your code.
  21. @isellsoap Glad you like it. Let me know if you have any questions.
  22. This looks awesome! I was considering a similar advanced DateTime module that would store the UTC offset in addition to the timestamp, so in the UI you could select the date, time, and timezone. I might try this out and see if I can extend it for that purpose.
  23. That sounds like an odd server setup. $config->path->assets should give you the full path. Glad you got it working, though.
×
×
  • Create New...