Jump to content

PW 302 - Front-End Editing


Tom.
 Share

Recommended Posts

Hello,

I'm currently working on a website using 3.0.2, I would like to utilise the front-end editing. However, I have the module installed but I'm having a little trouble. 

I have a settings page that holds contact details and social links. I use these on different occasions throughout the site. So to access it I would usually use:

$pages->get("/settings/")->contact_number

So to enable editing I would have assumed this would work:

$pages->get("/settings/")->edit("contact_number")

I find that the number displays correctly on the front page, however it is not editable. 

In this case I used:

<edit 1016.contact_number><?=$pages->get("/settings/")->contact_number?></edit>

Which works like a dream :-) 

I'm unsure whether this is a bug or not as I'm not entirely sure if $pages->get() would fall under "Note that $page can be any Page object, it doesn't necessarily have to be the current $page." 

If anything I just thought it was worth asking :-)

Link to comment
Share on other sites

Tom, check your PageFrontEdit module settings page to make sure you've got the option enabled to allow editing of pages other than the current. This is a new option added in 3.0.2. previous versions let you edit anything anywhere, whereas this version let's you lock it down a little more, and it comes that way by default. but you can turn it off from the module settings page.

  • Like 1
Link to comment
Share on other sites

Tom, check your PageFrontEdit module settings page to make sure you've got the option enabled to allow editing of pages other than the current. This is a new option added in 3.0.2. previous versions let you edit anything anywhere, whereas this version let's you lock it down a little more, and it comes that way by default. but you can turn it off from the module settings page.

Hi Ryan, I apologise for my ignorance. I can't seem to find that setting. I guess the next question would be; Is there any performance hit due to accessing the edit functionality this way? I was just wondering the reason behind locking it down and whether I should avoid it if possible, using the other options such as Option C or D (as per my example).

Thank you for your response Ryan, I've attached what I see

FjVUUyS.png

Link to comment
Share on other sites

Hi Ryan, I apologise for my ignorance. I can't seem to find that setting.

@Tom - that setting will appear once you check one of the fields.

Ryan - the one thing I am noticing is that there is no way to choose B,C, or D. Nevermind I see that you don't need to choose the other options!

But, I am also wondering what you think can be done about this:

post-985-0-81095700-1449948231_thumb.png

Notice the area of the paragraph - that translates into the area that is triggerable for edit mode by double-clicking - so the user mouses over the bottom half of the image and it looks like they can double-click on that and edit the image, but they can't - it just makes the paragraph editable.

Link to comment
Share on other sites

@Tom - that setting will appear once you check one of the fields.

Ryan - the one thing I am noticing is that there is no way to choose B,C, or D. Nevermind I see that you don't need to choose the other options!

But, I am also wondering what you think can be done about this:

attachicon.gifScreen Shot 2015-12-13 at 5.22.06 AM.png

Notice the area of the paragraph - that translates into the area that is triggerable for edit mode by double-clicking - so the user mouses over the bottom half of the image and it looks like they can double-click on that and edit the image, but they can't - it just makes the paragraph editable.

Hi Adrian, 

I see that it appears when clicking a field, but clicking a field would make it automatically editable (Option A). I don't want that. I'm using option B in the example given in OP. So far I will stick with Option C as it's working for me and seems like the most flexible in most use-cases. I just thought it was interesting that Option B wasn't working in this case. 

I selected a random field ("email") different to the one I was outputting using (Option A) so the Field on other pages radio button would appear. Then used Option B to output the field I want ("contact_number") and it works now.

However I if the Field on other pages isn't going to be exclusive to Option A then I would argue it would always need to be displayed so it could be used with Option B. 

I am still curious to know if using this method produces any performance problems, I'm just curious about the reason it being off and being recommended to be turned off by default. 

(Is using Option C the standard when it comes to fields that exist on another page?)

Link to comment
Share on other sites

I don't think that option is relevant for modes B, C & D, because they require you to manually specify the page that the field is on or they just don't work. eg,

