Jump to content

adrian

PW-Moderators
  • Posts

    10,741
  • Joined

  • Last visited

  • Days Won

    345

Posts posted by adrian

  1. I have attached a revised version of the module. I know Pete is pretty busy with other things at the moment, so I thought I'd try to help out.

    I haven't tested this thoroughly, but I think it should take care of things. It also includes a few other fixes, like adding delete buttons for each category and also fixing a bunch of PHP warnings.

    If you could test and let me know if everything is working fine and then I'll submit a pull request for Pete.

    My forked version

    • Like 2
  2. Nice catch horst :)

    Can I go one simpler:

    $pids = array(1010, 1011, 1022);
    if(in_array($page->id, $pids)) {
        echo $pages->get("1114")->body";
    }
    

    or even just:

    if(in_array($page->id, array(1010, 1011, 1022))) echo $pages->get("1114")->body";
    • Like 4
  3. Hey kongondo - no worries. Maybe it will be ready for the modules directory sometime soon. I just need to find the time to get back to it - maybe this post will get me motivated to find the time - I do think it has lots of potential and most of the hard work is already done :)

    • Like 1
  4. Check out this module:

    http://processwire.com/talk/topic/4420-page-list-migrator/

    It is still in development, but it allows you to export a hierarchy of pages, templates and fields from one PW installation to another and import them into another PW installation. It currently doesn't copy the actually template.php files, but that is the easy part really :)

    A blog setup is definitely one of the uses I am thinking of for this module, but at the moment you will find on the import page of the module the ability to import/create the pages/templates/fields for lists of countries and a few state lists.

    I really do want to get back to finalizing this module, but it is in a usable state already although I would definitely recommend running it on a test installation of PW and not one with data that you care about first. If it works for your needs then use it wherever.

    • Like 2
  5. No problem, another alternative would be:

    $pids = array(1010, 1011, 1022);
    $downloads = $pages->get("1114");   
    if (in_array($page->id, $pids)){
        echo "$downloads->body";
    } 
    

    This would be cleaner if your list of pages started getting longer.

    • Like 4
  6. The key is find vs get:

    $downloads = $pages->find("id=1|1114|1452");
    
    foreach($download as $p){
        echo $p->body;
    }
    

    EDIT: Actually I am not quite sure what you are trying to achieve. I left out the check for whether the current page is id=1011, but you can easily add that back into my code.

    Am I on the right track with grabbing the content of pages using multiple IDs in the find, or am I off track completely with what you want?

    • Like 1
  7. Wow, speedy service! It shouldn't be that complicated to get imagemagick compiled with rsvg. I have certainly had my issues with dependency conflicts over the years, but two weeks is a lot of debugging time :)

    Anyway, great to hear you have it working now and the conversion results are good. I am really excited to have someone else using this. I wish there was an easier way to make these conversions, but unfortunately there is nothing simple. There are options that use batik (needs java) and some php classes that make use of running inkscape via the command line (relies on exec which is often disabled), so the imagemiagick / rsvg combo seems to be the best option and gives great results.

    That latest version should have fixed a few dimension calculation issues from the previous version, but please let me know if you come across any issues or have any ideas for improved functionality.

  8. Yes, I am using the Zurb Foundation 5 profile which has 1.10.x version of jQuery. Maybe the module could be fixed to use .on?

    It isn't always as simple, but in the case of this module with the way that statement is structured, you can simply replace "live" with "on". 

    If you want you can file an issue over at: https://github.com/NicoKnoll/ProcessPageDelete/issues/new and ask Nico to make the change. I don't think there is any need to worry about detecting the availability of "on" anymore with a "live" fallback, because PW is using jQuery 1.8 which supports "on".

    • Like 1
  9. Hi everyone,

    Another overhaul today. A few bug fixes and a bunch of new features. I have updated the first post here to detail them better, but key things are the ability to make use of the following variables in the filename format: $page, $template, $field, and $file.

    To accommodate some of possibilities this opens up, eg: $file->description, there is new logic to handle renaming after page save if the filename format can't be properly evaluated at upload because the field isn't available yet, or is still blank. If possible, renaming will still occur during upload - "on save" is just a fallback if needed.

    Another key addition is the ability to give each rule the option to rename the file again each time the page is saved. There are obvious issues with this if images or files are being linked directly by their URL, so care is needed with this option checked. It does allow for some incredible flexibility though. You could even have a field in your template called "Filename" allowing the user to rename the file whenever they want. In most scenarios of course this would not be at all desirable, but it suited my needs, so thought it might come in handy for someone else as well :) If nothing else, it might be useful during development, but could be disabled once the site is live.

    Let me know if you find any bugs with this new functionality.

    • Like 3
  10. Sounds like you have something weird going on with your config file regarding the duplication of DB details, but I think your 500 error might be coming from the modrewrite base setting in the .htaccess file.

    Some relevant posts that might help you narrow down exactly what needs changing to what:

    http://processwire.com/talk/topic/4434-pw-not-installing-correctly-admin-not-found/

    http://processwire.com/talk/topic/4917-the-admin-cannot-be-reached-in-new-installation/

  11. Really great diogo - fantastic looking site :)

    Also, love the meanmenu - I think that is the first mobile friendly menu I've seen with the plus for expanding submenus, thereby avoiding the need for duplicating the parent item - might be my new favourite!

    • Like 1
  12. Hi verdeandrea and welcome to PW.

    PW 2.4 introduces a new system for managing admin themes. If you are using 2.4 and you're new to PW I would recommend staying with the default theme for the moment until existing themes are updated to handle some of the new functionality. However if you are still keen to change, I think all you should need to do for the moment is uninstall "Default Admin Theme" from the Core tab of the module settings page. Then your manually installed theme should work. Alternatively, you could follow Ryan's instructions for converting your old theme of choice into a new installable theme:
    http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=53671

    Let us know if you need any further help.

    • Like 2
  13. Nice one Reno. I just tested and it works!

    My quick mash - I am sure it could be improved.

    $template = $templates->get("your-details");
    foreach ($template->fields as $field) {
        $fieldlabel = $template->fieldgroup->getField($field, true)->label;
        echo "<label for='$field->name'>".$fieldlabel."</label>";
        $inputfield = $field->getInputfield($page);
        echo $inputfield->render();
    }
    
     
    • Like 6
  14. Not sure what you mean. I just put all my scripts inside  /site/templates/scripts/

    Sorry, I probably wasn't very clear on that - I am talking about php scripts that need to be called from the browser, but that are not PW template files. For example this could be an AJAX call to a php file.

    That make sense now?

    To clarify, any javascript files can definitely be run from inside templates/scripts.

    Sorry for the confusion.

  15. Mike,

    The great thing about PW is that you can structure and name files however you want and put them in whatever subfolders you want. The only real restriction is that your main template files (the ones that relate to the templates you set up in the PW admin) must be in the site/templates directory. The only other restriction is that if you want to call any scripts directly, they need to be above the sitefolder. Other than that, you can do whatever you want. Feel free to add as many include folders and name files however best suits your workflow.

    I haven't used Drupal so I may not be the best person to comment, and maybe you can do this is Drupal too.

    Bottom line: I'd love to see PW move over to at least PSR-0 compatibility and available via composer.

    It's on the roadmap:

    http://processwire.com/about/roadmap/

    • Like 3
×
×
  • Create New...