kongondo

Media Manager version 009 (released 16/12/2016) Happy to announce the latest release of Media Manager. Changelog Filter Profiles: Feature enables configuring of various media filter interfaces (similar to ListerPro). This feature was requested here. Please see otes below Filter Profiles Usage To use the so-called Filter Profiles feature, you will first have to enable it in your settings (see images below). Head over to any media view. You will see a 'config' tab next to the Filters tab. Click on it. It will open a modal Create your profiles (one at a time). These are added to a table in that modal view. Click on the title of a filter profile to configure it's filters. Moves to 'single filter profile edit view' Set a filter as active by selecting it in the dropdown at the top of the modal view (#2) To delete one or more filter profiles, click their trash icon and save (there's a checkbox to confirm action) Close the modal. The Media Manager Library will reset and if you set an active filter in #5, your Media will be filtered according to your settings Currently, any user can create filters. Depending on your feedback, this might change. We might also add other features, e.g. locking down filters so they cannot be deleted. OK, that's it from Media Manager for this year. Hope it's been fun! Thanks.

Welcome to ProcessWire and the forums @vvanasperen . A theme, in the sense you describe it, is a so-called 'site-profile'. We don't really have themes in ProcessWire. Personally, I think a great place to start is reading the docs, the basics. My motto would be I can make it all nice and shiny (theme) later, once I get to know the basics. If you already have a PHP background, great, you will be quite comfortable. If not, you will need to learn a few PHP basics in order to use ProcessWire, Here's a couple of docs to get you started: https://processwire.com/docs/tutorials/ http://processwire.com/api/variables/page/ : must know http://processwire.com/api/variables/pages/ : must know Sorry, typing in a hurry...but others will chime in am sure.

You should be able to do your 'automatic checks' in getModuleConfigInputfields(). If the checkboxes are on that screen then I see no harm in letting them be part of the config. See how we do it in Blog. If Blog is installed, we show a different form, if not, we show the pre-install form. Search the forums for that method for simpler examples. It's a static method, mind you, so you will be 'wiring' a lot

I am not sure you can do that (without hooking into something). Module configs are are processed internally by ProcessWire. It will correctly save radio values, checkboxes, etc. The module config form has the ID: ModuleEditForm. Is there any reason you want to also process them? If, on the other hand, you need access to the saved configs, you get those using: $happyImageConfigs = $modules->getModuleConfigData('HappyImage');// assoc. array

Yes. It's quite advanced to be in the cheatsheet . Besides the links below, you can Google (forums) $database (or even PDO) to find out more if you wish. Also, just grepping $database in ProcessWire core files, especially Fieldtypes should yield interesting stuff API documentation on ProcessWire site: Class Database More API Docs: Class Database Example usage: Blog and Matrix modules.

You can still use your SQL in ProcessWire, either raw or using $database variable. I have done this myself in various modules. Also, maybe not to the extent you want, but Padloper generates sales reports.

Add the field to your user template Do what you want ...e.g. $process = wire('process'); $u = $process->getPage();// this is an object $id = $u->id; return $id;// will return 40 for guest, 41 for superuser, etc... //return $process->className();// would return ProcessUser. Useful to know if you are using the field elsewhere and want to do different things based on context // return $u->email;// etc... Edit: But that only works when you are actually editing that page, of course

In that case, the following code should work.... $out = ''; $u = wire('users')->get(3718); $related = $pages->find('your-relation-here'); foreach ($related as $r) { $out .= $r->title; } return $out;

Nik, Maybe I am missing the point but my example code above is meant to show that ALL ProcessWire variables are available to you. They will just have to be called as if they were in function, i.e. user wire(). You are not limited to page(s) only . However, for syntactic convenience, $pages and $page are available without resorting to wire('page'); I don't understand what the current user being edited means. However, to get the current user, you would do, for example... if(wire('user')->name=='santa') return "Dude, where's my stuff?"; else { // do something else } Instead of typing all that code in there, you can user wireRenderFile() and write all your code and logic in an external php file.

Is it is possible to show native ProcessWire notices (errors and messages) in a PW modal (pw-modal) or alternatively on inputs in that modal? Thanks.

Welcome to the forums and ProcessWire . Oh, we are very kind to everyone, especially those coming from the nightmare that is WordPress. Just kidding. Former MODx-er myself. Nothing wrong with using the variable $features. What I suspect is that your image field is set to hold (and return) more than one image, i.e. an array. So, calling the resize function on an array won't work. Edit Been beaten by others who are faster at typing/thinking...so will stop typing now

return wire('users')->get(40)->name; @NikNak That will return guest. Only $page and $pages are locally scoped, as per the description right above the input for code. I guess that and the docs should perhaps be clearer.