<edit field="image" page="<?php echo $other_page->id; ?>">

I am not sure about the performance issue - will wait to hear what Ryan says.

  • Like 1
Link to comment
Share on other sites

Hi Ryan, I apologise for my ignorance. I can't seem to find that setting. I guess the next question would be; Is there any performance hit due to accessing the edit functionality this way? I was just wondering the reason behind locking it down and whether I should avoid it if possible, using the other options such as Option C or D (as per my example).

Tom, sorry that field was behind a showIf dependency for the inline edit fields checkboxes, like Adrian mentioned. It's actually only supposed to apply to those checked fields, which is why it didn't appear. I was replying from mobile before and was forgetting this. 

That particular setting really is only meant to apply to those checked fields, so your $page->edit() wasn't working as a result of a bug, which I have pushed a fix to 3.0.2 just now. You should now be able to use $page->edit() with any field regardless of page. 

There's no concern about performance hit here. The reason it's recommended off is only as a default setting. For instance, let's say you've got a "summary" field in your page and you are rendering search engine results that include that summary. You probably don't want the summary to be editable in all those search engine results, whereas you do want it to be editable when you are actually on the page. So the setting is just there to reduce confusion since chances are, most of the time you'll only want to have a field editable when you are on the page it is owned by. None of this is meant to apply to options B through D since you are already in control of it all from the API side. 

Notice the area of the paragraph - that translates into the area that is triggerable for edit mode by double-clicking - so the user mouses over the bottom half of the image and it looks like they can double-click on that and edit the image, but they can't - it just makes the paragraph editable.

I don't think there's much we can do about it, if that image is not part of your field there. However, if it's a concern, you may be able to add something like this to your css file to adjust the cursor:

#your-container img.your-image {

  cursor: pointer; 

}

  • Like 1
Link to comment
Share on other sites

Tom, sorry that field was behind a showIf dependency for the inline edit fields checkboxes, like Adrian mentioned. It's actually only supposed to apply to those checked fields, which is why it didn't appear. I was replying from mobile before and was forgetting this. 

That particular setting really is only meant to apply to those checked fields, so your $page->edit() wasn't working as a result of a bug, which I have pushed a fix to 3.0.2 just now. You should now be able to use $page->edit() with any field regardless of page. 

There's no concern about performance hit here. The reason it's recommended off is only as a default setting. For instance, let's say you've got a "summary" field in your page and you are rendering search engine results that include that summary. You probably don't want the summary to be editable in all those search engine results, whereas you do want it to be editable when you are actually on the page. So the setting is just there to reduce confusion since chances are, most of the time you'll only want to have a field editable when you are on the page it is owned by. None of this is meant to apply to options B through D since you are already in control of it all from the API side. 

I don't think there's much we can do about it, if that image is not part of your field there. However, if it's a concern, you may be able to add something like this to your css file to adjust the cursor:

#your-container img.your-image {

  cursor: pointer; 

}

Thank you very much for your great work Ryan. Also your explanation was very helpful. :-) That's exactly where my confusion laid, I suspected it was a bug :-) 

Link to comment
Share on other sites

I don't think there's much we can do about it, if that image is not part of your field there. However, if it's a concern, you may be able to add something like this to your css file to adjust the cursor:

 

#your-container img.your-image {

  cursor: pointer; 

}

I have made the image editable as well though, so the problem is that the clicking on the top half edits the image, but on the bottom half edits the text, so not something that is acceptable - too confusing for the user. I understand the technical limitations though so not a criticism - more of an observation of a limitation.

Link to comment
Share on other sites

I have made the image editable as well though, so the problem is that the clicking on the top half edits the image, but on the bottom half edits the text, so not something that is acceptable - too confusing for the user. I understand the technical limitations though so not a criticism - more of an observation of a limitation.

This is a complete guess, but since the actual edit links have an ID for example pw-edit-1, are you able to apply a CSS z-index using:

#pw-edit-1 {
position: relative;
z-index: 999; /* Probably something less ridiculous ***/
}
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...