kongondo

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

There's these two payment modules in the modules directory, for PayPal and Stripe. I'd go with the commercial e-commerce module Padloper though.

If going that route, I'd recommend you put your code in a file and call it via wireRenderFile() in the module. Have a look at the support thread for some of things guys have been able to pull off using the module.

Thanks...sorted..

Yeah, my whole server is! A server upgrade gone wrong; it might be a while. Sorry for the inconvenience...

Bit of an update, we are back in play with this one. Moved the doc-generation tasks to a remote server for reliability. PW 2.7 docs stay, although not getting updated, obviously. PW 2.8 and 3 branches getting regular automated doc-generation.

foreach ($pages->find('template=basic-page, limit=50') as $p) { $p->of(false); $p->title = "My New Title";// if using a new title...otherwise comment out this line $p->name = $sanitizer->pagenName($p->title); $p->save(); $p->of(true); } If renaming in the thousands let us know so that we can adjust the code...

Update: Blog 2.4.0 Changelog Fixed SQL error thrown when comments disabled and accessed blog dashboard. Thanks @justb3a Added capability to copy demo JS and CSS files on blog install as well as remove them on uninstall. Full compatibility with ProcessWire 2.8.x and ProcessWire 3.x. Thanks to @BitPoet Happy then to announce that I've tested and can confirm that Blog is compatible with ProcessWire 2.8.x and ProcessWire 3.x