Leaderboard

$fields->get('image')->getInputfield($page)->maxWidth;

Speaking for my modules only, I'm marketing these as turn-key modules, not as API tools. With the exception of the ProfilerPro module and Likes modules, the Pro modules that I develop were never intended as primarily API programming modules. They are modules that, outside of output generation, are meant to be largely turn-key, without little or no coding needed. It is true that you can use them at the coding level to do lots of things, they have an API and hooks available, and we could write an encyclopedia worth of content to cover it all. And it's also true that there are a few people, perhaps 5% of the users, that pursue this kind of stuff with these modules (especially Robin S., Adrian, LostKobrakai). I think that's great, and I'm happy to support that for those that are interested in using them that way, and have been for a long time via the support boards. This is a welcome and valuable audience for these modules, but not the primary or intended audience. The intention with most of the Pro modules is to provide things you can install and start using, and not have to code around. The documentation is consistent with the audience and intention of the modules. For those that want to get into the code side, I welcome it, but prefer to support them via the support board and focus in specifically on their needs. Though in the ProFields modules we do cover a lot of API side stuff too. The code of the modules is also well documented with phpdoc as well, making it handy in an IDE environment. If I develop a module intended primarily for API usage in the future, then of course the approach would be different. But because that doesn't describe my current Pro modules, I prefer to support people individually when they want to pursue unique needs that might require additional code, as everyone's needs are slightly different. That's beautifully put together– joshuag is an amazing designer and front-end framework developer, and there's no way I could ever compete with his skills in those areas. Sorry about that, but that's just reality. I can make great modules, but I'm far more developer than designer and marketer. I gave up trying to be a designer long ago. Also should mention though that what he's marketing clearly has a larger API-side than what's intended for any of my modules. And I agree he's outlined everything really nicely. I feel that I covered everything about the product pretty exhaustively. What do you think is lacking? https://processwire.com/api/modules/lister-pro/ Actions are just one small part of ListerPro, but it comes with seven actions, including an action that's a template for creating your own. Also why the surprise (?), the ListerPro page outlines all of the seven actions here. Have you seen this? https://processwire.com/api/modules/profields/ I don't use this one very often, and may delete it. It started back before we had an on-site store, so isn't really needed anymore, as it's been replaced by our store. They are not outdated. As far as the information goes about the modules, they are fully relevant and up-to-date. Though I should mention I always try to provide more than I market, and feel this is a good thing. I like for people to feel that they got something more and better than what they expected, with everything I do.

My new blog post on setting up a Blank Proflie: http://szabesz.hu/blog/my-basic-setup-of-processwire/

Most of our image/file features have been developed by the community rather than me, and I'm guessing this will follow a similar path. It doesn't seem to come up very often, but since you've mentioned it here maybe we'll have to bring more focus to it. I'll try to get a closer look this week to get a better idea of when we might be able to get more momentum going here. I do agree it would be a nice thing to have sooner rather than later. Also, since you quoted both 2016 and 2017 roadmap, it's important to note that this is a roadmap. It is a list of goals, it is not a contract of promises. We never expect to be able to accomplish all the goals, but feel it's important to have them nevertheless. Always good to aim for more rather than less. What doesn't get completed in one year still stays on the roadmap for the next year, unless it's determined it shouldn't be for some reason.

Introducing our newest [commercial] module: Recurme Processwire Recurring Dates Field & Custom Calendar Module. http://www.99lime.com/modules/recurme/ One Field to Recur them ALL… A Recurring Dates InputField for your Processwire templates. The InputField you’ve been waiting for. Complex RRule date repeating in a simple and fast user interface. Use the super simple, & powerful API to output them into your templates. example: <? // easy to get recurring events $events = $recurme->find(); // events for this day $events = $recurme->day(); // events for this week $events = $recurme->week(); // events for this month $events = $recurme->month(); ?> <? // Loop through your events foreach($events as $event){ echo $event->title; echo $event->start_date; echo $event->rrule; echo $event->original->url; ... } ?> Unlimited Custom Calendars. Imagine you could create any calendar you wanted on your website. Use recurring events with the Recurme field, or use your own Processwire pages and date fields to render calendars… it’s up to you. Fully customizable. Make as many calendars as you like. Get events from anywhere. Recurme does all the hard date work for you. Unlimited Custom Admin Calendars too. Hope you like it , Joshua & Eduardo from 99Lime. ## [1.0.1] - 2017-05-29 ### changed - Fixed $options[weekStartDay] offset in Calendar - Fixed ->renderCalendar() Blank Days - Fixed missing ->renderList() [renderMonth][xAfter] - Removed ->renderCalendar() <table> attributes border, border-spacing - Fixed ->renderCalendar() excluded dates - Fixed rrule-giu.js exclude dates - Fixed ->renderList missing space in attr ID (shout out to @Juergen for multiple suggestions & feedback).

