All Activity

Just dropped the latest/3.0.219 into a local dev instance and was greeted with this: Besides my gastro modules nothing makes sense here (for me) and I can't find the source of this issue. Unfortunatelly moving back to another version of ProcessWire didn't solve the issue. I had to import an older version of the database as well.

@PhilR I can understand why LimitRequestBody 0 may solve this issue for you - but it sounds like you needed to also set the SSLRenegBufferSize for a file upload to work - is that right? If so, I wonder why that was needed. What kind of sizes were the files you were uploading?

I had issue with uploads and found adding to .htaccess in the root under section 11F resolved all upload issues for me LimitRequestBody 0 SSLRenegBufferSize 50242880

If you upgrade to 3.0.219, grab the latest commits, as the commit labeled "Bump version to 3.0.219" still had a couple of issues that I ran across since then and have fixed. (The issue may have originated in 3.0.218 or 3.0.217 actually). It was primarily "class not found" errors, and I didn't notice at first because the errors didn't appear when doing minor version upgrades and instead would appear when upgrading older versions to 3.0.219.

@thetuningspoon @cb2004 Try the most recent dev branch commits. The "class not found" error at least was coming from upgrading an older version of PW that had certain modules in different parent directories. For instance, /wire/Fieldtype/FieldtypeFile.module was moved to /wire/Fieldtype/FieldtypeFile/FieldtypeFile.module many versions back. But if upgrading from that older version (that had the file in a different location) to 3.0.218 then you'd see this error. At least, that's the issue I ran into (and fixed) here.

Hi @fruid, Just to be clear, "media_manager_image" is an internal native ProcessWire field of type FieldtypeImage used by media manager to store media items that are of type image. Its value is a Pageimages object. Back to your issue, mmfield should be a Media Manager field of type FieldtypeMediaManager. Its value is a MediaManagerArray. A MediaManagerArray contains one or more MediaManager objects. This is analogous to a WireArray can contain several objects of type WireData. All these work for me. The value of $image here is a single object of type MediaManager. What do you get when you dump $image using Tracy? Screenshots test_1_media_manager is equivalent to your mmfield.

I know a media_manager_image field is always an array so I need to loop through it. But can I access a specific image given the key? I tried: $image = $page->mmfield[3]; $image = $page->mmfield->get(3); $image = $page->mmfield->eq(3); none of those work ;(

@netcarverThanks for your reply. Will most likely deactivate Cookies in frontend, unless you are in admin/backend, or the user checked the confirmation in the frontend form to use CSRF protection. Most likely in combination with a user consent module asking for permission. Your posts and links helped a lot to understand the background to get things done.

@zx80 Check out the $sessionAllow options in the config.php file. The outline config.php in the wire/ directory documents all the options and outlines how to turn off guest-based session cookies using a callable. This isn't exactly what you asked about but might be a starting point. I use this method to create a cookie-free public interface on the site I posted about the contact form before. No cookie banner because there are no cookies at all unless you are an admin and know where the admin interface is.

@flydevThanks a lot. Exactly what I searched for. Will try to play around with those settings. Regarding lawyers. Interesting post, but stuff may differ in Germany. The lawyer of the company I am working for has a completely different view of what Cookies are technical required and what Cookies are not 🙂 Cheers.

Hi, this and this If you want a short and clear preview of lawyers insight of a really big company (website hosted in United Kingdom), check the cookie policy of this Engie website: https://www.fhc.co.uk/en/about/cookies-policy/

Hello all, is there a way to prevent the creation of the Processwire frontend Cookie wire until the user has confirmed/opt-in to allow technical required Cookies? Not too sure, if the wire Cookie is technical really required for PW to do it‘s job (show frontend stuff, remember layout etc.). In Germany it‘s still a bit fuzzy, what technical required means to a lawyer. So ideally there shouldn‘t be set any Cookie without opt-in by the frontend user, unless it is really technical required. Can anybody shine some light on this aspect? For what is the wire Cookie used in the frontend layer, or in other words technical required by the PW frontend? What parts - except admin/backend - of PW wouldn‘t work without that cookie? Looking forward for some hints on that topic.

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?

This seems to through namespace related errors in the latest dev version (3.0.219) Perhaps something related to the modules rework?

Super! Need to keep everything in order. A Higher Order of Perfection, nothing less)

Hi @Spinbox, Please see the example in demo-2 of the Padloper 2 Starter Site repository. This is for when you want to save the extra form inputs at the checkout form stage. In summary: Add your extra fields to your checkout form In ready.php use a hook to listen to PadloperProcessOrder::orderSaved as shown here in demo-2. In the hook function, process the newsletter signup checkbox. It should be in $input->post('name_of_your_checkbox') Save that to your backend field where you are saving customer signups. In this hook you have access to $orderPage. This will give you access to $orderPage->padloper_order_customer. You can grab the customer details from there if you need them for your signup. Given that you might have repeat customers, you might not want to save the customer signup details with the order itself since this will mean saving the same information with each order for this one customer. Secondly, you might want to check if the current customer has already signed up for the newsletter. You can do this in the checkout form using htmx (ajax). I.e, after they enter an email address, htmx sends ajax request to your server. In the backend you check your signup records. If customer already signed up, do nothing. Else send back html with checkbox markup for htmx to insert in your checkout form. If you instead want to do the signup request in the next step when collecting payment, let me know and I'll tell you where to hook. This only works for the current order in the session and only for the customer details that Padloper knows about, i.e. not your custom ones.

