Leaderboard
Popular Content
Showing content with the highest reputation on 02/20/2020 in all areas
-
Hi guys, I was very excited for this module, but my life took a huge direction change and I no longer have the time to invest in module development. I am gonna leave the files here. You guys can take it and run. Maybe there might be something useful here. Maybe not. I still think it's a good idea to do drag and drop modal building in PW. So hopefully one day something like that can come to light. I love this community and I love ProcessWire. Live long and prosper. - Joshua Designme 2.zip8 points
-
Having just wasted the best part of a day debugging an access issue because I hadn't realised that page-edit-created negated any related page-edit permissions, could I suggest that a note to this effect is included in the default title. I have amended the title on my system to read: Edit only pages user has created (IMPORTANT: This will negate any related page-edit permission - including permissions granted to a user by other roles) ..although it may be possible to make it briefer while not losing clarity and impact.2 points
-
--- Module Directory: https://modules.processwire.com/modules/privacy-wire/ Github: https://github.com/blaueQuelle/privacywire/ Packagist:https://packagist.org/packages/blauequelle/privacywire Module Class Name: PrivacyWire Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md --- This module is (yet another) way for implementing a cookie management solution. Of course there are several other possibilities: - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/ - https://github.com/webmanufaktur/CookieManagementBanner - https://github.com/johannesdachsel/cookiemonster - https://www.oiljs.org/ - ... and so on ... In this module you can configure which kind of cookie categories you want to manage: You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience. Currently there are four possible cookie groups: - Necessary (always enabled) - Functional - Statistics - Marketing - External Media All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ... When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax: <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision. If you want to give the users the possibility to change their consent, you can use the following Textformatter: [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie. You can also add a custom link to output the banner again with a link / button with following class: <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> I would love to hear your feedback ? CHANGELOG You can find the always up-to-date changelog file here.1 point
-
@adrian Interesting point indeed, though I recall having changed the priority once or twice in the past for some reason or the other. To me, it makes sense that JL does its thing first as it acts as a user-intervention strategy in that we have to honour the user's wishes. Figuring out what those are, however, is a different story, given the different approaches/modules that are available. I wish this could be configured by the user, in the case conflicts/undesired redirects take place. Jumplinks was actually borne from a plugin I wrote for Bolt CMF, and that plugin was an absolute, undeniable 'before everything else even considers thinking of running' scenario. Before we make a decision here, I think we should get more feedback from other JL users, and perhaps get a list together of any plugin that does route-redirection along with their priorities.1 point
-
This could lead to different results when short-circuit evaluation is used. (But I don't know if this can occur with the Boolean expressions in PW selectors.)1 point
-
The round braces in selectors are named OR-groups for a reason, so you'll have to adapt your selector. You may want to remove the negation and switch ">" to "<=" and "<" to ">=" for easier readability. Since I don't really know how maps to your data, it's difficult to tell you more. The docs I linked also explain to use named OR-groups where at least one selector expression of each named group has to match. To apply that to your example, this would e.g. read: $pages->get("parent=1042, first=(!comp0_min_high>200, !comp0_max_override<100), second=(!comp1_min_high>50, !comp1_max_override<10), third=(!comp2_min_high>50, !comp2_max_override<10)"); However, if your logic is right, you can simply drop the parentheses since boolean AND expressions are commutative. (a AND b) AND c is the same as a AND b AND c or c AND b AND a.1 point
-
Hey Kei, Have you tried the skyscrapers profile by @dadish that can be found here. With a clean install of processwire, you can drop the profile in and proceed like you are setting up a new instance with the profile selected.1 point
-
Hi @Jens Martsch - dotnetic Almost a year later and still in the same situation, @joshuag jumped ship on this project and I'm full of client work ?. I know it looks awesome but I it's still far from being good enough for release ? I seriously get the impostor syndrom when I see all the awesome users we all know, releasing amazing modules every now and then with such amazing quality, how do you guys do it?! Need to level up ?1 point
-
You don't need PHP at all. I'd suggest to use Google Optimize (and a linked Google Analytics account where you set up your goals) instead. Here's a nice tutorial. (you can skip more or less to step 3 "Create an Experiment" - and make sure you also include the "anti-flicker" stuff at the end of step 2)1 point
-
I understand why you are asking for this feature. You're not the first one. But it's not as obvious as it seems. The 'title' field is not the same as all other built-in fields. You can't modify the behavior of the built-in fields per template basis. Which means they all behave the same no matter what template the page has. That's why we have a generic type 'Page' that has all the built-in fields. No matter what template the page we can confidently serve those fields for every page. The 'title' field's behavior could change depending on the template. I understand that it is almost never the case, but semantically it is. For example, you can set different access settings for 'title' field depending on the template. You make it that user can view the 'title' on one template and not on the other. You can change the description of the field for each template and it will appear in the GraphQL documentation. You can also make 'title' field 'not required' for one template and 'required' for others. So, including 'title' field into the Page type will break the semantics. I understand that 'title' field is almost always treated as a built-in field but I just can't overcome this feeling that it is the 'wrong' way to do it. I would like do it only the 'right' way. And the right way brings us to your second question. If we implement it properly and add the ability to get the values of the template fields for generic Page types, then 'title' field should also be solved. For this we will be adding interfaces. It will allow you to get template fields for Page types by providing a template. It will look something like this. { city{ list{ children{ # <== let's say children are the pages with template skyscraper and architect list{ id name ... on SkyscraperPage { # <== you basically say: "for skyscraper pages give me these fields" title images{ url width height } } ... on ArchitectPage { # <== "and for architect pages give me these fields" born email resume{ url filesize } } } } } } } this way you can fetch values for all template fields on Page types. This will work with everything that returns a Page type. Including 'child', 'children', 'parent', 'parents' and Page Reference fields too. And the best part is, it will be semantically correct! ?1 point
-
Hello @Brett. Thank you for your feedback! I was able to reproduce your issue and hopefully tracked down the bug. Please, install the latest version and give it a try. Let me know if the issue is resolved for you. New Release 1.1.3 - Fixed bug with FieldtypePage returning only single value.1 point
-
This module does not work with ProcessWire 3.0.x. If you try to edit a page "The process returned no content" appears (translated from german). Must have to do with the hooks not returning correctly. Sadly the README on github says, that this module is no longer maintained.1 point
-
Hi aren, I just committed an update to Custom Upload Names for you. It now has an option to generate a random string at a length of your specification. Please take a look and let me know if you need any assistance.1 point