Leaderboard

Ah, there's light at the end of the tunnel. Those annoying cookie banners required by a misguided 2012 European law might soon disappear. One less thing to implement...

$children = $page->children("template=article"); foreach(['A', 'B', …] as $letter) { $startingWithLetter = $children->find("City^=$letter"); if(!$startingWithLetter->count()) continue; // Do things here } Only the first find is a call to the database, while all the other ones in the foreach are just in memory searches and therefore quite a bit faster.

@Speed You are welcome. Even better to change the document root in your web server setting.

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.

it is better to do it the other way. Upload the new site to a sub folder. After you test it, create a redirect in the original folder to redirect all the request to the new site.

The image field default setting is to output an array, so if you only want to output one image of the page, try on your loop: $event->images()->first()->url;

There are several options: 1) The easiest option would be in the Console Panel in TracyDebugger 2) Converted to an action for the Admin Actions module - this would be a great option because I expect there will be lots of users wanting to convert from Thumbnails to Croppable image over the next few months - hint hint @netcarver, @horst, or @jacmaes 3) In a test hanna code 4) In a template file 5) In a bootstrapped script in the root of your site

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.

Pretty much exactly what I offer as a web designer -> look at wix or sqaurespace and if you want to do something more interesting in functionality or design then come to me and I'll make up a PW site with the extra requirements. I like working on new and interesting projects not just banging out the same site again and again, so PW works well for me. Plus the community are super helpful! I never enjoyed the swamp of wordpress and drupal modules and forums

You might be interested in this recent thread about rendering page content to an 'index' field with a save hook. I only tested it briefly but with this approach you are in control of what is saved to the index - so for Page fields for example you can save the title or any other subfield you want.

Which cache? Template cache you would go to the PageRender module settings and delete cache.

Updated and fixed Russian Language Pack. Completed translation main part of the administrative panel. Add Translation for some popular modules like Markup SEO PW-PW-LanguagePack-ru-RU-master.zip

Any way to enable the Auto Links Textformatter for a Textarea Rich Text (CKEditor) field on a ProFields Table? Works a charm everywhere else, but can't seem to crack the settings to get it to link content within a ProFields Table. Thanks!