Hi @SamC You should allow segments for the home page and then you can do what you want. But to keep things simple you can just rename "Misc pages" to something like "Info".

Hi @ryan thanks as always for your work and all the progress! may i ask about one special feature here that lots of us are waiting for since < 2016 and that was on the roadmap of 2016 and 2017 and still there are no news about it... I'm talking about client side image resizing... Roadmap 2016 Roadmap 2017 Please don't get me wrong - the intention of this posting is really not to point to you with my fingers (like "but you said you will do that..."). and of course, i could have tried to implement it on my own... but i'm not sure how much sense that would make. first of all, since it is on the roadmap for such a long time, it is risky to put effort in something that maybe solved by the core one week later and likely much better. secondly i'm not that familiar to javascript and last but not least, i think this should really be built into the core image field because i think that is a main feature of a content management software! if you don't think that you can make that happen soon it would be nice to know. maybe we could find someone in the forum that has the abilities to do it. i would also be happy to sponsor development, or at least a part, if someone else would be willing to join. ps: i know that we already have media manager and jquery file upload, but i don't think that this is a good solution. processwire is so easy and flexible in almost all situations that it just feels too bad to not being able to just put an imagefield on one template and make the client upload several large images and display them as a gallery... would really be happy to hear your opinion about that and of course, also the opinion of all the others

IMO having comprehensive documentation is something that can only add value to the Pro modules, and takes nothing away from them. I get that many users will only interact with the modules via the admin interface and would have no desire to browse through all the methods - they can ignore that documentation entirely. But it's nice to have thorough documentation for those who do have a need for it. I'm not proposing that you necessarily spend a lot of time writing up documentation beyond what's already present in the source. The tools already exist to extract and format those phpdoc comments as online documentation as it powers the current API reference docs. And the API Explorer module can do this for modules already. The reason I prefer online docs to the API Explorer is that it's so useful to harness the power of Google to find what you're looking for. It's quicker and more powerful to open a new browser tab and do a search from the address bar (I have a keyword shortcut for "site:processwire.com/api/ref/+%s") than navigating through the API Explorer interface. And of course not everyone has API Explorer. Could the Pro modules be stored in private GitHub repos and indexed the same way as the API reference? Maybe this module from @justb3a could be useful for the authorisation?

