Jump to content

adrian

PW-Moderators
  • Posts

    10,741
  • Joined

  • Last visited

  • Days Won

    345

Everything posted by adrian

  1. In case you guys haven't seen it, this might be relevant: https://processwire.com/talk/topic/4544-image-field-changes-file-name/
  2. Kongondo, Regarding blog_date field. I get the feeling it is designed to be the date/time that the blog post is published, but from what I can see it gets set when the post is first created and doesn't automatically change after that. I might be misunderstanding your use of the field, but I would like to see it change automatically when the post is published and not change after that - maybe even disable user editing of it? I know we often draft up several posts at a time and publish them later. I don't think we should have to manually adjust this field when publishing the post. Another thought for you - have you considered integrating this module: http://modules.processwire.com/modules/schedule-pages/ or the functionality from it into the blog posts tab? This would make WP users feel at home. Thanks for considering.
  3. Great first post ukyo - welcome to PW and thanks for the contribution!
  4. You can get the latest dev from here: https://github.com/ryancramerdesign/ProcessWire/archive/dev.zip This version will become 2.5 fairly soon.
  5. I manage my own servers and I have certainly enjoyed the learning and freedom that goes along with that. It is great to be able to compile the latest version of something yourself on the day it is released and to be able to mix and match various versions of software as needed. It can definitely have its frustrations though when dependancies are not playing nicely. Things are generally simpler if you use pre-compile packages and a package manager like aptitude or yum. I think @cstevensjr's comments about security might be your biggest issue - there is a lot to learn on that front and it can bite hard if it's not done right. Of course I bet you could probably do better than a lot of the managed options out there on your first time anyway. When I do deal with hosted sites, I haven't had great experiences, usually because the client has been with a host for a long time and doesn't want to change. There are some horrible operators out there I need to start making sure I get to choose the provider in future!
  6. I posted about this on kongondo's blog module thread, but wanted to note it here too I just tested Nico's new version, tweaked the field and template names to match those used by K's Blog module, imported my WP blog xml and it worked brilliantly. Great work Nico!
  7. kongondo - really fantastic - you have put a huge amount of thought and work into this. I just tested an import from WP using the latest version of Nico's MigratorWordpress. I just edited the config settings in his module to match your template and field names and bingo, a perfect import!
  8. Yeah, I am sure you are distraught Now we just need someone with some Drupal skills to write a MigratorDrupal plugin. Anyone?
  9. Just an update for those following intently Turns out there was a character encoding issue in totoff's WP xml export. WP was url encoding special characters which is why he was getting the selector error. Remove that and it all works because that selector error was responsible for the categories/tags assignment problem and the post date stuff as well.
  10. I am sure it is achievable, but most people here would argue it's not worth the effort. Most dedicated forum software out there has been developed over several years by teams of people. It is a lot of work to replicate all the functionality. But, if you want something simple in PW, if you haven't seen it, here is a very basic but functional forum module from apeisa: http://modules.processwire.com/modules/discussions/ It might provide a good starting point for you.
  11. You're not making me happy I'll PM you the XML I have been testing with. I don't suppose you'd be able to send me your one as well? What version of Wordpress are you running - this could be relevant? I don't think it should matter, but also what version of PW are you running - I have been testing the latest dev.
  12. I agree diogo! Just a small issue for anyone who goes to test the WP import. If you are using TinyMCE on the body field, images won't display in the editor. There is a tiny bug in MigratorWordpress that breaks the valid_elements setting. If you want to test before Nico fixes this, after the import, just replace the valid_elements for the body field with the default settings: @[id|class],a[href|target|name],strong/b,em/i,br,img[src|id|class|width|height|alt],ul,ol,li,p[class],h2,h3,h4,blockquote,-p,-table[border=0|cellspacing|cellpadding|width|frame|rules|height|align|summary|bgcolor|background|bordercolor],-tr[rowspan|width|height|align|valign|bgcolor|background|bordercolor],tbody,thead,tfoot,#td[colspan|rowspan|width|height|align|valign|bgcolor|background|bordercolor|scope],#th[colspan|rowspan|width|height|align|valign|scope],code,pre
  13. Ok, I think we are sorted I made some changes to the module so get the latest version - there were some session variable issues regarding the Import Type not being used as selected. This is exactly what I did and I got Ryan's blog profile installed and a test install of 40 WP blog posts, with tags and categories assigned and users and dates imported. Started with a clean PW install. Import the blog.zip with the following settings Parent Page: Home Components to Import: Everything Import Type: Append Import User Details: Checked Import Created/Modified Dates: Checked Data Source: blog.zip Import wordpress xml file with the following settings Parent Page: Blog (this parent page was created by the blog.zip import) Components to Import: Everything Import Type: Replace Import User Details: Checked Import Created/Modified Dates: Checked Data Source: wordpress.xml Now that kongondo has released his Blog module (https://processwire.com/talk/topic/6465-module-blog/) I think it would be awesome if Nico's MigratorWorpress was made compatible with the page, template, and field names that kongondo is using, because this will be a much better approach than using the blog.zip import I put together. Perhaps a way to configure the names of these in the module config settings! Anyway totoff, please let me know if it works for you now. I have run this a few times now and it seems perfect!
  14. To be honest, I haven't had the need to use track changes yet either, although it sounds like it would come in handy if you are looking to report field level changes.
  15. How's this to get things rolling? foreach($pages->find("id!=2, id!=7, has_parent!=2, has_parent!=7, template!=admin, sort=-modified") as $p){ echo "<p>{$p->modifiedUser->name} updated {$p->title} " . wireRelativeTimeStr($p->modified)."</p>"; }
  16. Thank you for the thorough testing and detailed reporting - really appreciate it. I had never tried the combo of importing that blog.zip I posted and then importing some WP posts, so I just gave it a go and found it worked flawlessly, except for assigning tags and categories to the posts - there must be a conflict with those fields already being created from the import of Ryan's blog.zip This sounds mostly like your first attempt, except that for me, I didn't get the selector operator warning and the post dates were imported correctly. Can I ask what you mean by: "Page tree as before"? I am going to see what I can do about the tag/category assignment to posts problem when using Ryan's blog profile and on subsequent install attempts. Once I get that sorted, it would be great if you can test again and make sure debug mode is on to see if we can get some more info on that selector error. I am not sure why the post dates aren't importing for you, but I'll take a look at that too. Stay tuned
  17. Try this: $discuss_logo = $item->discuss_image->size(200,200, $image_options);
  18. Just to clarify, it is the google map itself that is not working - the issue is not specific to this PW fieldtype. Take a read of the comment by patrickjdempsey in this thread: http://forums.mozillazine.org/viewtopic.php?f=38&t=2440619
  19. Sounds like a cool concept - I'll have to take a look
  20. Check out the Migrator module: https://github.com/adrianbj/ProcessMigrator At the moment I still strongly recommend testing the migration to a test PW installation before running the import to your production install, but it has all sorts of options for migrating content from dev to live, including a new feature during export which allows you to export only those pages that have changed since a specified date/time.
  21. Minor, but important fix just committed to prevent domdocument from adding docytype, html, and body tags to RTE fields.
  22. I have actually always just used what Soma suggested here: https://processwire.com/talk/topic/3992-how-to-check-if-a-module-is-installed/?p=39141 $modules->get("Your Module"); and it always seems to work, but then I don't really understand the need for the getInstall() method.
  23. A little self help tip Right click on the button and choose Inspect Element and then see what css is applied to the button. As for grouping inputfields, check out Field type FieldsetOpen: https://processwire.com/talk/topic/176-fieldsetopen-fieldsettabopen-%E2%80%93-what-is-it/
  24. Hi Ralf, The only thing I would say is make sure you trust your site content authors/editors before giving them TextColor control. Things can get very ugly very quickly
  25. Looks really nice! I know your name is videokid but one of my pet peeves on websites is auto playing videos and audio. Turning that off would be my only suggestion!
×
×
  • Create New...