Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/28/2024 in all areas

  1. Page sure does have a changed() method. https://processwire.com/api/ref/wire/changed/
    2 points
  2. Hey man, I coined that term! (patent pending! j/k) I would really love to hear your Laravel/ProcessWire experience and comparison in terms of web application development. I too have been working on a very large webapp with ProcessWire over the last 6 months using ProcessWire, Alpine and HTMX (no need for Tailwind since it's completely admin side, although I did nearly completely develop AdminThemeBootstrap as an experiment during this project which I may or may not use in the future on it).
    2 points
  3. Hey all! This is a module to enhance forms built using the Pro FormBuilder module by providing the ability to submit them in place using AJAX and HTMX. FormBuilderHtmx works in harmony with FormBuilder by handling front-end rendering and AJAX and lets FormBuilder manage form configuration and processing. FormBuilderHtmx provides a drop-in replacement for the $forms->render() method and provides all native features and behavior (and adds a few extra superpowers to boot). Noteworthy features: Zero configuration, install and render AJAX powered FormBuilder forms immediately Render multiple forms on the same page. Supports both multiple instances of the same form or different forms. Each form is processed independently. Non-intrusive, can be used alongside FormBuilder's native rendering methods and does not modify core module behavior Perfect for forms embedded in popups and modals Does not conflict with styling and other JavaScript already in-place, only handles the form submission/response loop Automatically disables the `Submit` button on submission to prevent duplicate requests Provides the ability to add a custom 'spinner' shown when a form is being processed Gives you the ability to add additional HTML attributes to your FormBuilder <form> element. Add additional custom functionality using HTMX attributes, hook into form actions with your JavaScript, or even add AlpineJS directly to your forms. Compatible with FieldtypeFormSelect, let users choose which forms to embed, your code determines how they are rendered Uses HTMX, a stable, powerful, and tiny (14kb gzipped) library, installation documentation available here This module is BYOH (Bring Your Own HTMX) in that the HTMX library is not included or available within this module. This ensures long-term stability by not locking FormBuilderHtmx to external asset versioning. FormBuilderHtmx uses stable core HTMX features so use the library version that works for you and confidently add this module to both new, existing, and future ProcessWire applications. In some instances CSRF protection may need to be disabled to submit forms with this module. Just test your forms and you're good to go. Using this module is truly easy. <!-- Replace the native $forms->render() method with $htmxForms->render() --> <?php $htmxForm = $htmxForms->render('your_form_name') ?> <!-- Use native ProcessWire properties and methods as usual --> <?php echo $htmxForm->styles; echo $htmxForm->scripts; echo $htmxForm; ?> Presto. You can optionally include a helpful 'spinner' or activity animation that will be showed to users while their form request is being processed. Check out these ready-to-go examples you can use in your projects. <style> /* Add these styles to your CSS, the `.htmx-request` must be present as shown here. Be sure to include any CSS your 'spinner' may need, and style everything as desired */ .activity-indicator { display: none; } .htmx-request .activity-indicator, .htmx-request.activity-indicator { display: block; } </style> <!-- Optional second argument matches that of the $forms->render() method for pre-populated values The third argument is the CSS selector matching your 'spinner' element --> <?= $htmxForms->render('your_form_name', [], '#indicator-for-the-form') ?> <div id="indicator-for-the-form" class="activity-indicator"> <span class="spinner"></span> </div> Presto (again) Check out the documentation for detailed usage and other available features. Pull requests and issues filed on Github are welcome, or drop by here to get some help! Install as a ProcessWire module Install using Composer Download from the FormBuilderHtmx Github repository . Cheers!
    1 point
  4. This week on the dev branch are a few updates to the core including the following: Support for Inputfield header icon actions defined in PHP. If you recall, a couple weeks ago we released header actions for Inputfields via the JS Inputfield API. Robin S requested that the same be available from the PHP Inputfield API, and now it is. More details can be found in the phpdoc for the Inputfield::addHeaderAction() method here. New link action was added to Inputfield header actions. This was also added by request and it's another type of header action that simply links to a URL. It can optionally be opened in a modal window. The $database API variable has been updated with a new $database->reset() method which resets the database connection. This is potentially useful after a "MySQL server has gone away" type error, to re-establish the connection. The $database->execute() method also now uses it to attempt to reestablish the connection (for a few tries) when appropriate. Though I've not yet been able to test this one with an actual lost connection. There were various other minor updates, optimizations and fixes this week as well. In addition to the above core updates, we've got a new version of the UserActivity module (v8) posted in the ProDevTools support board. This version adds support for the PageEditChildren module and can properly identify which child pages are being edited alongside the parent. Previous versions only identify the page open in the page editor, and not the children open in PageEditChildren. Thanks for reading, have a great weekend!
    1 point
  5. This is more just a reminder post than a problem post. If you have been having issues building UIKit from more recent repos it may be because the math setting in the currently used LESS.php wikimedia version is a bit greedy. Even after setting the 'math' => 'strict' option in the $less object it still gave an 'Operation in invalid type error'. I forgot that I needed to modify two files in order to get this to compile. base.less and article.less have two variable calculations that need to be quote escaped. Basically you need to turn this: @base-h1-font-size-m * 0.85; into this: ~'calc(' @base-h1-font-size-m ~'* 0.85)'; No matter how many times I write this someplace I forget that it needs to happen. So I am saving it here for the next time I desperately search for it.
    1 point
  6. but but but we told you to try with the same env, anyway glad to hear it's solved, this type of issue kill a kittie each day.
    1 point
  7. @bernhard I did try to use it at one point. I remember that it wasn't compatible with how DeepL required it's URL parameters to be structured. I think it was the way that it had multiple GET variables with the same name and that didn't serialize properly when using WireHttp. That may be a moot point now because the DeepL API now accepts JSON encoded POST requests so that URL issue isn't a problem. Prior to that I ran into an issue with WireHttp not handling 404 responses in a way that I need to rely on, so it isn't generally top of mind. Long story short, if a 404 is returned, WireHttp will ignore that valid response and try again. As an aside- I'm working with an API right now where 404 is a valid response for a record that doesn't exist, so trying 2x doubles the API credit usage with that service. May or may not be an issue in this instance, but it is something to keep in mind when HTTP requests have a hard cost associated with them.
    1 point
  8. @FireWire have you considered using WireHttp for the requests?
    1 point
  9. @theoreticHey there- we figured out the issue on Github but wanted to mention here for others as well. Fluency uses CURL to make API requests to the translation service so that is required to be present on the server. I'll note this in the documentation on the next release as a requirement for the module since it's possible to use ProcessWire and never need or use CURL. Good catch and thanks for the report!
    1 point
  10. Oh yeah? PATH is so *checks date of tweet* last year. The new stack is PHAT. "Whats the difference between PATH and PHAT" "Nothing, but one is going to appeal to kids from the 90s" My takeaway, and why it's relevant to devs here in the forum, is that ProcessWire is the right choice for a lot of situations. Side by side comparisons implementing the same thing in each platform makes an objective case for both and, from a technical point of view, my application could have been built in ProcessWire. Heck yeah. If/when possible, posting a case study here in the forum would be a great read!
    1 point
  11. Okay... Doublechecking it was in RepeaterMatrix items only. Nested maybe 3 deep. I will play around with it later this week if it doesn't affect you and I'll let you know if I find anything related to the module. I need to dig into how I can alter the pwimage selector in front-end editing to grab the imagefield from the item in a repeater field and not from the page where the repeater field is anyway so I will dig into that as well.
    1 point
  12. @kuba Most likely this week.
    1 point
  13. I can confirm that it is working now as expected when using the native datepicker.
    1 point
  14. Hello @Stefanowitsch I have updated the module and it should work now as expected. I have not the time to test all possible scenarios now, but I could not discover any problems on my local setup. For more information about the problem read the changelog.md. Please test it, if it works for you now. Best regards Jürgen
    1 point
  15. I think I may have identified the problem with the 'getFresh'. It seems that PageAutosave was turned on. I have refined the module settings to only use it for certain templates. I guess it saves with ‘no hooks’ so it wasn’t showing up. I’ll check it out more thoroughly in the morning. UPDATE. I can confirm that the problem was caused by having autosave inadvertantly turned on (+ not realising that it suppressed hooks). This was not helped by the editing taking place in a modal, so it was not obvious. I assume that initially it was turned on in the live environment but not in the dev. The problem was intermittent because, if you hit 'save' quickly enough it does the user-initiated save before the autosave. One to watch!!
    1 point
  16. @Robin S I ended up using boot.ini to extend PW's class loader early enough to allow traits to be used in the UserPage class. More on this here.
    1 point
  17. Hi everyone, This new video fieldtype extends FieldtypeFile. Video is available via: $page->video_field->url Module automatically creates a poster image of the video on upload and makes this available via: $page->video_field->poster Shows the duration of the video on the title bar, next to the filesize Stores VTT files for subtitles accessed via: $page->video_field->subtitles Formats a transcript from the subtitles, accessed via: $page->video_field->transcript Users can easily upload videos and enter VTT files. The following code is used in the template file. <video src='{$page->video_field->eq(1)->url}' poster='{$page->video_field->eq(1)->poster}' width='720' height='408' ><track kind='subtitles' src='{$page->video_field->eq(1)->subtitles}' srclang='en' /></video> Additional Settings You can additionally set a few different options in the field's Input tab: Number of poster images to generate - if you change from the default of 1, the editing user will be able to select which image they want to use for the poster image Copy poster image to dedicated image field - not necessary but gives you more options of interacting with the poster image(s) Field that you want poster images copied into - only relevant if the option above is checked Try it out (NB: the code is rough - it works, but needs cleaning up. Github: https://github.com/adrianbj/FieldtypeVideo NB: Requirements The module requires ffmpeg and ffmpeg-php, although I can make the latter optional fairly easily. I don't have any requirement checking implemented yet, so if you don't have these, you'll get php errors. Possible future enhancements Ability to specify what frame is used for the poster - either by number, and/or by offering several options to choose from Done! Push poster image to a dedicated image field Done, although could be improved Field for pasting in or uploading closed captions Done, but need to look into multi-language options etc Support for uploading multiple formats of the same video (mp4, webm, etc) and/or automated video format conversion My biggest concern, is how useful this will be to people - how many hosts actually have ffmpeg setup? Do any have ffmpeg-php? Anyone have any ideas for features they'd like to see?
    1 point
  18. Would be nice to update the Fontawesome icons in PW core, so they can be used for labels in the backend. The current version 4 is quite old and has a very limit set of icons. Version 6 also has a free version with more icons. The implementation seems to be very similar, so it should be easy to implement. The icons can be downloaded here.
    1 point
  19. You could ask Ryan to update Font-awesome (on GitHub).
    1 point
  20. Maybe try markdown syntax [Title](http//:…/). This at least works for the description/notes.
    1 point
×
×
  • Create New...