Jump to content

porl

Members
  • Content Count

    105
  • Joined

  • Last visited

  • Days Won

    1

porl last won the day on June 17 2012

porl had the most liked content!

Community Reputation

52 Excellent

About porl

Profile Information

  • Gender
    Male

Recent Profile Visitors

2,733 profile views
  1. Hi again. Further to my last question, how do I use the class in the front end? I tried to copy the snippet with $matrix = new Matrix(); but it couldn't find the class. I tried to add the Matrix.php as a require_once line but now I get an error stating WireData cannot be found, so I assumed I need to instantiate the module some other way. I then tried to use the $modules->get method to load the module and changed new Matrix() to new \Matrix(). This seemed to load the Matrix class now, but it now complains with the following error: Class 'MatrixArray' doesn't yet implement method 'makeBlankItem()' and it needs to. I don't get this error when using the module in the back-end so I assume there is something else obvious I am missing.
  2. Hi there. I'm trying to work out if this module will suit a site I am working on, but I'm not sure how to add items via API. I saw your code snippet, but is there a way to modify individual elements rather than adding to them? What I mean is something like $row = 1024; $column = 2048; $value = "hello, matrix!"; $matrix = $page->matrix_field; $matrix->set($row, $column, $value); or similar? The dynamic nature of the row/column generation is perfect for my use case, but I will be needing to modify "cells" from the front end and not sure if this is how this module is designed to work or if I am just missing something obvious. Thanks!
  3. Looks like it might have been specific to the Twig module then. Yes, auto rendering is nice and handy but sometimes gets in the way. I made my Judo/BJJ club's site as a single-page website but wanted to keep all the partials separate and combine them dynamically. It was trivial to pull pieces from wherever I wanted with auto rendering off but when I hit that bug (and was on a tight timeline so couldn't dig into it more) I had to restructure to allow the auto rendering to be on. Not as clean but still worked okay. I'd imagine in more complex setups it would be harder to work around if it wasn't an option!
  4. Nice! I was tempted to try the same just to see what was involved. Definitely curious to check it out! On a side note, can you see if it works with the "auto render" option in TemplateEngineFactory off and with '%' characters in the markup (outside of the latte tags)? I found this bug with the Twig render engine but not sure if it is specific to the Twig module or the Factory part itself.
  5. Hi all I am currently working on a custom orders site for a client. One thing that I'm racking my brain over is how to structure some fields that seemingly require relationship with other pages. Not sure how to describe that properly so here is the basic idea: Templates Product types (self explanatory) Customer (also self explanatory, likely custom user pages but could be separate if necessary) So far so good. Now, each product type needs an image field. The tricky part is that each product's image field needs to have the ability to have a different image for each customer (the orders are for unique customised items and the site will display images of how they will appear). My current thought is to make the product_image a repeater that holds two fields for each item: an image field and a page_ref filtered to the customers. It could also be reversed - customers have the image repeater containing the image field and a page_ref to the product types. Is there a cleaner way to do this? Ideally I would like to have a field that is a table of some sort that automatically shows all the customers and you can assign an image to each. I thought of making a custom field like this but then felt out of my depth - what to do when a customer is deleted for example? Is there some field module that has some ability to load a reference to other pages or something like that? Or some way I can easily "hook" the repeater field/table field etc. to do a "foreach" of current customers (that wouldn't fall apart if the customer list changed)? Of course I can do it with my current thought, however I felt this is not intuitive for an end user (they would need to go through any page list to make sure they got every one for instance) and since so many people here have clever ideas I thought I'd see if there was any other approach.
  6. Where did you get the Less compiler part from? I noticed some warnings from php regarding the use of "continue" rather than "break" in some switch statements (functionally identical but continue generates a warning). I saw they were from the less.php/Less.php file and was about to patch them, however I was curious as to whether this was imported from an external library or you rolled your own. If external then I would imagine it more useful to fix it upstream first. I did a brief search for "less.php" but didn't find anything that seemed to match your project file's structure.
  7. I would suggest using the blog site profile as suggested above, even if just to learn your way around. Once you get a feel for it you will see it is relatively straightforward to set up the ability for a user to make a specific type of page (post/portfolio item etc.). Starting with the blank profile makes sense if you already understand this process and want to build something very different. The site profiles are pretty flexible and serve as good starting points for everything else (including what I feel you want).
  8. Well then... I guess I can delete my module haha Nice one, I'd heard of AOS but didn't think to check it for this feature. As I said, I was just playing with it for my own sake and thought that since it was a small change it might be able to be included. Didn't think to use hooks (and to be honest I'm not sure I would have known which ones to use and how to do it in this case). Thanks for the input, happy to learn!
  9. Hi all. I've made a small tweak to the ProcessPageList core module. I like the page actions hover feature but find it a bit fiddly hovering over the page labels. I made a change to (optionally, toggleable in settings) show the actions when hovering over the entire page row. I mostly did this for myself but is there any interest in people using this? I'm not sure it is worth releasing as a full module, as it then would require tracking updates etc. and is just a small change in a couple of files. If there is interest though I guess I could request a pull request (if @ryan doesn't want to just use the diff file below). ProcessPageList.diff
  10. Success! Found this nice little snippet that basically just requires the url. This is similar to how I tried to do it but doesn't require a specific page at the url (some admin urls aren't actual pages which is likely why I got the NullPage issue doing it my way): if(strpos($_SERVER['REQUEST_URI'], $this->wire('config')->urls->admin) === 0) { ... } Now it works even better - no need to rename admin.php to admin.latte (which was a little annoying as it wasn't a latte file!). I also made a second commit to remove the ignored templates field as you suggested.
  11. Hi @tpr Thanks for checking it! I appreciate you are very busy. Playing with things a bit more today I now understand why you need the !=admin check. When I switched on the .latte template extension option in my test site I didn't realise I was still using a non-empty "views directory" field, which meant that any templates (including admin ones) that didn't have a .latte file in there were disabling the module for that rendering. This meant that I didn't see any issues with the admin side of things at all. When I emptied the field (which is how I assume your site must be) I got similar issues to what you were describing. Unfortunately I had the same lack of luck as you in trying to get the autoload to not occur for admin files. I had deleted the admin template check because I thought it would be nice (though unlikely) to allow someone to replace the admin theme with a .latte one should they so choose, but after mucking around a while I can't see a clean way to allow this and since that is such an unlikely use case I figured I'd add it back in as you had to. I even thought it might be a good use of the "ignored templates" field but putting admin in there doesn't help as I can't seem to find a way to get the page's template information before the .latte extension override function in the code. Is there a way to get the page or template information that early? Even doing something like wire('pages')->get(wire('input')->url())->template doesn't work because for some reason admin pages return a NullPage. Other pages return the correct template so I assume there is something different about how admin pages are rendered. One more thing, I couldn't quite get your changed fuel loading line working - can you show me where you put it? I tried to replace the relevant foreach loop in the ready() function but I got errors about missing page variables etc. and my understanding of that line is that it would result in something like $view->fuel->page etc. Is this correct?
  12. Just made the change to after Page:render. I also removed a few redundant checks: template filename being '' doesn't seem possible (tested it with a die(); statement to be sure, but the whole Page:render does not seem to be called if this occurs) template name === admin: since we now no longer render any template that does not have a latte view file this seems unneeded. Hmm.... I did just have the thought though that using the .latte template extension option might conflict with the above logic. I don't use this option and didn't think to check. I'm a bit tired now though so I'll have to play again tomorrow if someone else doesn't test it first (again from my github fork).
  13. I suppose that shouldn't be too difficult. Is it really necessary? Currently just leaving the field blank disables it, but if you think a checkbox would be clearer then I could try to add that. Not sure if it would clog up the interface though. The TemplateEngineFactory modules allow for this, although I did come across a bug that meant that the templates could not have a '%' symbol in them (outside of the Twig tags). Not sure if that is related to the Twig module or the Factory module though. I wonder how much work it would take to re-use the Twig module and make a TemplateEngineLatte one. And whether or not it would be worth doing - there are some things I like about those modules and other things I prefer in tpr's way of doing it. My original Twig module was pretty unintelligent and not much different to how one would use it manually. Haven't tried that, I have made dummy pages with templates that I render from other pages though. I guess it would be nice to be able to do it more cleanly than that. I wonder if that is the reason I was having trouble using the technique from point 3 I mentioned - I had to explicitly pass $page variables etc. so as to not have the other page's template render fields from the current one. I wonder if it requires a big change, worth looking into. I noticed this one. Can't remember if other modules like the Twig one can generate errors from the template process step rather than the final php output run. Might be a bit beyond my level to work out how to pass those on though (if they even occur - Twig seems to do a lot more processing of its variables before deciding to allow the output to be generated, Latte from my understanding is a bit more directly transpiled).
  14. Nice work! I made a Twig module way back as I was doing similar things to what you do here. Since then others have made (far cleaner) Twig modules too and I recommend these for most people. Getting your hands dirty and seeing how relatively straight-forward it is to use Twig or similar engines from scratch with ProcessWire is extremely valuable though - even if you go back to using the modules in the end. It gives a much clearer picture of what is going on (and therefore what could go wrong too). I've started playing with the Latte templating engine recently and love it (though I hate Php's $ style variables and -> style object notations which Latte uses), but Twig will always hold a special place as it was the first templating engine that actually felt good to use and not a chore! Thanks for the great tutorial!
×
×
  • Create New...