Jump to content

Joe

Members
  • Posts

    143
  • Joined

  • Last visited

Everything posted by Joe

  1. Thank you for these pointers, Ryan. Yes, I´m trying to do it with CKEditor (although if I felt that it could be done better with another editor I would use that - I will not need a lot of functionality, as I obviously have to limit the options to protect page integrity, so basically the editor just needs to work well and provide clean markup, it does not need to have a huge amount of features.) So I´ll get busy trying to implement this...
  2. Thanks, Soma, this is what happened, I´m almost sure. Anyway, as I wrote above, I have been easily able to fix the issue and to me it´s not a problem now. Maybe it might be good to include the above information with the module somewhere.
  3. Hi teppo, thanks for the quick reply well, the folder in site/modules is "teppokoivula-ProcessLoginHistory-11af3f7" now. This is after the update, but I actually see in a previous install, that it is called the same there. No, there are not two folders for this module in the modules folder. EDIT: I boldly went ahead and tested updating Modules Manager on another version of my PW site... That went without a hitch. After that I updated the ProcessLoginHistory module again, using Modules Manager and bang, the site was down again! Then I erased the ProcessLoginHistory module folder manually and de-installed the module: the site is working again. Now I have installed the LoginHistory module, using Modules Manager, the install went without a problem and the LoginHistory module works. To me there is no problem left and all I can say is that apparently there are circumstances under which an update of the LoginHistory module using Modules Manager fails, whereas a new install works. And when the update fails the site goes down completely (which I guess is of concern for future users, especially on a production site). By the way, the first occurrence was under the latest stable version, the second under one of the latest dev versions. So it probably will be hard to pinpoint the problem. Anyway, both the ProcessLoginHistory module and the Modules Manager are good modules and seem to be working well!
  4. Hi. I just ran into an odd problem, not sure what happened: First I updated a few modules using a previous modules manager version without any problem. Then I updated the teppokoivula-ProcessLoginHistory with modules manager. After that the whole site was out and I got this E-Mail error notification: Compile Error: Cannot redeclare class ProcessLoginHistoryHooks (line 22 of /xxx/xxx/xxx/xxx/site/modules/ProcessLoginHistory/ProcessLoginHistoryHooks.module) (xxx = server specific, my server) I don´t know whether the problem here was caused by the module itself or the modules manager. I fixed it by replacing teppokoivula-ProcessLoginHistory with the previous version from my local install. Now I don´t know if this is related, but after that I updated modules manager itself. Now it shows me "new version available!" messages for modules I´ve just previously updated, but there are no update-links for any modules, as there were before. It is not a serious problem for me, as this is a test-install and of course I can update in the traditional way, but I wonder what might be the problem...
  5. Maybe just a php line like $content = str_replace(" ", "", $content); in the template file before outputting the db content would do the trick here? EDIT: => But it is obviously a cleaner approach to filter the content before writing it to the db...
  6. Yes nice site design. And great they allow dogs, would not go there otherwise... Cheers!
  7. You have a point there. But on the other hand it just feels good to edit things "on the fly" and people go for it. Changing content easily is what a CMS is about after all. Whether in-page editing is preferable for a site or not will really just depend on the setting I think.
  8. Joss, I think you are making a valid point about issues with front-page inline editing here. I believe it just depends on the kind of site: The reason I am so interested in making front-page editing work smoothly is that I´m intending to create a CMS/site structure ideal for small website owners. These sites are often managed by one person only and they normally do not need versioning. As to drafts and previews: I do agree that this would be ideal, taking things a step further. I could imagine that instead of actually editing the live pages directly things could be set up so one would edit a sort of "shadow-version", a page that looks just like the live page but only overwrites it once you choose to do so. However the draft/preview functionality is not contained in a standard PW setup now either. You can only work on a draft version while you keep it unpublished. I´m not proposing to eliminate that when implementing in-page editing, but you could only do it on an unpublished page in the back end, same as now. If you work on an already published page any change you make goes live once you save it, unless you set it to "unpublished", but that is the case now too. About forgetting to publish: Well yes, it can happen, same as it could happen now if you click on a link in the back-end after editing a page without clicking "Save" first. I don´t see a difference there. (In either case, maybe a JavaScript popup warning might be something worth implementing to avoid this). It applies to back-end editing also, as you are saying here and I have written above. I don´t really understand then why you think that spontaneously making changes would affect the site differently if done on-page rather than in the back-end?
  9. I agree. I think the issue with in-page editing is not that it is technically speaking a better solution. But the spontaneous response by a lot of (prospective) clients is just too positive for it to be dismissed (...or they will go somewhere else!). I just recently showed my PW demo site to someone, they liked it, but the spontaneous feedback was that it would be even nicer if content could be edited right on the page. The thing is, I´m talking about small website owners, not people running a newspaper or large company website (who presumably are IT-pros). And to them the more intuitive the thing feels, the more appealing it is... Obviously one has to strictly limit the options people have when editing, but that is the same when using RTEs on the back-end, to me it really is only about the CMS feeling more intuitive with on-the-page (inline) editing, not about new functions. I truly like PW and feel that after a fair bit of searching I have found the CMS I really want to use - but it is pivotal to me that I get front-page inline editing running. I already have it working for text content using CKEditor (it´s easy, if someone needs some help with this I´m happy to post it.) But for handling images and links within the PW structure I still have to send users to the back-end, hope to be able to fix that soon.
  10. Ryan, as I´m currently struggling to integrate front-end inline editing into my site design, what you are saying is valuable input for me. I agree that it is a good idea to limit clients to creating semantic markup. For a certain kind of user, namely small web site owners with limited computer skills, it is very appealing to edit things right on the page. And let´s face it, it just does feel more intuitive than having to go to the back-end. So basically look and feel is the reason I want my pages to be editable that way. I would not give clients more editing options in the front end than they have in the back-end. It is of course the task of the site developer to insure that content can only be added in such a way as to be mobile-compatible for example. So if used in this way, I don´t think it can be said that front-end inline editors are a bad practice, any more than RTEs in the back-end. EDIT: I just saw the point you made here: ...yes, those really seem matters to worry about. In the headline example: I would make the headline a separate field. If it is just a text field they cannot input line breaks. With other problems I suppose it is either possible to eliminate the option of inputting non-compatible content or filter it out if done and finding an adequate way of letting the client know it´s happening. As I said above I do think that these issues are all similar as when editing from the back-end. Things come down to making the CMS interface more intuitive for the client, but more work for the developer I guess...;-)
  11. Well done! I really like the clear design. Only drawback seems it´s not adaptive. Are you planning a mobile version as well? (I´m not really a smartphone fan myself but it is becoming more and more important...)
  12. Great, but here I really don´t know how to call that module from the front end, I´ve tried but could not get it to work so far. Actually the module to create links (ProcessPageEditLink I believe) would have to be called in the same way too. If I could get these two modules working in this context I would have full inline WYSIWYG editing on the front page for logged-in users. I think that would be very attractive for a lot of people. (I´m specifically talking about small website owners whose computer skills are frequently limited to surfing, checking their mail and writing Word-documents ;-) Right now I got everything working, except I have to send users to the back-end for inserting images and links. Come to think of it, I might also want to make the image upload function accessible from the front end to make inline editing even more seamless. The page content could then be managed completely from the front-end. One would only go to the back-end to create pages, move them around and adjust other settings.
  13. Thank you, Soma! Yes, the Fredi module is nice. The reason I didn´t just use it is that I would like to have inline WYSIWYG on-the-page editing for logged-in editors like in this example. I might use Fredi to handle image insertion now, as this doesn´t seem to work via the CKEditor, as Ryan has pointed out. But the "&modal=1 solution" looks very interesting too!
  14. Thank you Ryan! I suppose if you say so, it really cannot be done. So I will stop trying to implement things this way then. I´m not sure if in my adaptation would be a security risk, since I will only allow logged-in site editors to access this function on the front-end. What I´m trying to implement is inline front-page editing to make the editing experience simpler for not so computer-savvy users. I suppose I will try to find some "hybrid solution" then, where they get sent to the back-end for adding images, maybe an adapted and simplified back-end page. Btw, happy New Year!
  15. Hi, I´m using CKEditor as an inline editor on the front-end. Now I need to call the ProcessPageEditImageSelect dialog when the CKEditor image button is pressed, just like when using the editor in the back-end. (Right now the standard CKEditor image dialog comes up.) Does anyone know how to integrate ProcessPageEditImageSelect here? Thank you!
  16. Thank you, teppo! Oh, of course I would not use this on a public server, this is just local testing. I was just pleased to get it working for a starter, already had the notion that this should be done via the PW API, just didn´t know how offhand. Thank you for your code, I will look at it and try to make it work._> Works great! => I created a hidden page and used it there almost as is, except for role and permission checking, because only logged in users who are allowed to edit pages anyway get to use this edit function.
  17. Ok, I got inline WYSIWYG on-the-page editing working now , here´s how: (This is only for one field so far, but it should be the same for multiple ones. It works, but some changes and improvements need to be made still.) In the page template file, or rather the included "head.inc": <!-- The paths to the scripts, CKEditor may already be in site/modules and jquery.min.js in site/templates/scripts, I use v1.6.4 - not sure what earlier versions work --> <script src="path_to/ckeditor.js"></script> <script src="path_to/jquery.min.js"></script> <script> // I saw this script here: http://gazpo.com/2011/09/contenteditable/ $(document).ready(function() { $("#save").click(function (e) { var content = $('#editable').html(); $.ajax({ // save.php and db.php currently are located in site/templates-admin - this may not be the best place for them. // I am still looking for a way to save the edited content though a built-in PW mechanism if possible rather than this way url: '<?php echo"{$config->urls->adminTemplates}"; echo "save.php"; echo "?page=$page"; ?>', type: 'POST', data: { content: content }, success:function (data) { if (data == '1') { $("#status") .addClass("success") .html("Data saved successfully") .fadeIn('fast') .delay(3000) .fadeOut('slow'); } else { $("#status") .addClass("error") .html("An error occured, the data could not be saved") .fadeIn('fast') .delay(3000) .fadeOut('slow'); } } }); }); $("#editable").click(function (e) { $("#save").show(); e.stopPropagation(); }); $(document).click(function() { $("#save").hide(); }); }); </script> <!-- Now the editable div with the content, in this case the body field content - only editable for logged-in users: --> <div id="editable"<?php if($user->isLoggedin() ): echo " contentEditable=\"true\""; endif ?>> echo $page->body; // THE CONTENT </div> <!-- And the status bar and the save button: --> <?php if($user->isLoggedin() ): echo "<div id=\"status\"></div><button id=\"save\">save</button>"; endif ?> Using CKEditor for inline editing is described here. The same approach should work with various other editors as well. Now for saving the changed content. It works, but I am not sure if this is the best way of doing it - PW may provide a better way built-in already. Both save.php and db.php also come from there: http://gazpo.com/2011/09/contenteditable/ THIS IS save.php: <?php $page=$_GET['page']; include("db.php"); $content = $_POST['content']; //get posted data $content = mysql_real_escape_string($content); //escape string $sql = "UPDATE `PW_test`.`field_body` SET `data` = '$content' WHERE `field_body`.`pages_id` =$page;"; if (mysql_query($sql)) { echo 1; } ?> AND THIS IS db.php <?php //database connection mysql_connect("localhost", "PW_test", "PW_test") or die(mysql_error()); mysql_select_db("PW_test") or die(mysql_error()); mysql_query("SET NAMES 'utf8'"); mysql_query("SET CHARACTER SET 'utf8'"); ?> That´s it. With this I get CKEditor as an inline-editor on the front-page body field and I can save the content via the save-button. To be able to edit the page the user has to be logged in. Some things remain to be adjusted: - The editor configuration - possibly it is necessary to sanitize the content, have to work out yet how to do it in this context - It might be nice to integrate the save-button into the editor if possible Also there is this security issue to be resolved: In order to use save.ph and db.php in site/templates-admin I had to remove the following line in .htaccess: RewriteCond %{REQUEST_URI} (^|/)(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ [OR] - Of course this needs to be done differently. These two files can be placed anywhere else. I think save.php needs to be protected from being used in an unauthorized way by some script. - Assuming I do not find a better way of saving the content through PW and don´t need these files at all.
  18. Thanks, Martijn, thanks teppo! So I´ll get busy looking at those.
  19. Hi, I have a field on a public-facing page that can be edited (by logged-in users only). I haven´t yet succeeded in making it saveable right from there. Thank you!
  20. Hi all, I´ve posted something about using CKEditor for front-page inline editing. Teppo has told me about this thread, so I just wanted to connect. I see the possible use of various editors for inline editing has been discussed here before. @apeisa: Your Adminbar module looks great. I´ve only become aware of it now. => I´v just installed Adminbar for a test and it really works well, but if editing could be done "right on the page" (inline) that would be even more intuitive for the end user.
  21. Thank you teppo, I hadn´t seen that thread. They are discussing exactly what I´m talking about. The option to do the same thing with CKEditor is likely newer than the thread, so now this would be an additional possibility. I haven´t had time yet to read through everything there but I find it very interesting. They also seem to be discussing the usefulness of this kind of front-page editing. I´m sure it very much depends on the kind of site and the kind of editors/users. But for a site with fairly straight-forward text and image content and for users who don´t have much computer knowledge I think it would be a very good thing. Of course it´s necessary to strictly limit the editor options so they can´t mess up the page. (Here´s a link to a page where some problems related to inline editing are being discussed.) I really want to implement this for a certain kind of site and I think it can probably be done already. And if it could be offered by PW as an out-of-the box module solution I think that would be a great additional selling point for PW.
  22. Hi everyone! I would like to provide inline WYSIWYG on-the-page editing. Ideally I would like my pages to be editable like in this example: http://nightly.ckeditor.com/13-12-19-07-06/standard/samples/inlineall.html The CKEditor option for inline editing is based on the HTML5 contenteditable attribute (like in http://html5demos.com/contenteditable) But with the editor there are the usual editing options, rather than only being able to change the text. Before coming to PW I´ve been toying with this little CMS: http://gpeasy.com/ I had chosen gpeasy exactly because it provides intuitive front-end editing (to me their previous version was almost more intuitive). It is a flat-file CMS and I would say it´s geared towards small projects only. I didn´t get on so well with adapting various aspects, mainly the back-end, and I´ve come to PW for its flexibility and scalability after looking at about 20 different CMSs earlier this year. (None of them provide front-end editing that way, except for gpeasy) So my aim is to build PW-sites that are editable like in the CKEditor example mentioned above. (Just the page content, not other things for which I find the current PW back-end pretty perfect.) So far I haven´t really worked out how to save the editable content on the pages to the DB. Actually I´m not quite clear on whether this would be only a simple tweak or a major project. Has anyone looked into this already? What are your thoughts? P.S.: I´ve looked at the Fredi module. It´s nice but doesn´t really seem to provide complete WYSIWYG on-the-page editing like I´m envisioning. I´ve also seen the Page Frontend Edit module, but somehow have not been able to make it work - I don´t expect it´s what I´m looking for. EDIT: I´ve just seen that they´re working on something sort of like this over at Drupal, using the Aloha Editor. From what the project looks like there I get a feeling getting this to run is not just a "simple tweak", even if it might be easier to implement in PW... => ...looking at the API now I think maybe it is not all too difficult to accomplish, we´ll see. Also with TinyMCE something similar is possible I see here. But I suppose whichever editor you use the same issue to solve is how to transfer the edits from the front-end to the DB.
  23. Hello Ryan, I´m not sure if by the above you meant that it´s been updated already - I just downloaded the latest PW version at GitHub and installed that. But the problem still persists. I have changed the line in config.php to "$config->uploadUnzipCommand = 'unzip -j -qq -n /src/ -x __MACOSX .* -d /dst/'; " (and back to the default for a test) and also verified again that exec is activated. So for the moment I don´t know... Like I said, this is not an urgent thing for me, just trying to work it out eventually... Greetings
  24. Thank you Ryan! Yes, exec() was disabled and I changed that. I was able to confirm that /usr/bin/unzip actually is the path on my server. But changing the line in config.php like you mention above didn´t have any effect so far. I upload the zip with the images field and it is shown there, but only as the zip, the zipped images therein are not displayed. But like I said, this is not an important issue for me at the moment, just tried to make it work in case I need it at some point in the future. I really would like to thank you for your fast responses when a problem is mentioned here in the forums. I´m amazed at how you find the time to sort through all the different issues so quickly! And also the responses from other members I have found most useful. All this together with the great functionality really makes it a pleasure to work with Processwire!
  25. Hi, just for a test I have installed the Frontend Edit module in an out of the box PW site. The module is installed but nothing happens, I mean I cannot find any new editing function. Maybe I´m missing something here? Thanks.
×
×
  • Create New...