Ivan Gretsky

@elabx:I found this answer for you. Guess It all makes no sense without ssh.

I am yet trying to encorporate this in my workflow, but deployer seems to be valid alternative to capistrano. And it is in PHP, so no need for Ruby. The developer is Russian, so that gives me a little pride. A lot of Capistrano maintainers are also my fellow contrymen - just to point that we not only bomb and confront . @pwired: There seems to be a web interface to deployer too. You can see it on the frontpage of offsite and the source is on github/ At least i think I saw it there.

Ahh! Got it! You need an admin interface to easilly manage those guestbook submissions. 1) BernhardB's listerpro suggestion is what you want to go for if you have the option to use this paid module. It is really powerfull. 2) You could build a process module to list all guestbook submission for free, but you need to get your hands dirty with code . You can take a look at something like this for an inspiration: class GuestBook extends Process { public function init() { parent::init(); // always remember to call the parent init } public function execute() { $out = ''; $table = $this->modules->get("MarkupAdminDataTable"); // Table header $table->headerRow( ["Name of submission", "By whom...", ...] ); // Selector to get all your guestbook submissions $listing = $this->pages->find("..."); foreach ($listing as $page) { $data = array( // A td with the link to edit the page (you need to change the ... part) $page->title => $this->config->urls->admin . ".../edit/?id=" . $page->id, $page->created_by, ... ); $table->row($data); } $out .= $table->render(); $pagination = $listing->renderPager(); $out .= $pagination; return $out; } public function executeEdit() { // Write code to edit submission } // ... }

Sorry, but I could not understand what you are questioning about. Could you please try to rephrase and be more specific?

I am not sure that I understand what you are trying to achieve. Why do you want to sanitize $this->pages->get("template=location, title=$lpTitle")? It is not a user input and will return a Page or NullPage anyway. No commas . If you need to get the id just use $this->pages->get("template=location, title=$lpTitle")->id. The notice you are getting is from ProcessXMLImport module and is not directly connected with the code you presented.

Maybe this can help you to start off?

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.