Jump to content

MoritzLost

Members
  • Posts

    321
  • Joined

  • Last visited

  • Days Won

    16

MoritzLost last won the day on April 14

MoritzLost had the most liked content!

2 Followers

Contact Methods

  • Website URL
    https://moritzlost.de

Profile Information

  • Gender
    Male
  • Location
    Cologne, Germany

Recent Profile Visitors

1,632 profile views

MoritzLost's Achievements

Sr. Member

Sr. Member (5/6)

854

Reputation

  1. @DV-JF Hm, good question. The module builds on the base Inputfield class provided by ProcessWire, so it's built around being used inside a ProcessWire form context. I'm not actually sure how to execute the input validation on itself. That said, all you need to do is create an instance of the module and then execute the ___processInput method. This method expects a WireInputData object that you can get from $input->post(). The method will validate the hCaptcha response and add errors to the module instance, if any. So something like this *might* work: $InputfieldHCaptcha = $modules->get('InputfieldHCaptcha'); $WireInputData = $input->post(); $InputfieldHcaptcha->processInput($WireInputData); $errors = $InputfieldHCaptcha->getErrors(); $hasErrors = !empty($errors); But I can't test this code right now and I haven't done something like this before, so I'm not sure if it's the right approach. If it doesn't, maybe ask in the FormBuilder support area. Ryan knows way more about this ^^
  2. InputfieldHCaptcha 1.0.4 I just pushed an update that fixes a typo in the default error message for a missing captcha response. If you're using this module and have added translations for the module's messages, make sure to update them to match the new source string! More information in the changelog
  3. @horst I think I've found a small bug in the module, could you take a look if you've got time? Thanks! https://github.com/horst-n/AdminLinksInFrontend/issues/2
  4. You have a couple of options: You can create the required fields (and templates, if any) programmatically in the install() method of your module (see the documentation). Creating fields through the API is pretty straightforward, though you might have to dig a bit to find the properties you need if you want to customize the field's settings. In this case, you should probably also handle removing those fields in the uninstall() method so your module can be uninstalled cleanly (make sure to warn the user that uninstalling the module will remove all of it's data in this case!). The benefit of creating regular fields in your module is that your module's data can be managed through ProcessWire's regular interface, and you don't have to provide your own custom interface for simple CRUD operations. An approach that might be better suited if your module is targeted at developers is to make the fields to be used for storing data configurable. You can build module configuration options to let the developer select which templates and fields are used to store the data your module uses. Though this doesn't work for every use case. Finally, you can bypass regular fields entirely and store your module's data seperately. The advantage of that is that it's easy and quick. The downside is that you will have to provide your own interface for displaying and editing your modules data. Of course, that doesn't apply to every module – for example, you wouldn't need an editor interface to edit a user's cart. But if you store completed transactions, your module users will probably expect an interface to list (export, edit, delete, ...) all transactions, at which point you would have to build your own interface for that. Where you store the data is up to you: In the session or cookies (only for ephemeral data, like a cart). In a page's meta() data. I do that in some of my modules, see my post here. You can also use a custom database table for more elaborate storage capabilities. Again, you would use the install() and uninstall() methods of your module to create and (optionally) tear down your custom tables. See this post for some examples. Personally, I prefer modules that adopt best practices of the system they're build for – in the case of ProcessWire, I'd say it's best practice to create regular fields and templates instead of custom tables. But the ultimate answer is – as always – "it depends".
  5. You're confusing variable type and object classes. gettype() returns the type of a variable, i.e. string, int, object etc. If you want to know the class, use get_class(). Note that this will return the fully qualified classname, i.e. ProcessWire\PageArray. If you want to get the classname without the namespace, you can also use Wire::className, which is a method available on all classes extending the Wire class (so pretty much all ProcessWire classes). This one gives you only the classname with the namespace by default: $somePageArray->className(); // PageArray
  6. @3fingers No that's actually correct, I'm checking the class of the formatted values there, not the class of the fieldtype. For example, for an image field, the $value will be an instance of Pageimage or Pageimages depending on the formatting settings, but the $type will be an instance of InputfieldImage. In fact, the $type variable is not needed at all. In the first version I started by checking the $type, but turned out checking the $value directly was more efficient. Though you could do it both ways. That would only work if you're working with field objects, not formatted values. The formatted value of a text field will be a string, so accessing $value->type will result in an error. The code you linked is slightly different since it iterates Field objects, not field names: // iterate over Field objects // @see https://processwire.com/api/ref/field/ foreach($this->wire('fields') as $field) {} // iterate over field names (strings) of fields on a page // @see https://processwire.com/api/ref/wire-array/each/ $fields = $page->fields->each('name'); foreach ($fields as $field) {}
  7. @Hector Nguyen Functions can't be autoloaded in PHP. Two options to work around this: Put the QFramework\Function function in a class as a static method, then the class can be autoloaded. Add all files containing functions in the autoload files list in your composer.json. This way those files will be included on every request.
  8. @AndZyk Alright, I had some fun with it. Here's an improved script for the asset export, which can handle nested repeater and matrix repeater fields: /** * Get a flat array of all images on the given page, even in nested repeater / repeater matrix fields. * * @var Page $page The page to get the images from. * @return Pageimage[] Array of Pageimage objects. */ function getImages(Page $page): WireArray { $images = new WireArray(); $fields = $page->fields->each('name'); foreach ($fields as $field) { $value = $page->get($field); $type = $page->fields->{$field}->getFieldType(); if ($value instanceof Pageimage) { $images->add($value); } elseif ($value instanceof Pageimages) { $images->import($value->getArray()); } elseif ($value instanceof RepeaterMatrixPageArray || $value instanceof RepeaterPageArray) { foreach ($value as $repeaterPage) { $images->import(getImages($repeaterPage)); } } elseif ($value instanceof RepeaterMatrixPage || $value instanceof RepeaterPage) { $images->import(getImages($value)); } } return $images; } $images = getImages($page); // create target folder for the page assets $targetDir = $config->paths->assets . 'export/' . $page->name . '/'; $files->mkdir($targetDir, true); // move all images to the target folder foreach ($images as $image) { $name = $image->basename(); $target = $targetDir . $name; $src = $image->filename(); $files->copy($src, $target); } This could be extended in any number of ways: Handle file fields as well as images. Handle any other fields and dump them in the target folder as JSON. Handle native Page properties. At some point you got a complete page export module. Might want to look into the pages export module if you don't want to write all that stuff yourself 🙂
  9. What do you want to achieve? Do you want to get all images for a project out of the system to use them externally? Or do you want to restructure how/where ProcessWire saves images in general? For the first case, you can write a little script to iterate recursively through all fields, including any repeater / repeater matrix sub-fields, to get an array of images. Then you can use that to copy all the images to one folder (using $files->copy(), for example), get a link of filenames (see Pagefile::filename()) or do whatever you want with them, like export their meta data as JSON or anything else. Super quick and dirty, will probably not work right away, but you get the idea: function getImages(Page $page): array { $images = new PageImages; $fields = array_map(function($field){ return $field->name; }, iterator_to_array($page->fields)); foreach ($fields as $field) { $value = $page->get($field); $type = $page->fields->{$field}->getFieldType(); if ($type instanceof FieldtypeImage) { $images->import($value); } elseif ($type instanceof FieldtypeRepeater) { $images->import(getImages($value)); } } return $images; } $images = getImages($page);
  10. Don't overthink it. You're gonna need a way to reference a specific field anyway. Hiding the name away behind a constant, config or whatever isn't going to change that. If you're worried about changing field names, you should instead invest the time to find better names for your fields. Why would your field names change? Probably because the data they hold or the thing they represent have changed - both of those cases will require adjustments in the templates anyway. I've never understood the benefit of "hiding" a property or method name behind a constant. I mean, what are you gonna do if the field name behind it changes? Let's say I have the field field_for_thing_a and use a constant FIELD_NAME_THING_A to hide the dirty, dirty field name string behind a nice, verbose constant. Now I need to rename the field to field_for_different_thing_b. Am I just gonna leave the constant in place? So FIELD_NAME_THING_A now references something completely different? No, I'm gonna rename it, in which case I could just find+replace the name of the thing itself and will introduce a BC break anyway. But if the field needs to change, it's not backwards compatible anyway. The only backwards compatibility I'm maintaining at this point is unreadable cargo cult code 🙃 Of course, there are exceptions. Depends on what you're building. If you're talking about a module which might need to access a user-defined field, by all means, store the field name in a variable (it's gonna be pulled from the database anyway if it's configured in the module settings). Maybe I'm way off base here. What problem are you actually trying to solve? Maintainability is a spectrum and doesn't exist in a vacuum. What maintenance burden do you want to avoid?
  11. @adrian Awesome, thanks for the fix adrian, you're my hero 🤩 Didn't know about the OPT + Enter shortcut, that's handy indeed! I removed the snippet through the Console panel, that bit worked fine, I guess the problem was just the shortcut trying to load a snippet after it had been deleted. Anyway, thanks again!
  12. Hi @adrian, I'm having a small but annoying issue with the Console panel in the debug bar. I'm using the Console to quickly try out code snippets, so most of the time I enter some code and hit CMD + Enter to run it. I've rarely ever used the option to save snippets on the right side. Now I tried to save a snippet which somehow broke the CMD + Enter shortcut. After saving a snippet, hitting CMD + Enter always wipes out whatever I have entered in the code input and restore that snippet from disk, instead of running the code I entered in the code input. Clicking the "Run" button above the code will execute the code I entered normally, it's only the keyboard command that's not working. So I tried removing the snippet and clearing the "Enter filename" input on the right. Still, after entering some code in the code input and hitting CMD + Enter, it will still try to load the (deleted) saved snippet from disk – I can see an error in the debug bar: PHP Warning: file_get_contents([...]/site/templates/TracyDebugger/snippets/new.php): failed to open stream: No such file or directory in .../includes/ConsoleSnippets.php:16). Since the snippet file does not exist, it will wipe out the code I entered in the Console window completely. Am I doing something wrong, or could this be a bug in the JS code handling the keyboard shortcut? I don't need the snippets, I just want to CMD + Enter Shortcut back to execute the code I entered in the Console window ^^' Thanks!
  13. Quick tip: Displaying hCaptcha in the correct language By default, hCaptcha displays its interface in the visitor's browser language, which means it may differ from the current language of your site. You might want to change that to always use your site's language, or the current language if you have a multi-language site. You can use the hook InputfieldHCaptcha::getScriptOptions to adjust the language of the hCaptcha interface dynamically. Here's a snippet with a couple of options for setting the language: // site/ready.php wire()->addHookAfter('InputfieldHCaptcha::getScriptOptions', function (HookEvent $e) { $options = $e->return; // option 1: for single-language sites, you can just hardcode a specific language $options['hl'] = 'de'; // option 2: for multi-language sites, you can use the translation api $options['hl'] = _x('de', 'hCaptcha Language'); // option 3: you can also add a custom field to your language template to hold the language code $options['hl'] = wire('user')->language->language_code; $e->return = $options; }); For option 2, make sure to add a translation for the language code in every language. For option 3, first set $config->advanced = true in your config.php so you can edit the language template. You have to create the language_code field yourself and add it to the template, then set the language code in each of your languages. For all options, make sure to use the correct language code as listed here.
  14. Thanks @adrian! Sorry I forgot to mention the versions ^^ The site I ran into this problem is still on PHP 7.4, but the update fixed the problem nonetheless. Thanks for the quick response!
  15. ProcessCacheControl version 1.1.0 released I just released an updated version of this module which fixes some issues with the asset version management feature. In particular: When using CacheControlTools::getAssetVersion while no asset version existed (for the specified category), the implicitly generated version incorrectly expired after one day. This is now fixed, so asset versions will not expirate anymore until manually cleared. Asset versions are no stored using WireCache::expireNever instead of WireCache::expireReserved. This means they will be deleted when using $cache->deleteAll(), when previously you had to explicity specify them by namespace to clear the cached versions. Links: Full changelog for version 1.1.0 ProcessCacheControl in the modules directory
×
×
  • Create New...