Leaderboard

Hi! Look repeater. It's already installed in core. Good luck!

https://processwire.com/api/ref/input/page-num/

don't know if this site was already posted or where they get their data from, but maybe it is interesting for someone: https://trends.builtwith.com/cms/ProcessWire/Market-Share

Interesting discussion about extra address fields. I created a fieldtype 'AddressGeoNames' that consists of separate text inputs for country, city, postcode, lat, lng etc. where field values are verified and partially auto populated through geonames.org API. This is a standalone Inputfield that geocodes through the google maps api. But it can also be connected to an InputfieldLeafletMapMarker field so that the given address will be rendered as pin on the map. The pin can also be manually repositioned and writes back lat/lng to the AddressGeonames field. I am currently using this in one live project with about 1500 users and they seem to get along fine with data input and geocoding. This is how it looks like when used next to a InputfieldLeafletMapMarker field: Planning on adding support for GoogleMapsMarker, too and eventually releasing it on github. Not quite ready yet, though. But if anyone is interested in the concept, I could share what I have so far.

That's the whole point of this thread I don't think there necessarily needs to be a plugin for outputting legal stuff. Considering the basic contact form, there should be a privacy policy page somewhere that describes what happens to the data, and we have some guidance for writing that up here: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/principles-gdpr/what-information-must-be-given-individuals-whose-data-collected_en. But that's our clients' responsibility, not ours. Of course, this will vary greatly from site to site. It's not the same as the cookie consent message. The company has to describe exactly what they will to do with the information and how long they'll keep it. We should also add the "I accept the terms of this site's privacy policy" checkbox on any forms that ask for private data, and the words "privacy policy" linking to the page where it's all described. There shouldn't be a problem stating that the form submits the data to our email for appropriate response, that no data is stored permanently on our servers, and should you require the right to be forgotten, please submit your request to the email xxx. This and all the rest that's stated in the link above. But so far this isn't more than a disclaimer and examples will start popping up everywhere on the web in no time. What worries me more is when the data stays in our PW. If the server is hacked and info is leaked, there can be an investigation that will evaluate how careful we were with the way we've built the site. They mention database encryption, security by design, and keeping the data for the least possible time. For me this is where one or two new modules may come in handy. Not keeping the CMS updated can theoretically burn someone. Example: We have a jobs form that stores a user's CV. In a year that CV will be outdated and would serve no use. A module that automatically manages that content's (page) date of expiration and deletion could be useful. Another example: A site that has a private area that a user can register to gain access to. After X months without logging in, the data is deleted. Maybe even notify the person that it will happen unless they log in before day X. Doesn't sound too complex to do. Now, security by design... I'm clueless. I saw a mention of stuff like scattering personal data in more than one DB and only by comparing a blind ID you can tie the info together. I can see the coolness, but can't see it as something viable for smallish sites.

And that is why companies will not be able to fully comply even if they wanted to. Most people cannot even find an old email, they do not properly know how Outlook works, and on top of that they use Windows, the most hackable widely used OS on the planet. So now what? While the intention of GDPR is OK, it has been written by lawyers who live in their dream world not knowing anything about IT. Do they care if they ask the impossible? Of course they don't. Anyway, we need to do our best, so I propose to start writing a module that helps generating the legal stuff (privacy policy, etc...) that must be outputted somewhere so we do not have to reinvent the wheel. For other systems people are already writing plugins that test the CMS and look for possible issues, eg: https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=32993&sort=date_added https://wordpress.org/plugins/tags/gdpr/ I guess none of us wants to spend a lot of time on it, so why don't we help each other?

I recently started to build Vue SPAs with ProcessWire as the backend, connected with a REST API. Thanks to code and the help of @LostKobrakai (How to use FastRoute with ProcessWire) and @clsource (REST-Helper) I got it up and running pretty quickly and now have put all of it in a site profile for others to use. It includes the REST API with routing for different endpoints, JWT Auth and a simple Vue SPA which shows the process of logging in a user (nevertheless, you don't have to use the Vue part, the API will work on it's own). Check it out here: https://github.com/thomasaull/RestApiProfile I'm pretty sure, it's not the perfect or most sophisticsted solution, but it gets the job done for me… Feedback or Improvements are very welcome Update: This site profile is a module now: https://github.com/thomasaull/RestApi

Easiest, fastest, most reliable framework. Considering my workload this past weeks, I'm considering on switching. It supports a wide range of applications:

Velotraum is a small German manufacturer, building rather costly, individually manufactured bicycles for both globetrotters and everyday bikers. We use RepeaterMatrix for long structured texts, and we use a lot of individual fields for metadata. We even built our own "preview" function for blog comments and included Textile light for blog comments, too. Have a look: velotraum.de

for the most part, the hidden field option i think is best, but does take some logic and page saving; If you do want to have them be virtual, then you can do a hook wire()->addHookProperty('Page(template=product)::rating', function($event) { $product = $event->object; $event->return = $product->points / $product->votes; }); but you will be limited to in-memory selection, since the property is not in the database

