Leaderboard

This module allows you to select fields that get anonymized after a defined period of time. Anonymization refers to either replacing field values with a configurable fill word, or removing stored data altogether. The time period after which page content gets anonymized can be configured (default is 60 days), and anonymized fields can be selected manually via module config screen. Behind the scenes LazyCron is used to trigger the anonymization process, which makes the whole process completely automatic. The module was developed for a client that handles job applications. The software we developed required to anonymize personal identifiable data after a specific amount of time, if the applicant did not get the job, according to the law DSGVO. There might be other uses, where this module could come in handy. Thanks @teppo for mentioning it in ProcessWire Weekly #393. I hope you don't mind, that I copied the description from your site? You can find the module at https://github.com/jmartsch/AnonymizeFields and in the modules directory at https://processwire.com/modules/anonymize-fields

Hello at all, I am struggeling about a fast method to get all language translation CSV files of fe a module and merge all these files into 1 CSV file. I do not want fe 10 CSV translation files for a module. So I want to merge them all into one. All translation files for a site module are stored in site/assets/idoftheModule/... as json files. These translation files can be downloaded, but they are in json and not CSV format. I know I can do it one by one in the backend, but this is not my goal. Does anyone has done this before and could give me a hint, what ist the best and fastest way to 1) dowload all CSV files of a module at once and 2) merge them all into 1 CSV file. Thanks in advance

Doh! Thanks for making me think @kongondo. Re-reading the docs, it is clear that there should be no difference between -> and get(). That is, unless you have inadvertantly declared a property with the same name as a data item..... ?

In case you use Neovim/VIM you can still use this VSCode extension through coc-snippets.

Just checking that you expressed an interest? Wow! From performance side of things, that's still fine as each individual combination (variant) is not a page in itself. From a UI/UX point of view though...that can be a nightmare. I wonder if some sort of grouping is possible? i.e. creating configs for similar products. Maybe not worth the effort though as you can use the inbuilt pagination and search on the variations table. You should still be able to. However, I am not sure how your setup looks like. This confuses me: Usually, a single product would have more than one variation, e.g. Red Small, Black Large, etc. However, it is also possible for a product to have one variation/variant only. The key thing here is that a one-to-many relationship is still assumed. The usual setup would be like this: Product A variant 1: Red Small variant 2: Black Small variant 3: Black Large In your Invoice Page, if you have Product A selected, you have access to all its variants (1, 2 and 3). Assuming you have a variations field inside Product A called catalogue, then you can access Product A variations like so: <?php namespace ProcessWire; $productA = $pages->get(1234); /** @var VariationsArray WireData $productAVariants */ // VariationsArray -> WireArray $productAVariants = $productA->catalogue; Since $productAVariants is a WireArray, you can use get() and find() on it like any other WireArray. E.g. <?php namespace ProcessWire; // find variants in Product A whose colour is 'Black' $productABlacks = $productAVariants->find("colour=Black"); // find variants in Product A whose colour is 'Blue' and 'Price' > 5 $productABlues = $productAVariants->find("colour=Blue,price>5"); Again, I don't fully understand your setup so I may be way off base here, but happy to help if I can see an illustration, screenshot, etc. Ahem... It has been a minute and a number of things had to change. This will be explained in due course but I can only say that we have the best of several worlds with the about to be released Padloper 2 Alpha/Early Beta ?. All will be revealed in due course ?.

@kongondo I'll end up scrapping this setup once PadLoper is ready in the long run as I know it doesn't use pages now. So this is only a bridge really and there is no need to part with too much of your time considering this if it simply isn't straight forward. Thank you for your time.

@kongondo thank you for that. That means my set up is the best setup based on the way it works! Great work by the way!! ? I saw this in the product video demo way back! Great job again. Looking forward to hopefully testing alpha, if you approve and supporting the amazing task you've undertaken as and when purchasing is available. e.g. One has 396 variations Table not PageTable. Effectively I'm using it to create a kind of invoice page and the table acts as the items to invoice. I have a PageReference field which grabs a product. It would be awesome to be able to either, grab the product variation (though they aren't I understand that they aren't pages, so that is ruled out), then I could grab the associated information such as sizes and colours available. Then I thought that perhaps another way would be to grab the available variations for a Referenced page in the PageField and then output a dropdown of options to make it easy to pick. To be honest though, it's not a whole lot of effort to just type XL and Blue in 2 text fields failing there being a solution that you can see.