Hey @alexm, Cool idea. Given that people will have different needs on what extra information to capture for invoice payments (or indeed other payments or just general customer info), I am inclined to let devs implement this per their needs. The implementation would be similar to the custom fields example in demo-2. Thus: Display inputs for bank details in your checkout form. If only accepting invoice payments, always show the fields and make them required. If accepting other payment options, toggle-show the bank details inputs (e.g. using Alpine.js) In ready.php listen to PadloperProcessOrder::orderSaved as shown here in demo-2. Use that to save capture and save your bank details. Save those to some field(s) you have added to the template padloper-order. You have several choices here, e.g. multiple text fields, or a repeater matrix or a multiplier text field, etc. You could even get away with a single textarea since this is not a field you will need to query in the frontend. If user continues to shop after the first checkout attempt, you can use $order-your_bank_details_field to show them the bank details they entered when they first attempted checkout. It would be best to check if there is a valid Padloper session before doing this. Perhaps best just to let them re-enter the bank details though. To display the bank details in the backend, there are several places you can hook into in the single order view depending on where you want to display the info. To show the bank details on the invoice, copy /site/modules/Padloper/templates/invoice-content-html.php to /site/templates/padloper/invoice-content-html.php and edit per your needs. This template will receive the Page $order. That will give you access to $order-your_bank_details_field. Would this work for you? Lemme know.

I'll see if I can include his in the next version of Media Manager. My current thinking is that I'd add an extra column/subfield to FieldtypeMediaManager.

Hi @fruid, I am totally confused by this 😄. When editing a media item (i.e. inside media manager), you are editing the page where the media item lives. In the case of an image, the image is in a normal ProcessWire image field. So, the description, tags, cropping, etc are all native ProcessWire inputs and functions. Yes it is.

Hi @joshua Thank you for what looks to be a great module and excellent support. I'm hoping to get some pointers from you as PrivacyWire isn't working as expected on my website somehow. I'm on PrivacyWire v1.1.2. and checked the 'active' checkbox in config screen. The module is loading fine, and I'm getting the banner allright - but no element is stopped from loading at all! On my test page , no matter what i try, i still get to read "This script only runs after giving consent to functional cookies" in my console! But I haven't given consent. All assets seem to be loading fine: <head> <style>.privacywire{background:#fff;bottom:-250%;box-shadow:0 -1px 3px rgba(0,0,0,.3);left:0;opacity:0;padding:1rem;position:fixed;right:0;transition:bottom .3s ease-in,opacity .3s ease;z-index:1}.show-banner .privacywire-banner,.show-message .privacywire-message,.show-options .privacywire-options{bottom:0;opacity:1}.privacywire-header{font-weight:700}.privacywire button[hidden],.privacywire-ask-consent-blueprint,[data-ask-consent-rendered="1"]{display:none}</style> <script>var PrivacyWireSettings={"version":2,"dnt":"1","bots":"1","customFunction":"","messageTimeout":2500,"consentByClass":"1","cookieGroups":{"necessary":"Necessary","functional":"Functional","statistics":"Statistics","marketing":"Marketing","external_media":"External Media"}};</script> <script type="module" src="/site/modules/privacywire/js/PrivacyWire.js"></script> <script nomodule="" type="text/javascript" src="/site/modules/privacywire/js/ie_polyfill.js"></script> <script nomodule="" type="text/javascript" src="/site/modules/privacywire/js/PrivacyWire_legacy.js"></script> On the page in the <body> i've put the example script <script data-type="text/javascript" data-category="functional" class="require-consent">console.log("This script only runs after giving consent to functional cookies");</script> and in the console the message shows. Then: when i give consent- it shows up again in the console! I'm lost on what to do and how to figure out what i could be doing wrong... Any help would be much appreciated!

ProcessWire 3.0.219 on the dev branch focuses primarily on a major overhaul to the core $modules system. The Modules class had grown into more than 5000 lines of code — all related to modules, but with lots of different areas of focus within that. It had become a little bit messy, fragile and hard to maintain at that size. I've had @todo notes in the class to "clean it up" for quite awhile, but this week I finally got to it. The approach is similar to that of our $pages API (Pages class), which is split into separate classes for page finding, loading, editing, caching, etc. The Modules class has been split into several much more focused classes for module information, installers, loaders, files, flags, duplicates, and configurations. This leaves the main Modules class as the gatekeeper, making it less fragile and easier to maintain. If this overhaul was perfect, you shouldn't notice any difference, and the public $modules API remains as before. But with such significant overhaul that took a full week to complete, there's also an increased potential for temporary errors, so please let me know if you encounter any. Thanks for reading and have a great weekend!

date - Documentation - Twig - The flexible, fast, and secure PHP template engine Says here you can change Twig’s default date format like this: $twig = new \Twig\Environment($loader); $twig->getExtension(\Twig\Extension\CoreExtension::class)->setDateFormat('d/m/Y', '%d giorni'); And format individual expressions like this: {{ page.created|date("d/m/Y") }} But to get Italian words like ”giugno“ or “venerdi” you’ll probably need something called “Twig Intl Extension”: https://stackoverflow.com/a/75572704

I'm using TwigTemplateEngine for an Italian website, but I get always English dates for `{{ page.created }}` code. I installed the Languages Support module, Languages, Italian Language Pack, used `setlocale('LC_TIME', "it_IT")`, `setlocale('LC_TIME', "ita")`, and the various combinations with LC_ALL, but no. How can I output an Italian date on the page? Thanks!

Thanks for the suggestion - tried this, does not solve the issue. The homepage delivers the default language only; I have typically made a different page for the homepage in other languages (subpage with url /fi/ for example).

Actually the cached files are cleared if they are expired but only through a LazyCron: (from the ProCache’s page) In other words, if you still have apache running and your database is down, you should not have to worry, so long as your website is fully cached.