Jump to content

Pete

Administrators
  • Posts

    4,054
  • Joined

  • Last visited

  • Days Won

    67

Everything posted by Pete

  1. I think it's funnier that he's supermom (I think that word filter is a leftover from when someone was posting links to all sorts of illegal film downloads a year or two ago).
  2. What is the reason you need this? If it's for the admin and it would be handy to be able to add links on either page A or B then that makes sense. However if you only need it in a frontend template there are other ways to find what page B is linked to without the need for having the field in both templates. EDIT: Martijn's code looks like it would do what you want though
  3. I've changed it so anyone can set the first tag as a prefix, however staff will need to be vigilant and see that it is being used properly (I believe the original use case was to clearly define the different types of topic in the module forum, which may not be a problem in future with some restructuring anyway).
  4. Nope, just one video link (I actually applied it to a text field in my case that is solely for the video URL), so I set my image field to only allow 1 image. Soemtimes I want to set my own thumbnail though, so in those cases when I've uploaded an image of my own the module grabs a thumbnail anyway and saves it to the image field I've set to only allow one image, so I end up with two images which shouldn't be possible. You're right, expected would be to replace the image already in there, but it would be nice (albeit tricky) to allow per-image field to somehow say "if a single image field and there is already an image in there, don't overwrite". Now there's a challenge I guess the obvious way around it for my somewhat unique use case would be to have another image field and just tell my template "if manual thumbnail field has an image in it, ignore the thumbnail grabbed by the module in the other field". I'll probably go that route since I'm not sure anyone else has this need.
  5. Hi Adrian This is a really great module that's helped on two sites recently. My only issue (not a huge one) is that I'm using a single image field. It, possibly unexpectedly, adds a second image (ignoring the fact that the field is set to only allow one image) whereas it might be nice for it to have the option somehow of detecting an image in that field already and not bothering adding another one. Certainly it having 2 when it's set to only allow 1 is a little confusing
  6. Pete

    jQuery Not

    I guess what I need is something like this (which is untested as I need to leave the house now and probably doesn't work): Basically for each hidden input, if the parent is hidden then remove it. That should capture everything I need it to then. $("#myform *:hidden").parent(":hidden").remove(); All suggestions are very welcome.
  7. Pete

    jQuery Not

    Hi guys For various complicated reasons I have fields re-used in a form with text around them, and various conditions show one set of text with the fields inline and hide the others. As such, it's a mess when I submit What I need to do is, on submit, remove all hidden fields (hidden by their parent containers not being visible, not fields with type=hidden) and exclude asmSelects from being removed since the field the ASMSelect data is stored in is always hidden. I had come up with something like this: $("#myform *:hidden").not("[type=hidden], name*='[]").remove(); But it's not idiot-proof really as 1) it doesn't work and 2) even if it did, I'm detecting ASMSelect's by searching for [] in the field name. These latter fields could be in a hidden section and should therefore be skipped. What I really need is to iterate all fields, remove all where the PARENT element is hidden and never remove input type=hidden and I think that would work, however my brain certainly doesn't work right now Any ideas? I know it's going to be a simple one-liner that I kick myself over.
  8. I've known people in large organisations (not saying which) turn down quotes because the price seemed suspiciously low. No follow-up discussion to ask why it was low, just discarded the quote in favour of a higher one.
  9. The only security vulnerability I can remember was in my own Minify module (not to be confused with AIOM) as it relied on this library: https://code.google.com/p/minify/ however as soon as I was made aware of that it was patched and updated. I can only echo what others have said above - you can never say with 100% certainty that there won't be a security issue discovered in software of this size, especially when coupled with all of the possible web server platforms and server module combinations. There are too many variables for anyone to say with certainty on any project that a security issue won't be found. There is more likely to be issues arising from our own code (not sanitising user input etc) than in the core though (that's my own experience anyway). The default templates even with search capability (user input right there) are build with best-practises in mind and offer several different ways you might want to build your front-end, but it's usually when you start doing your front-end work that you have to be careful - obviously PW is one of those rare projects where you don't need to upgrade a site if it works. If there were to be a vulnerability discovered, I would wager that you would have an easier time upgrading than with many other projects though (your front-end templates just won't instantly break for one because the API calls all remain the same!). I have been, for the last almost 4 years (wow, that's flown by) pleasantly surprised by the lack of a need to keep things up to date. I've never used Wordpress for my own sites so haven't suffered that rapid upgrade cycle, but have used MODx where every so often I've had to patch multiple sites. Now pretty much everything is on ProcessWire for me I've not had to do any of that. Choosing when to upgrade based on new features that might benefit the client, or might enable me to sell additional services to the client - that is the position we should all be in, not dropping everything to upgrade every couple of months But yes, the final line on security should be that none of us can say that a security issue will never arise, just check your module compatibility when upgrading (and it's best to test those modules locally as well because I think most will work on newer versions even if the module pages in the directory haven't been updated) and you should be fine.
  10. He means this, which will potentially be a quicker way I think of what you are describing with your process: http://modules.processwire.com/modules/process-export-profile/ So set up a new install with "basic business site features" and export that as a site profile, then when you do a new site requiring simmilar features, upload a fresh copy of PW to a server, copy your exported profile before installation and it should (I think) appear during the installer as an option
  11. Have you tried using the cache fieldtype to combine multiple fields' data into one for things such as searching? It's in the core an Teppo explains it well here: https://processwire.com/talk/topic/5513-fieldtype-cache-please-elaborate/
  12. Can I ask what you built the Volvo CRM with? Also feel free to submit yourself to the dev directory at http://directory.processwire.com
  13. I think that was the same conclusion that was drawn in a similar topic (can't remember where it is now). The suggestion was I think that since the API abstracts modules away from the core functions you're not actually using any of the core code, just accessing it via the API. Probably someone will find the link to the other topic now where I will have said something completely different
  14. But that performance increase might be nice for servers where you could request an upgrade
  15. There are some brilliant minds on Reddit. I've only ever read two things on there and this was the second. http://www.reddit.com/r/discworld/comments/2ysv26/sir_terry_has_gone_for_the_long_walk_across_the/cpcmru1 Amazing tribute.
  16. Pete

    Search and Replace

    This was the quickest way for me to search over an unknown number of fields in an unknown number of tables (the code took 1 minute after searching for the correct way to do it in mySQL for over 5 and time is at a premium (so why am replying ), so yes a replace in mySQL would almost certainly be better if someone knows the best query for that (preferably search the fields table for all fields of a certain type, then update all of the tables for those fields to replace the word). Yep - don't use this for big sites. mySQL is the way to go there but this works for smaller sites < a few hundred pages. As for modified date and user, I can see how that might be an issue in some workflows but I've never used either myself in selectors - very much worth you mentioning it though of course. If you simply wanted to maintain the order if your pages were sorted by modified date then simply sort the child pages by modified date first before replacing your search term though if you need to maintain the same modified date and user then the replace is best done directly in SQL to bypass those being updated.
  17. I just had to do a site-wide replacement on a word this morning, so this may be of use to others in a similar situation (in my case a product name had to have a capital letter in the middle instead of lowercase). Stick at the top of your homepage template and be careful with this - always take a database backup before playing with anything that's potentially destructive. function searchReplace($page) { foreach ($page->children('include=all') as $child) { // Skip admin page if ($child->id != 2) { foreach ($child->template->fields as $field) { $child->{$field} = str_replace('search_word', 'replacement_word', $child->{$field}); } foreach ($child->children as $grandchild) { searchReplace($grandchild); } $child->setOutputFormatting(false); $child->save(); } } } searchReplace($pages->get('/'); exit; It essentially iterates every page under the homepage, goes through every field and replaces the search term with the replacement. It is case sensitive too. Comment out the code when you are done and see the changes live on your site. This might be a nice one for a quick module that only targets things like text, textarea and image/file descriptions as that's pretty much the only fieldtypes that are relevant I think. Settings could be added to skip certain pages (and therefore their children) entirely, but I don't have time for building a module at the moment.
  18. It's possible to paginate the datatable with AJAX too, though it adds a minor delay of course when you click a page number.
  19. Done
  20. Pete

    Regexp Help!

    Awesome - thanks guys!
  21. Pete

    Regexp Help!

    Thanks Steve - much appreciated. Is there an easy way to see if the whole thing has accidentally surrounded in <p> tags and match that as well? This is all hilariously in a CKEditor field (what could possibly go wrong ) and it would look a little neater if the {showif} is on its own line. As for what this is all about - it produced something akin to an MS Word mail-merge, but with inline fields that then optionally show other sections of text that in turn might show their own fields. It's a horrendously long and complex form, but I've realised that the built-in "showif" javascript in the PW admin is very useful for this and just works once you look at the requirements for a div tag surrounding an optional piece of content. Unfortunately it's nothing I could share as useful to others as it's so tied into this one project, but it would be nice to build a module around this idea in future - it's a relatively nice interactive document builder where the idea was to remove any margin for error over the old version which was a straight Word doc with highlighted text you deleted or added to where applicable. In some ways, now I'm past page 10 of that document, I wish I'd suggested leaving it how it was
  22. Pete

    Regexp Help!

    I am not as hopeless as I thought. This: {showif::field=value} some text {/showif} Can be captured with this: preg_match_all("/\{showif:.*?)\}(.*?)\{\/showif\}/is", $input, $matches); My next trick will be matching if the {showif} tags are optionally surrounded by paragraph tags, but I have a workaround for that so no real need to fix that right now.
  23. Pete

    Regexp Help!

    Hi guys I hate regexp - they always give me a headache no matter how many times I try and learn them. What I want to do is capture the various parts of this: {showif field=value}some text over many lines potentially{/showif} So from that I need the values of field and value and preferably the operator in between them. I don't need a templating engine (before anyone suggests one ) as it is literally just the above I want to parse in some text fields in ProcessWire before a page loads in the admin.
  24. I think the best way to put a gallery in CKEDitor would be Hanna code to be honest - only sane way I can think of My Block editor implementation allowed multiple CKEditor fields too (in inline mode) so I'm going to stop referring to SirTrevor completely at this point as it's confusing. I'll try and revisit it this week as I think a lot of what I've been doing the last couple of days might help me get over the final hurdles with it and then I'll be confident about sharing a screenshot. Topic thoroughly derailed now though, sorry!
  25. @ last 3 posts - I agree but there are still times where, as long as you trust the person editing to do it properly, this is still okay (although not usually ideal, I agree). With regards to the craft screenshot and Apeisa's link to SirTrevor - this is the ideal way to handle this and I did actually start to play with an inputfield to accomplish this using SirTrevor but couldn't get it to work properly (I may go back and check it again now I've got more experience). The idea is simple enough - allow as many image fields and text editors as you like in a single fieldtype (I got that working) and simply have ONE textarea field that stores the order of the elements and the editor content as JSON. That way you just need one multi-image field to store the actual images, and the textarea field stores all the editor contents. A nice little render function would pull the content together to display on the frontend and you're sorted I think if I revisited it I wouldn't even bother with SirTrevor to be honest and I'd roll my own interface so as to keep the styling in line with the PW admin themes.
×
×
  • Create New...