Hi @alexm. Many thanks for the purchase. No, you don't. You can (as you have found out) use the same Variation configuration multiple times. For example, a 'Catalogue' variation configurations made up of colours (black, red, green) x sizes (small, large, tall). However, currently, Variations does not allow you to remove / hide unavailable combinations (e.g. small / red). That is the way to do it. I'll have a think about how this can be improved. For instance, for some products, the seller would know that some combinations would never exists for that product, e.g. green x large is (silly example, maybe) never available for this product. In such a case, they may want to delete the combination altogether. On the other hand, it is better in many cases to readily see what is and what is not available. In some cases, unavailable might become available in the future. Hence, making it available is easier if the combination is still visible in the UI. Incidentally, in Padloper 2, variations are inbuilt and allow you much more control. You are not tied to one configuration and can either delete or disable a variant. There shouldn't be. How many colours / sizes combinations are you generating? I haven't tested with Table. Are you talking about Table or PageTable, by the way, given that they are different modules? I am not sure I follow the question as well. Please clarify the field on the PageTable. Docs, just in case you didn't see them. Thanks.

Thanks again for providing this module and keeping it up-to-date. This module is so useful for me.

https://processwire.com/api/ref/wire-data/ ?

Yes, it is a Pro Board (VIP Support) for Padloper 1. The topic in Dev Talk that I referenced is an identical announcement to the one in the Pro Board.

In that case, the most straight forward approach is to add a custom permission through the backend (e.g. 'import-pages'), hook before your module's execute method and check if the current user has this permission. Untested code for site/ready.php: <?php namespace ProcessWire; wire()->addHookBefore("ImportPagesCSV::execute", function(HookEvent $event) { if(wire('user')->isSuperuser() || wire('user')->hasPermission('import-pages')) return; $event->return = '<h3>You do not have permission to import pages. Please contact the administrator!</h3>'; $event->replace = true; }); Of course, this still leaves the backend menu item in place, but unlike modifying third party modules, it is upgrade safe.

I think I've found a fix for this. Please update to v0.3.3 and let me know if that version resolves the issue for you.

Apologies, I forgot to announce this topic here. Just cross-referencing this announcement/call for testers: Please note the expression of interest was to close yesterday (Friday 19 November 2021). However, the deadline has been extended until Monday 22 November 2021 to accommodate those who would have expected an announcement here. Apologies again.

It is a bit "hidden" but somewhat documented over here: https://processwire.com/docs/security/file-permissions/#securing-your-site-config.php-file Quote: "This includes /site/assets/ and everything within it, as well as /site/modules/ and everything in it (if you want to have a writable modules file system). Read the next section for details on how to do this." Also, the PW installer is also informative (sure, these are the conditions required by the installer, so later on /site/modules and config.php can be locked down, as also explained in the docs):

New module: OneTimeOnlyCode https://github.com/benbyford/OneTimeOnlyCode Use this module to create codes with urls (or any of string data) and later check a code and its data e.g. to get one time access to content. I built this to send out specific "exclusive" users codes at the end of URLs to new articles where noramlly they would have to log in -> now they can see the content only once and then have to login if they navigate away. I made it only to show the content not any user profile infomation etc when using the code, be warned not to use it to show user information unless you know what you're doing! Codes can have an expiry and uses lazy-cron to cull codes out of day at a set interval (both in checking and elapsed interval for the codes). Check it out!