I've used the code on this tutorial for at least 4 or 5 sites, and it's rather easy to tweak for your needs. (You can pay for the full source code if you want to reward the developer for his work, but you don't have to: you can copy and paste the various parts needed).

This may be just my impression, but I think that this side of your modules, particularly FromBuilder and ProCache, would be worth exploring a bit further. I find myself extending both modules quite often for different client needs, and in my opinion third party extensions to these modules could bring in notable extra value. That, at least, is how it works for their WordPress counterparts. (Not saying that you should start mimicking Ninja Forms or Gravity Forms etc. but I do think that they have handled the extension thing pretty well.) Please don't. While Pro modules are better featured in other places, this is a good way for third party commercial module authors to get some extra visibility. That alone is a very good reason to keep this category around and even develop it further (Oh, and sorry if I misunderstood and you just meant that you might remove your own Pro modules from there. That's fine by me, though it'd be a shame; I like the idea of being able to quickly check out what the commercial module market for ProcessWire looks like.) Thanks for considering this. Perhaps you're referring mainly to new users bringing this up "out of the blue", but I for one tend to avoid bringing up topics that are, for an example, already listed on the roadmap. I'm probably not the only one who thinks like this, which might be one of the reasons why it doesn't come up that often

Hello @modifiedcontent, my code above works in PW3 dev. I have modified a if function and this makes the problem. Removing the if statement makes the code working again, so this is an working example. Of course. This is only a temporary storage folder and the image will be deleted after this command: unlink($upload_path . $files[0]);

Hello @ all, it is possible to get the parameters of min and max dimensions of an image upload field set in backend via API on the frontend. I use an image upload field on the frontend and I want to show a hint for users that the uploaded image should be at a certain size. For this purpose I want to output the min and max sizes that I have set in the backend. Does anyone know how to get this values via API calls on the frontend? Best regards

Wow! Just that simple!! Thanks a lot - works as expected!!

I always clone a site form production to my local dev machine, I follow the simple workflow of syncing files AND cloning the database of the production site to my Mac. To clone the db I use this in a simple Bash script including the following: printf "Trying to drop all the tables of the Target database called $DB_TARGET_NAME \n" mysqldump -u $DB_TARGET_USER -p$DB_TARGET_PASS --add-drop-table --no-data $DB_TARGET_NAME | grep ^DROP | mysql -u $DB_TARGET_USER -p$DB_TARGET_PASS $DB_TARGET_NAME printf "Trying to download+import the database...\n" mysql -u $DB_TARGET_USER -p$DB_TARGET_PASS $DB_TARGET_NAME < <(sshpass -e ssh $SSH_ARGS "set -e; mysqldump -P 3306 -h $DB_SOURCE_SERVER -u $DB_SOURCE_USER -p$DB_SOURCE_PASS $DB_SOURCE_NAME | gzip -cf" | gzip -cd) So I drop all the tables of the target DB first, then import the production DB via SSH as seen above. I have a keyboard shortcut to launch the script, so that I can get the production db in a matter of seconds in the case of not gigantic databases. (Which I do not have currently...)

Sounds good. So a better proposal is to just use live data for developing and stop emails out? I guess that could work, then before doing some dev, you just copy your production DB to the dev first, so you have an environment as close as possible. Make all your dev, and then merge changes back. That would keep the changes to merge and apply from dev to production to a minimal. Also instead of intercepting emails, another way would be just to alter the email formats on the sync/transfer process. Example changing all emails from account@example.com to account-example.com or similar. That would make all emails out as invalid as well or better, replace all of them with an all catch in the address in your domain like changing account@example.com to account-example.com@yourdomain.com I think that approach would be better just to be sure because the module you mentioned is only for emails using the WireMail function. So if you have PHP code that does its own email sending, or any other form or system sending emails mixed up or made up on PW templates, that module would not work.

Edit: I had posted here because I thought this didn't work: But it does work. The images just don't end up where I expected them - the 'headshots_uploads' directory is supposed to stay empty? You can see the result of the upload with: There should be a headshot/avatar field in the user template. It can get confusing if you have some kind of custom user profile page; you have to make sure you get the avatar of the relevant user instead of the logged-in user. And the upload is saved to $user, not the $page the form is on. There is no way to get the nifty image upload from the admin area on the front end? Edit: I have added $user->headshot->removeAll(); because I kept seeing old avatars. This way you can only have one image in the field/array, so you can't have a feature where the user can swith between uploaded avatars. Is there a more elegant way to "refresh" or make sure that only the latest modified profile picture is shown? Edit2: If you click Submit without selecting an image, you get an Internal Server Error. So I guess you need a check if the input field is empty or not. How do you do that in Processwire? What I have tried so far - adding && $input->post->headshot to the first if statement etc. - didn't work.

i've searched many times for just upload single images on user template without creating a new page...and best found was the gist from soma: https://gist.github.com/somatonic/4150974 But i've stucked don't get the upload working on this....if i did a var_dump on the upload array it is emty...hit my head on the wall while searching the issue... my edited code with some debug messages: <?php //color the code somas code below // front-end form example with multiple images upload // add new page created on the fly and adding images if($input->post->user_img){ // tmp upload folder for additional security $upload_path = $config->paths->root . "tmp_uploads/"; // new wire upload $u = new WireUpload('user_img'); $u->setMaxFiles(1); $u->setOverwrite(true); $u->setDestinationPath($upload_path); $u->setValidExtensions(array('jpg', 'jpeg')); // execute upload and check for errors $files = $u->execute(); //just some checks whats going on...$files is empty $upload_path seems to be right! $successMessage .= var_dump($files); $successMessage .= $upload_path.'<br>'; if(!$u->getErrors()){ // add images upload foreach($files as $filename) { $successMessage .= $filename; $user->user_img = $upload_path . $filename; } // save page $user->save(); // remove all tmp files uploaded foreach($files as $filename) //unlink($upload_path . $filename); $successMessage .= "<p class='message'>Files {$filename} uploaded!</p>"; } else { // remove files foreach($files as $filename) //unlink($upload_path . $filename); // get the errors foreach($u->getErrors() as $error) $errorMessage .= "<p class='error'>$error</p>"; } } And here is the form itself...it is in a var to echo the whole thing...with some options ans so on... // display a user settings form $settingsForm = " <!-- general form elements --> <div class='box box-primary'> <div class='box-header'> <h3 class='box-title'>Voreinstellungen ändern:</h3> </div><!-- /.box-header --> <!-- form start --> <form name='settings' role='form' action='./' method='post'> <div class='box-body'> <div class='form-group'> <label for='user_an'>Auswahl Auftragnehmer</label> <select name='user_an' class='form-control' id='user_an'> ".$optionsLu." </select> </div> <div class='form-group'> <label for='user_mr'>Auswahl Maschinenring</label> <select name='user_mr' class='form-control' id='user_mr'> ".$optionsMr." </select> </div> <div class='form-group'> <label for='exampleInputFile'>Profilbild ändern</label> <input name='user_img' type='file' id='user_img' accept='image/jpg,image/jpeg'> <p class='help-block'>Nur jpg Bilder sind erlaubt!</p> </div> </div><!-- /.box-body --> <div class='box-footer'> <button type='submit' class='btn btn-primary'>Ändern</button> </div> </form> </div><!-- /.box --> "; Really have no clue why the upload array is emtpy? Best regards mr-fan

I've written a module called HTMLBodyClasses that renders classes for the <body> tag. echo HtmlBodyClasses::renderClasses($page); Outputs: <body class="home template-home page-id-1"> Page name, page template, page's ID. You can get it here: https://github.com/ethanbeyer/HtmlBodyClasses

User submitted data is nothing more than a group of fields that define the type of data you want to save, such as text (user name), images (avatar), etc. Those fields are then assigned to a template, which is nothing more than a grouping definition for those fields, eg, user name, address, etc. That template is then assigned to a page, which is basically the interface between the user and the database. You code how you want the user data entry form to appear, assign each data element to the appropriate field, then save the page. You use the current user (the one logged in) to determine which page to display. For example, $pages->get("page->createdUser = $user->id") returns an array of pages that $user created. No other user will see it, nor can they hack it. Your code determines what is accessible. You can define additional permissions using those modules mentioned earlier to further restrict what any particular user may do or not do. For example, if ( $user->hasPermission('whatever') ) { do something }.

Hi @Thor What I said about the author may not be the actual name. I think it is $page->createdUser, which indicates the user (author) that created that page. Sorry for my broad terminology. And Yes, page edit field permission module is a finer control over access. When you say 'submitted data' that implies a form action, either front-end or admin, so yes, you will need to code for your specific conditions. For example, User-A submits whatever through your front-end form. Your code will need to sanitize that form data, then save that data to the desired page. After you process the form data, and before you save the data, you can specify other properties, such as created user, or whatever fields you defined for that template. Later, you can retrieve one or more pages that the user created, or has access to, or however you define it, for whatever purpose you intend. That means User-B won't see what User-A has done. You could also retrieve all pages, regardless of user, to display to any user if you desire. Take the case of a user profile. ProcessWire, by default, only shows the profile data to the current user, and not another user. But it doesn't prevent you from retrieving all user profiles and displaying a list to any user if that is what you want to do. As I re-read your initial post, it is clear that you do your research. What you are asking for your project is very doable in ProcessWire. Even if you find you need to create custom tables, ProcessWire makes that very easy to do -- see the wire database pdo. There is a ton of information in this forum as well as the normal API reference, captain hook, etc. Should you have any questions during your development, there are many far more talented members here that will be glad to jump in and help out.

Hi @bramwolf, That's an interesting project you have because some of the items you list are what I am currently working on. I am rebuilding my site from the ground up to accommodate some of these items, so it's appears to be duplicating your project. I don't want to hijack your thread, but I will pass along what I am going through. - The dynamic content for news articles, company profiles, and the like, is easily handled by ProcessWire. You won't have any issues there. - The way I am approaching your membership requirements is that each user must register, which grants them read-only rights to view my applications (your free membership item). Then a user may select one or more applications to subscribe, which elevates their rights to administer the selected applications (additional user licenses, subscription payments, reporting, etc.). I changed the login to use an email address rather than a user name because I don't want Peggy Sue in Ohio colliding with Peggy Sue in Florida. - There are any number of solutions available that handle advertising for web sites, such as openx, google ads, doubleclick, revive, etc. However, ad blockers can limit these. I wrote a wp plugin many years ago to handle advertising that I am now porting to ProcessWire. I'm in the deep end too considering I am learning how to incorporate some of my older code into the ProcessWire way of doing things. - Your job listing also falls under the dynamic content. - The marketing automation can be done through cookies. Tracking user interest on your client's site is simple enough by storing elements. The issue comes later when you analyze that data. Adding unique ids to targeted emails will also let you track user responses. Hope this helps, and good luck to you.

Hello Bramwolf, As Processwire is a CMF it can do all of these. However it will require quite a lot of custom coding. If you aren't looking to do that, then you will have to use multiple platforms. Getting them to all work together, could prove a nightmare and blow your house down. For the CMS part, you could use ProcessWire and for the membership part you could also use ProcessWire and Stripe/PayPal quite easily. Personally I would suggest Stripe. Advertising platform you can use something like https://www.adbutler.com/ and plug that into ProcessWire, and for Marketing Automation you can now use something like https://mailchimp.com/features/marketing-automation/. The thing that I'll have no idea about is segmenting you users based on personal interest, pages they have visited etc. To me that will be your biggest bulk of work as to track all of this is big data and will require crazy optimisation or a huge database.

This post has had an inexplicable surge of Likes over the past few weeks so there seems to be quite a bit of interest in this 7 months later. I've been unable to follow these concepts up with the time they deserve but those interested in an mage field tidy up can see Toms own beautiful work mentioned on the Dec 18 blog post. Furthermore, Ryan mentioned in today's Roadmap blog post that these (Tom's) designs are already being worked on by LostKobrakai. Exciting stuff!