@NikNak. Works fine for me on PW 3.0.42 and PHP 5.4.22 . You need to ensure that your code returns a value. For wireRenderFile you will need to namespace the function in PW 3.

https://github.com/ryancramerdesign/ProcessWire/blob/master/README.md https://github.com/ryancramerdesign/ProcessWire/blob/master/README.md#upgrading-from-processwire-24

Short answer no. ProcessWire does not generate or output any markup. Any markup you add is your own. Maybe if you explained your situation we could show you how to go about it.

What Robin S said. Security How does the widget communicate with the third-party server? Is that something in your control? Are there risks if the communication was intercepted? User-Friendliness As a general rule, I would never put any sort of code in front of editors, unless I have to. Edit 10 or 15 pages and one widget starts to look like another, we miss or add an extra apostrophe here and there, and soon, it gets a bit messy and our code trips. In addition, the editors will probably be copying and pasting and that's somewhat tedious. Other than that, it doesn't look too friendly . OK, we can mitigate this by asking the client to enter something like this in the text/textarea field type:class_lists,partner:mb,id:123456WB,version:0.1 OK, a bit of progress, but that's still a bit cryptic for some clients. The ideal situation would be to create one input per editable-value. That would mean 1 field per editable-value. Maybe an overkill (to some). Better yet, I would create a custom field that will hold all those n number of inputs for n number of editable-values. The advantages of this are: It is user-friendly It is easy to sanitize and validate each individual input If needed, we can query each of those fields (e.g. in case we have lots of pages and need to find those that contain xxxx in their ID in order to edit them) Etc... Below is an example custom widget field as per above. It is not very difficult (if you are a developer) to create one based on the Events Fieldtype. Just my 2p. Something to consider.

Hi @Nukro, It is planned for the next version. Technically, I already know how I will implement this. What I am still unsure of is how I will implement the GUI (from a usability point of view). With lister, each lister gets its own fixed filter configurations. With Media Manager, there's only one canvass, so to speak. We will probably need a dedicated page to handle the creation and editing of a filter configuration. Users would need to be able to select the active 'filter' configuration/profile. I would like the whole thing to be a simple thing to do (from user perspective) but without cluttering the MM interface. I'll need some time to think this through. I would appreciate any thoughts you have, thanks. As for ETA, I am afraid it cannot happen before the new year.

Hi @adrian, Good catch. Yes, raw SQL would be the way to go. I'm still mulling and testing most efficient way to go about this.

If you use Hanna Code, you will place the Hanna Code in the RTE textarea of your page ,e.g. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras et rhoncus nisl, a facilisis turpis. Integer sit amet fringilla velit, quis lobortis leo. Aliquam vitae ante tristique, sollicitudin est sit amet, scelerisque leo. [[widget]] Pellentesque iaculis mi dolor, id pretium dolor pellentesque eu. Proin in tincidunt mauris, eget facilisis nibh. Mauris eget euismod magna. Nunc eu mi pellentesque justo pharetra dapibus. The 'widget' will be read by Hanna Code and it will apply the PHP code present saved for that widget in Hanna Code editor. I can give you example code. All your clients would have to do is to put [[widget]] on each page, or if passing values, [[widget data_type=whatever, etc]]. Would they be able to do that. As for the other alternative, you could use a normal textarea without RTE and instruct the Hanna Code [[widget]] to get its values from that textarea. Hope this makes sense. Edit: Beaten by Robin S. More thoughts: Scenario 1 If your widget code will be place before or after your body text, then you don't need Hanna Code; only a non-RTE textarea field. In your template you would have two fields. One is your RTE textarea and the other the non-RTE one. In the RTE enter body copy as normal. In the non-rte one, let's call it widget_textarea, your editors will place the code. If the whole code will be changing, as opposed to parts of it, then they will put in that textarea the whole code. You will then only have to do the following in your template file echo $page->body;// RTE body copy echo $page->widget_textarea;// will echo your <healcode-widget></healcode-widget> code Scenario 2 If your widget code will be appearing in between text, then you can either use Hanna Code only or a combination of Hanna Code and the widget_textarea. Then in your template file, you would only need to do the following: // since the body field has the Hanna Code, whatever that Hanna Code is returning will be displayed in the place where you placed [[widget]] // it will be specific to the page being viewed echo $page->body; If you want to go with Hanna Code, let us know and we'll give you example code

So maybe a setting in its own module settings to only autoload for specified/named modules? Is that even possible?