Announcing the current status, planned release, roadmap and preview of Padloper 2. Status Feature freeze. Full multilingual support. Only PHP 7.2+ supported. Support for ProcessWire 3.0 only. Backend support for modern browsers only (that support JavaScript ES6 modules). Current Work Finish work on admin/backend. Work on installer and uninstaller (including configurable availability of some features). Work on UI/UX improvements. Start work on documentation with special focus on technical documentation. Continue work on Padloper API and data/model component. Roadmap Please note that these ARE NOT hard and fast targets. The roadmap may have to be adjusted to accommodate technical and non-technical constraints. Q1 2021 Inbuilt support for (latest) PayPal (full rewrite, no external modules required). Additional work on Padloper API. Invite a limited number of early alpha testers (fully-priced product). Soft and closed release of Padloper 2. Q2 2021 Start work on relaunch of Padloper website. Inbuilt support for Stripe (no external modules required). Future Plans Support for more Payment Gateways. Support for order, customers, etc imports and exports. Support for AdminThemeReno and AdminThemeDefault. Separate fully-featured frontend shop module. Consider support for multiple currencies. FAQ 1. Have you abandoned this project? No. 2. When will Padloper 2 be released? First early alpha release is scheduled for Q1 2021. This target may change depending on circumstances! Access will be by invite only for this first release. 3. What is the pricing model of Padloper 2? Three licences: Single Site, Developer and Agency licences (12 months’ updates and VIP support). 4. How much will Padloper 2 Cost? No price has been set yet. It will cost more than Padloper 1. 5. Can we upgrade from Padloper 1? No. 6. Will existing users of Padloper 1 get a discount for Padloper 2? No, this will not be possible. Apologies for the earlier announcement. It was unrealistic and unworkable. 7. Can we pay for Padloper 2 in advance? No. 8. Does Padloper 2 render markup/templates in the frontend? No. Access to all data you need to build your shop’s frontend is via the Padloper API. 9. Can we keep sending you ‘Are we there yet’ messages? No, please. Preview Here is a video preview of the current state of the backend/admin of Padloper 2. Please note the following: This is early alpha. There are bugs! It even includes WIP/notes!! FOUC, misaligned things, etc. The video shows the near-raw implementation of Vuetify UI. The UI/UX improvements work is yet to start. What you see here is the development version. Some of the incomplete features may not be available in the early releases. Most of the features you see will be optional to install.

New version of the module is now released. Truncate description using $sanitizer->truncate() method Added properties: description_max_length and description_truncate_mode Due to the usage of truncate method, the module now requires PW >=3.0.101 Image added using API will be resized Validate image object before resizing it Added API notes for all fields in module configuration Documentation fixes Download here: https://github.com/Fokke-/MarkupMetadata/releases/tag/1.1.2

Padloper 2: Early Alpha Preview + Roadmap Please see the latest announcement here:

2 new methods for Schema.org markup added: print_r($page->fieldname->getjsonLDTimes()); returns an array like this: Array ( [0] => Mo,Tu,We 08:00-12:00 [1] => Mo,Th 13:00-18:00 [2] => Th 08:00-11:00 ) Can be used to create the markup by yourself or echo $page->fieldname->renderjsonLDTimes(); returns a string like this: "Mo,Tu,We 08:00-12:00", "Mo,Th 13:00-18:00", "Th 08:00-11:00" You can use the second method in schema.org Local Business opening hours as followed: ..... "openingHours": [ "Mo,Th,Sa 11:00-14:30", "Mo,Th 17:00-21:30", "Fr,Sa 17:00-22:00" ], ..... Best regards

New feature added: I have updated the inputfield to support multilanguage timeformats on the frontend. You can set the timeformat of each language in the configuration of the inputfield in the backend (see screencast below). Supports strftime() and date() formats. Languageformat.mp4 Version was bumped from 1.0 to 1.1 on Github. Best regards Jürgen

Variations 002 (released 16/09/2019) Happy to announce the latest release of Variations. Changelog ProcessWire 3.x support only. New GUI to match AdminThemeUiKit Save and exit or save and add more variations configuration or attributes (in modal) More granular control of custom column types and definitions: DECIMAL, FLOAT, DOUBLE, TINYINT, INT, VARCHAR, TEXT, DATETIME, TIMESTAMP, BOOLEAN, etc Decimal type better suited for price data compared to Float/Double Boolean type, useful for Yes/No type data, e.g. for sell out of stock? yes/no Datetime/Timestamp fields if required. Column definitions: null, precision, scale, length, default value, etc. Required fields: if column is not nullable and no default provided, it becomes a required field. E.g. can set price not to be null. Default fields: For uses such as prefixing SKU- Apologies that this has taken a while to update. Upgrading If upgrading from version 001, ProcessWire's Filecompiler will fight you. You might get errors such as Class ProcessVariations not found in file..... If you get such errors, first, try to clear your cache and compiled files several times. As a last resort, if clearing cache doesn't work (and I don't like this workaround), temporarily change the code in the offending file, e.g. in VariationsRender.php, where it says class VariationsRender extends ProcessVariations, change that to class VariationsRender extends WireData. Refresh the modules page until the errors disappear, then revert back to the original text (class VariationsRender extends ProcessVariations). I hate to ask you to do this but I've had it with the Filecompiler. Documentation Documentation can be found here. However, it still needs updating to reflect latest changes outlined above. For now, please note that we've added an extra setting for setting the default date and time formats for datetime/timestamp custom columns/subfields. This is available in the Input Tab of the field. Screenshots Thanks!