owzim

@Robin S thanks for the report. I will add an extra json settings field for modes in the field config. I am sick right now but I'll look into it, later this week. Edit: Can't test right now, but you might be able to set this in the advanced options of the field config.

Hey, I wonder if there is any interest, that this module is developed any further and that I fix the mentioned issues. It seems like, with things like front-end editing and/or ProDrafts it's kind of obsolete.

Google's Matt Cutts: Source: YouTube

Hello @werner, welcome to the ProcessWire forum. The fact that you're fiddling with sql suggests that you are an advanced user, so why inject PHP directly into a text field? That's not what it's for. If you really want to execute individual PHP code on each page, you might want to use something like Hanna Code.

Not sure what your goal is, with all child pages from a parent you mean all siblings, right? Do you want to select them? Use the page field: Create a field: Details Tab: Input tab: Add the field to your template. Now the Siblings are listed on your page edit screen:

For import of the hikes with images, you could use the ImportPagesCSV Module. I've used it for many simple occasions. A breeze. You will have to create a template with fields you need for your hikes. On the import screen, you can assign columns to fields and as long as the images are provided as http links the module can access, download and import them just like that. If your site structure is not too complex you might as well migrate all data this way.

Pushing code without any kind of testing?

If your module extends Wire or any Wire derived class, you should be able to this in your init() method. public function init() { $this->wire('html', $this); } Are you sure the module is loaded when the template is rendered? See the autoload option in your modules config: public static function getModuleInfo() { return array( 'title' => 'Example module', 'version' => '1.0.0', 'singular' => true, 'autoload' => true, ); } You could also load it manually: $html = $modules->get('ModuleName');

Should not look dodgy, I just tested it with 3 columns as well. Works. Field widths are 33%, 34%, 33% to make 100%. Edit: Ah now I know what you mean, yeah ... well. Not out of the box, you might want to inject some custom JS to take care of that. Or you populate the second empty field on page save with a hook: // not tested, off the top of my head $pages->addHookAfter('save', null, function($event) { $page = $event->arguments(0); if (!$page->secondField) { $page->secondField = $page->firstField; $page->save("secondField"); } }); Don't know about the second thing.

Yes it's possible with Field Dependencies. Set the visibility of the second field to yourDropdownFieldname=valueOfSecondSelect. The first field will take up the remaining space, if the second one is hidden. Edit: If your dropdown is a Page Field, the value should be the page ID of the selected item, not sure if it also works with the Select Options Field .. it should. If so, then it's the value you specified.

Thanks, I am actually in need of that feature in a current project. So hurry ... jk edit: As far as I know the page field stores multiple values just as comma separated ids

@kongondo, at the end of the select chain one might want to select multiple things, like on regular page selects. For example a list of employees: Company > Location > Department > Jane Doe, John Doe and Max Mustermann

Hey @kongondo, does your awesome module also work with ASM selects?

Just to clarify, when I say "no complex code in your templates" I actually mean no complex code mingled with your html (xml, json or whatever your output is). In the case of TEF your templates act as controllers, hence can have complex code, but the views are separated. You don't even need a module to implement this methodology Here's a post by @teppo with an example hwo to do it with the tools included in PW core:

@FrancisChung good question. Any business logic should be separated from the view layer. A template is a view, code there should not be complex. Loops, perhaps some string concatenations, value calls, nothing more. You want a template designer not to fiddle with your code and perhaps even break something. Even if you are the template designer. For complex logic use Modules, Template Data Providers or something like the Controller/View separation used in Template Engine Factory I understand that this is perhaps not the ProcessWire way, right out of the box, or at least not something that is advocated too much, but I think it's because ProcessWire does not dictate how you use it. MVC ... or just VC in this case is just one way to do it. For simple sites perhaps overkill but if your code grows more complex, the VC concept makes the project more sustainable and it's a well established concept.

Every site I build has an own module, where I put all my hooks and additional logic. Also I use an autoloader there to load all the custom classes. They reside in a psr-0 structure within the modules directory. Anyway, I would not recommend using class calls within your templates, rather encapsulate all logic/data needed by the templates in module properties/methods. Perhaps the TemplateDataProviders module might interest you.

Awesome! Especially the defineOptions feature.

A search on forum members, located in Berlin, turned up the following list: @blickwerker @Bron @ceberlin @chrizz @Dave Damage @dlen @FrancisChung @marcus @Mitko @neophron @Nico Knoll @ottogal @owzim @Philipp Nowinski @RSA @sisterlarao @skries @symb Some of them haven't been active recently, but perhaps a mention will get their attention.

Hey @kongondo I just recently came across this module in a existing PW project I had to take over. I knew about it's existence but never tried it myself. Great and useful features, thanks!

Welcome @handzain!

@Nico Knoll seems to be inactive at the moment, last seen on June 5. We should get @marcus aboard too. Making noise at the PHP meetup could be a task after New Year's. I am available on Mondays, Tuesdays and Fridays and definitely like to meet up before Christmas.

@szabesz sometimes live changes break the existing site if you don't have the necessary files (e.g. template files). Also, working on a live site's structure ... breaking stuff. Rather locally. It's kind of cumbersome, but this is how I do it: I lock the site for edits (in consultation with the client of course), clone the db, make changes locally and update the db when finished. Here's a small recipe for adding a maintenance mode.

@usillos You included we are 4 people that I know of using PW and living in Berlin. The other guys are @marcus and @Nico Knoll. And we're all have to find a date where we're all available. Not enough devs from Berlin as of now, I think

@thlinna I have been working on a module, a more non-dev-friendly approach the migrations module for about one year (on/off). I am actually using it all the time but it's not ready for public. It has many bugs I know how to circumvent and next to no documentation. It's similar to JSON Installer module, but more powerful and the data files are written in YAML. Perhaps JSON Installer can be of help to you.

@Robin S looks great, thanks. Can you name a use case? On a side note: What are you using to record the screen and export to gif? I tried gifrocket, but even with a small framerate, files get pretty large. Yours is tiny, I like it.