Hi @Maverick. Thanks for you custom. Currently, not out of the box. but should be very easy to achieve using your own JavaScript. It would go something like this Render your DynamicSelects form Next to it, in your template file, add your Go button or link Using JavaScript (e.g. jQuery) disable that button or link Once a 'last' selection is made, using JavaScript, change the value of your Go button/link to the URL of the last selection. For instance, if a link, we would change its href. On click, the user gets redirected to the selected 'URL'. Initially, I was thinking the developer could build in the 'URL' themselves, i.e. build it client-side using JavaScript, from the select option's label. For instance, if we have a city Berlin, we would build our ProcessWire URL off that. But that is not very friendly. I think it will be better if a I added a third $options argument to MarkupDynamicSelect's render() method. You can then specify what extra info for the results to return, e.g. url was passed in the options, it would result in: <select> <option value='1234' data-url='/continent/country/city-page-1/'>City 1</option> <option value='1235' data-url='/continent/country/city-page-2/'>City 2</option> <option value='1236' data-url='/continent/country/city-page-3/'>City 3</option> </select> You would then grab the selected option's data-parameter, e.g. in the case above, data-url, and do whatever you want with it. Is there any other value you think would be useful to return other than url? i.e. what other data-xxx would be useful? Thanks.

Yesterday I tested what @kixe said and it worked...to some extent. I could get the tabs but their content (i.e. all but the first tab's) were not getting loaded until one reloaded the page. I didn't have time to investigate further so left it at that. Basically, you would need to do three things: 1. In your module's getModuleConfigInputfields method, initialise WireTabs module. It is a static method so you would need: wire('modules')->get('JqueryWireTabs'); 2. Include the JavaScript that initiates WireTabs client-side: For instance, if you had that code in your NameOfYourModule.js, you could do this in your getModuleConfigInputfields : $dir = wire('config')->urls->ProcessModuleName;// whatever your module is called. Here we assume a process module wire('config')->scripts->add($dir . 'ProcessModuleName.js');// or whatever file you have your JS in, e.g. config.js The code in your .js file for your Tabs: $(document).ready(function(){ var $form = $("#IdOfYourForm"); // remove scripts, because they've already been executed since we are manipulating the DOM below (WireTabs) // which would cause any scripts to get executed twice $form.find("script").remove(); $form.WireTabs({ items: $(".WireTab"), skipRememberTabIDs: ['ProcessModuleNameTabID'],// if you need this option rememberTabs: true// if you need it }); }); The ID of the form is the tricky bit. I am not sure if you can use your own form ID in getModuleConfigInputfields. I tried but it was not getting recognised. If not, try using the existing form's ID which would be: ModuleEditForm. 3. Still in getModuleConfigInputfields, build your inputs, add them to your tabs which you then add to the form. I am too lazy to type now, so please have a look at modules that use tabs...Hanna Code, Menu Builder, Batcher, etc on how to do this.

CKEditor is stripping out your code since <healcode...> is not a valid HTML tag. You can tell it, via its ACF and/or Extra allowed content settings, to allow that tag, though am not sure even that would work. Another possibility is to use Hanna Code to insert that code at runtime. Parameters would have to be passed to it (the values you want the client to be able to change) so as to render them at runtime. The Hanna Code would be could like so in your body field: [[widget a=value1 b=value2 c=value3]] where a, b and c are the parameters whose value the editor can change. You can rename them to something your client would understand, e.g. type,partner,id, etc...However, do you still want your client to be editing the Hanna Code like that? Alternatively, you can create a field(s) to store your editable values and via the Hanna Code, tell it to read from that field(s). Or, if the values will always be coming from a set pool, you can save them beforehand to a pagefield. The client would then have select the applicable values in that pagefield. Hanna Code would then grab the values from that pagefield. Note that the above is not the Hanna Code code itself; just how to call it on your page. Anyway, please describe your scenario with a bit more specifics so that we can tailor our responses to that.

Update: Jquery File Upload Version 0.0.4. Changelog Fixed a small bug introduced during the last commit. This causes some images not to be displayed in image gallery.

Media Manager version 008 (released 09/12/2016) Happy to announce the latest release of Media Manager. Changelog Fully compatible with ProcessWire 2.8 and 3.x (@see note #1 below though). Fully compatible with repeaters including ProcessWire 2.7, 2.8 and 3 Fully compatible with Repeater Matrix Fixed bug in Media Manager insert-image-in-RTE feature. Please note, there are a some slight UI changes, but nothing major. Also @see note #2 below. Notes Maybe it's my environment or the file compiler but in ProcessWire 3.x, if you delete media, they are reported as not deleted until you manually refresh the page In case you didn't know, you do not have to use FieldtypeMediaManager/InputfieldMediaManager to insert images in the RTE Please also upgrade to version 004 of Jquery File Upload (uploaded today) A couple of people are reporting not getting confirmation emails after purchasing MM. I'm looking into this