Unfortunately, as we dive into GDPR, there will be a lot more that will worry us! For example: It can even be our responsibility: "As a business owner you are a data controller. Your web developer, hoster and saas marketing tools ( mailchimp, salesforce etc. ) are data processors. The data controller is ultimately responsible for the protection of personal data they store. However if it is found that your data processor has been negligent then they are also responsible." Since server logs cannot get any extra protections pretty soon, are we going to be negligent out of the box? Hosters must also comply. Without them a site cannot comply. If the site does not comply because of us/hoster, are we negligent? What does being negligent mean, anyway? This is the sort of ambiguous stuff which is frequent in any text written by lawyers and such. What about an order form with AJAX updating data? When should we get the consent during the not linear data post process? With recent trend of data fragments being sent constantly, is it technically possible to ask the user in advance in any case? I would not ask the user on each form as it is a UX killer and silly. I am thinking about placing an impossible to miss "GDPR banner" on the site, where all stuff is explained and probably the first form submission is only possible by going to that page (+ also a link to that page from the form...). If users know where they are informed, and they also click that one and only checkbox on purpose then this part of GDRP should be covered. And this is the sort of module that could also be written. I'm thinking of producing required legal text fragments which can be turned on/off depending on the site's needs. That text should be editable of course. Such a plugin could be just a starting point, which help us not to forget things.

Yes pal don't even say sorry, I wasn't really asking for features, rather I was just trying to give my opinion about the usage and the overall project I guess the word wishlist was misleading haha.

...couldn't resist to fork it and clean the code of this framework a little bit if i get the time...

Markup Cache for products cards, some static parts of pages and WireCache for searches. https://processwire.com/api/ref/cache/ Page cache and ProCache are options if you can implement ajax loading for dynamic parts, but definitely more work.

There's a million ways to do something like this. An easy and straightforward way is to add a data-attribute (YYYY) to your campaign wrapper div. Then use a few lines of JS to hide every campaign year item except the selected one. Examples: https://www.sitepoint.com/jquery-filter-objects-data-attribute/

Hey everyone! It's been a while since I last had a time to work on this module. But now I finally managed to focus on this module. So here are the latest updates. The codebase of the module grew very big and the more features I added the more time I had to spend to make sure the changes I made does not break anything. Because I had to manually verify if everything works as expected. After long night hours of trial and error I managed to setup tests for this module. Tests will help us quickly add/remove features as needed, because now there is no need for manually verifying all edge cases. Also I setup the Travis-CI so people can contribute more confidently and I can merge pull requests without worrying! There are already bunch of tests, but there is still some I'll be adding. ? ? I will add some documentation on how to run tests locally in github wiki pages soon and let you know here. Another thing to note is that the master branch of our module no longer tracks the vendor code. This means that if you download the master branch and put it into your /site/modules directory it will not work. Instead you should use release builds that are a cleaned version of the module. It includes required vendor codes and does not have extra files that are not relevant to ProcessWire. Like presentation gif images, test files and so on. This makes the module size smaller!

Just wanted to explain @kixe's excellent answer a little for those who might be wondering why that hook isn't listed in the Tracy Captain Hook panel or on the Captain Hook page: https://processwire.com/api/hooks/captain-hook/ What is going on is that ProcessPageEdit extends Process and Process has a ___headline() hookable method. If you're used the Tracy Captain Hook panel, it always pays to check the class that the current class extends: Now we're looking at the hooks for the Process class and we can see that headline is available. Hope that helps! The other useful tip is the to click the "Toggle All" button at the top and CTRL/CMD +F and look for "headline"

Of course ... /** * modify headline in page edit interface */ $wire->addHookAfter('ProcessPageEdit::headline', function($e) { // get id of page beeing edited $pid = (int) $this->input->get('id'); if (!$pid) return; $pageBeeingEdited = $this->wire('pages')->get($pid); if (!$pageBeeingEdited->id) return; $headline = "My ID is $pageBeeingEdited->id"; $this->wire('processHeadline', $headline); // no need to modify the return value ($e->return) });

I've been working with FieldtypeOptions recently and in the absence of documentation thought I would share some example code: $field = $fields->get('test_options'); /* @var FieldtypeOptions $fieldtype */ $fieldtype = $field->type; // Get existing options // $options is a SelectableOptionsArray (WireArray) // If there are no options yet this will return an empty SelectableOptionsArray $options = $fieldtype->getOptions($field); // Create an option $yellow = new SelectableOption(); $yellow->title = 'Yellow'; $yellow->value = 'yel'; // if you want a different value from the title // Don't set an ID for new options - this is added automatically // Will deal with 'sort' property later // Create another option $orange = new SelectableOption(); $orange->title = 'Orange'; // Add option after the existing options $options->add($yellow); // Get an option by title $green = $options->get('title=Green'); // Insert option at a certain position $options->insertAfter($orange, $green); // Remove an option $options->remove($green); // Reset sort properties (so order of options is the same as the SelectableOptionsArray order) $sort = 0; foreach($options as $option) { $option->sort = $sort; $sort++; } // Set options back to field $fieldtype->setOptions($field, $options);

Setting the defaultGamma option to 0.5 instead of the default 2.0 seems to have fixed the image quality. $config->imageSizerOptions = array('upscaling' => true, 'cropping' => true, 'quality' => 100, 'sharpening' => 'none', 'defaultGamma' => 0.5); Thanks for the help everyone!

I think your problem is that you mix up search and pagination. The pagination always needs to be called on the exact same pagearray. In your case this means that you need to have the exact same pages retrieved by your selector for each paginated page. Therefore you need to have some way of storing either $q or the generated selector for the next paginated pages to make the pagination work. That's what the whitelist teppo mentioned does for you.

Yep, works great! In case anyone is following along, my original example is updated and working correctly. Thanks Ryan!