Ivan Gretsky

I think it is more reasonable to compare PW+Padloper||Snipcart||... not with Magento or WooCommerce, which are well established and feature rich but less configurable systems, but with Drupal+Commerce module. Drupal8 is out (with much more fanfares than PW 2.7 ) and Drupal Commerse 2 is on its way to stable. For now it seems like we are not quite ready to compete with either, at least in the field of achieved. I think that can change as first Padloper projects will appear showing its true capabilities and as Antti releases his so long-waited shop profile.

Nice and clean! A few things... (isn't that what you are after ) 1) On mobile hamburger menu on-hover cursor should be pointer. 2) On the blog page there is no current state for pagination.

Taking a look at this it seems like you can achieve what you need. Did you try it in latest version?

I am using HeidiSQL too and like it just like kongondo. But I believe the question was about the use of a remote database with a localhost installation (of a PW, probably?) So you could just copy or git clone your site and start working not even changing the db in the config.php? If so, I would say having your own MySQL is cheaper for someone already having some kind of db hosting. But you have to set up SSH port forwarding to access your remote db (which scares me as (yet) windows user) or lower the security by allowing the access to it not only from localhost. As I could understand Google SQL is the same MySQL but with some restrictions. I do not know their benefits, so would probably go with my own MySQL instance.

If you only want to prevent saving the current field, you probably could modify the code above to be hooked before FieldtypeMulti::savePageField and add something like this in the end: if($page->your-field == "now-value" && $pageBeforeChange->your-field == "before-value") { $event->replace = true; } This should replace the whole FieldtypeMulti::savePageField and prevent the field from being saved. Not tested. No guarantees .

@LostKobrakai: But Pages::savedField does have different arguments to Pages::saved. So you would probably have to write different code for the hook functions? @valan: I managed to solve similar task hooking FieldtypeMulti::savePageField. This works for something derived from FieldtypeMulti. To hook fieldtypes extending Fieldtype class you can hook Fieldtype::savePageField. Here is the code: public function init() { $this->addHookBefore('FieldtypeMulti::savePageField', $this, 'saveFieldtypeMulti'); } public function saveFieldtypeMulti($event) { // Get current page and field $page = $event->arguments[0]; $field = $event->arguments[1]; // Perform all the check to execute only when needed if ($page->template != 'your-template') return; if ($field->name != 'your-field') return; // Get the instance of the page from db as it was before the edit session. $pageBeforeChange = $this->wire('pages')->getById($page->id, array( 'cache' => false, 'getFromCache' => false, 'getOne' => true, )); if($page->your-field == "now-value" && $pageBeforeChange->your-field == "before-value") { /* send email */ } } This should work whether you save the page or just the field.

I guess not. If it is something like Pages::saveReady, it is only called on $page->save() but not on $page->save($field, $value).

Wow! Your real face is as pixelated as the avatar (judging by the photo). But it will only provide more trust to someone speaking 'bout our more-and-more-digital future . I would come if I had any futuristic means to transport my presence over 2500 km cheap enough.

I think this example by Ryan looks quite similar to what you're describing. Check it out.

Like what and for what purpose?

I ended up using hook on before FieldtypeMulti::savePageField which seems to be triggered everywhere. I think I was using an after hook (as I did for saveReady and saveFieldReady) instead of before earlier.

Can I bring this up one more time? I am searching for a way to modify a field (it is a Profield Table if it matters) in a hook before save. And the hook should run both when I save the entire page and when I only save the field. I might be wrong, but it seems like saveReady hook only runs when saving the entire page; saveFieldReady only runs when saving the field, but not the entire page, at least it does not show messages in admin; so does FieldtypeMulti::savePageField. Is there a way? Edit: It might be that saveReady and FieldtypeMulti::savePageField do not work only from admin, but not depending on wheather I save or save('field').

I did try this and it did not work, because getById returns a PageArray, not a Page object in spite of the get part in the method name. Using something like first() on the returned result seems to give you the cashed (changed) version of the page. But there is a getOne option that managed to do the trick. So I could only get it to work like this: $oldPage = $this->wire('pages')->getById($page->id, array( 'cache' => false, // don't let it write to cache 'getFromCache' => false, // don't let it read from cache 'getOne' => true, // return a Page instead of a PageArray ));

Thank you, diogo! As we are in tutorial mode here, it is worth mentioning the benefits of this approach versus the common echo / print_r / var_dump. I can think of two: You can check variables on the live site, where outputting things in the document html may scare site visitors. In some cases, for example in Reno theme, html output is hard to find and read on the screen. So console log is simply clearer. I am not sure (as I have not tested it), but this technique may help debugging PW admin with its redirects.

It seems like you are trying to use "delayed output" aproach as you are extending on a standart site-languages profile. You have to put all the html generated in gallery template in a $content variable for it to be rendered in the _main.php. Like this: foreach($page->images as $image) { $thumbnail = $image->size(150,100); $content .= "<a class='gallery' rel='gallery-1' href='{$image->url}' title ='{$thumbnail->description}'><img src='{$thumbnail->url}' style=' padding: 5px;' ></a>"; }

Maybe not as convinient, but if you are comfortable in editing json, you can export a text field with built-in PW field export feature, paste the generated code to text editor, duplicate it as many times as you want, edit nearly all the field's properties and import it back into your site.

This is really awesome! Something to be proud of. I really need a few of your tricks on my current project so digging into the frontend source)

Come on, adrianmak! You are on the block for a while now and know that all the cool kids use dev branch. I can't live without the Saturday morning presents on the blog and certainly do not want to wait for half a year to get them) There are no hotfixes to stable branch (at least that I know of) so really no point in staying behind.

@Sradesign: Those are wonderful examples of what a custom admin theme for PW could look like. I do not think though that Tom should change his theme or incorporate any of it's parts including bootstrap. I am sure if you or me shall spare some time and actually produce the theme, it can under certain circumstances be included in the main PW branch as a third alternative. But it will actually be even simplier for it to just be distributed through modules directory (and it will save us from the need to keep it up to date ). I can see some troubles using bootstrap though as not only the chrome but all input's markup should be rewritten for that purpose. @renobird: I would like to ask your for a favour for PW community to share your knowledge about custom admin theme creating. If you could find some time and produce a little post with a tutorial on this topic it would be incredibly valuable, as Ryan's tutorial on this is rather outdated and probably no longer accurate. Personally, I am even more interested in creating not a complete admin theme replacement, but a theme with a limited functionality for non-superuser site editors.

Thanks for the explanation, Ryan. Clear, clever and polite as always. I thought that this could be related to Avoine new project on top of PW. And it is... but in a broader sense. And I guess Teppo is right. For the sake of nurturing a devoted and confident open source community such questions should probably be debated for a while.

I think you are right about that. But the task would require a team of well informed and highly capable people to help Ryan as it is probably not the task that could be easilly managed by one. One man is just not enough to manage both the developmrnt and the documentation (and the promotion, and the translation...) Some day the time will come to gather forces, so better get prepared - read the code and learn to write!

In the comments to the latest PW blog post Teppo noticed the licence change that seem to be present in the new 3.x branch of ProcesswWire. It has changed from GPL2 to MPL2. What does this switch means to us? Earlier Ryan said that he is not so much into legal matter and just goes along with the big players like Wordpress and Drupal in the field of licencing, Obviously that is no longer the case. I am no expert in this matter, but as I can guess MPL2 will allow to produce a commercial version of PW to exist alongside with a community one. I am starting this topic to find out about what real difference the licence change will bring and to find out about the core development team plans concerning future of PW development.

Another question. I try to tanslate the theme, but with no luck. I did add AdminThemeRenoHelpers.php for translation and added translations for strings I needed - the strings still appear in English. I can easilly translate strings from the core files like admin.php. What can it be?

Hallo, Tom! Could you please hide the profile link in the avatar dropdown for users without profile-edit permission like you did in footer?

I found this thread and it is a treasure for anybody doing some custom backend stuff! I still don't get half of it, but the answer is certainly there. Edit: Can't make the topic "solved" as this thread probably does not alow this.