Jump to content

cst989

Members
  • Posts

    115
  • Joined

  • Last visited

Everything posted by cst989

  1. The video on this page is not loading - didn't fill my boss with confidence when I said "yeah, Processwire could be a great solution for a multilingual site, let me show you their docs!" https://processwire.com/docs/multi-language-support/multi-language-fields/
  2. Hello, this is a great module! Is it possible to make subfields of Profields: Combo selectable for indexing?
  3. For some reason this map marker field has stopped working on my production server. It just saves 0.00000 as both lat and lng values, even though it correctly finds and shows the lat/lng on the field itself.
  4. The only time I've had different output in different browsers that wasn't a CSS etc issue, was with https or cross-browser cookie policies, where one browser was more strict with what it blocked than the other. I know I'm just brainstorming and it doesn't match the code you've provided, but food for thought maybe for you or another who lands here from google...
  5. That looks... remarkably like what I mean! Probably more feature-rich than I even need but definitely solving the same issue. The latest idea I was going to do was to use the ProFields: Table I mentioned above, and then use hooks to cache and store only the columns I need on a per-page basis. But I might keep an eye out to see what your solution is first! 💡
  6. Hi guys, this is one that's stumped me for a while and I've tried various methods none of which I've been particularly happy with. Basically I want a table field where the CMS user can add or remove columns as they need them. The usage for this is a catalogue website where products have a long list of model variations. For each product category or even individual products, the headers and number of columns could be completely different. A HTML table in a WYSIWYG would probably suffice - at least the kind of functionality you get with that is the kind of thing I'm after. Except that I want it to be both importable from a CSV, and the resultant data to be a bit more accessible afterwards. One option I've used in the past was to use Repeater Matrix, where the first entry controls headers and subsequent entries control all rows (and have to have the same number of sub-fields to match the header row). This worked from an import/usage perspective, but is hardly clean management in the CMS. Other times I've resorted to the fact that the CMS user can never manage the table with the CMS, and simply has to re-import. This way I can simply store the data however I like (custom table, json etc). I considered using ProFields: Table and simply putting all the possible columns in one field, then the user simply scans over fields that don't apply to the product. My concern with this is that the table could be huge and slow down the site - is that a valid concern?
  7. Just bumping this thread from a couple of years ago because it's the top result for "fieldset page as a tab" 😛 I wanted to say that I think it would be a really good idea if this was baked into the Fieldset Page by default. In fact, I think a tick box to make basically any field live in a tab of its own could be a pretty good idea. At this point a single field can contain so many subfields. There's Repeater Matrix, FieldsetPage, Profields: Combo, tables, textareas, and more. Many of these field types do a great job of reducing the amount of fields you need overall, but also lead to a very cluttered page edit screen. Fieldset Tabs were excellent in the past when we didn't have so many clever fields-within-fields, but now it feels like there could be a better way?
  8. Thank you, that worked! I wanted to loop through the results to template them manually and for some reason I had to change the following, which did nothing: echo $limitedResults->renderPager(); to $pager = $modules->get("MarkupPagerNav"); echo $pager->render($limitedResults); but otherwise, got there in the end.
  9. Ah yes, that's something I thought of and an elegant solution. But yeah a single selector I think is something I need, as unfortunately there's one additional thing I should've mentioned in the original post, I need to render pagination! And I don't think that will play nicely with combining queries and slices.
  10. I'm surprised @MarkE hasn't weighed in to talk more about their module linked in the OP - I think it's a really great concept that seems to tick a lot of the boxes being discussed. I just wish I had more time to try something like that out.
  11. I would like to sort search results so that those with a specific root parent ID (could be the immediate parent, could be one higher) are prioritised, essentially pinned to the top of the results. How can I do this please? My existing query is very straightforward (using SearchEngine module for index): $pages->find('search_index%=' . $query . ', limit=15'); Essentially what I want is something like this: $pages->find('search_index%=' . $query . ', sort=[has_parent=1234], limit=15'); Thanks.
  12. I didn't get as far as checking if a table field would save the rows when they were new, because unfortunately table doesn't offer as many options that I needed, like a default option on selector, or the ability to show/hide fields I ended up sticking with the repeater matrix but forcing the repeater to publish on save. I tried the following, it worked at first but then it started creating database errors.... $this->addHookAfter("Pages::saveReady", function (HookEvent $event) { $page = $event->arguments("page"); if(!($page->hasField("featured_articles"))) return; foreach($page->featured_articles as $item) { $item->of(false); $item->status("published"); $item->save(); } }); now I think I'm just going to create 5 separate fields of "fieldset (page)" type 😕
  13. Wow its funny you added this... I created something just a few months ago using CSS to achieve this... wish I'd waited! Mine...
  14. Unfortunately the module doesn't seem to work at all for me. Also none of the theme options seem to change anything. Perhaps it's using it inside a RepeaterMatrix field that's the problem? This is PW 3.0.184. Also the above post about performance is a bit disconcerting but I've not gotten far enough to test that It's a shame because it looks perfect for what I needed otherwise. Including ionicons was a great choice.
  15. That looks great! If "show all rows" is selected, and you open and save a fresh page with that field, does it actually save rows for you to iterate through? Per my issue at the end of my first post -- it caused me some issues with repeater
  16. You know what, I have a long expired subscription for ProFields and I have been weighing up whether or not I need to renew 😄 I will take a look, thanks
  17. Hi, I'm using a repeater in the following manner: I have set the minimum items to 5, and the maximum number of items to 5. I basically just want to loop through a few fields five times. But I feel like I'm really forcing the repeater to do something it's not really meant for by doing this. A table would look and feel better, but as far as I know can't be fixed to x rows/pre-populated. Also there's a technical problem with this. Repeater rows do not seem to save unless you change something. So if I make a new page with the fields above and hit save, no data is actually available for the field. In my screenshot you can see that items #1 and #5 have saved because the type has been changed to 2 - they're solid and don't say "New" anymore. Also item #4 has saved because the type was changed and changed back. But #2 and #3 won't ever save unless you change the value. If there's not a better suggestion for the approach in general - I would appreciate any technical support in forcing each row to save!
  18. Sorry I should've been clearer, what I was seeing was that the description was still visible, but the padding broke and spacing at the bottom of the fieldset was out of alignment. The way I'm trying to use minimal fieldset is like this: For me, a description would still be kinda handy to have - but I appreciate it would need new CSS logic and that's more complicated than it seems. And I understand if this isn't exactly the aim of the module. 0.1.7 certainly fixes the visual hiccup pictured, so thanks for that 🙂
  19. Just fyi this breaks a bit if you put a description for the fieldset and also tick the box. Maybe just in the latest version of PW
  20. I know this was asked before but I still don't fully understand, why does this module open a popup with a tab where you can select the target, if it doesn't do anything? I handed over a CMS using this field to a third party and they tried to use target="_blank" from the attributes tab of this field all over the site and were surprised when it did nothing. Wouldn't it be better if this module stored an object with these bits in, returning the link by default? Either that or at least drop the attributes tab from the popup if it doesn't do anything.
  21. I hit a back-end error with a default value on this module Basically I set the default opengraph image to an image within a pagereference field, like so: {banner.image} This works fine if it exists, but if it doesn't, it hits a fatal error
  22. Hi Erik, I would try the decimal fieldtype linked to in Robin's post - and also you don't want to be changing it directly in the db, just changing the field type
  23. What would you consider a good, clean way to append a list of pages retrieved randomly, with more random pages (excluding those you've got already)? Eg you start with $pages->find("template=gallery-detail, sort=random, limit=100"); You output this to your template, then you have a "load more" button. This works through ajax. Now within the ajax, you need to select another 100, but exclude those you retrieved the first time. So I'm thinking you need to post all the pages you've got already, or maybe store in a session? And then exclude them from your next find(). But I imagine that would be a bit slow, excluding 100 pages by ID? Is there a more efficient way?
  24. Var dump returns a string but still nothing in the field... It's occurring to me now, maybe I'm misunderstanding this whole thing? Is this actually meant to be populating the html field itself? Will this still work if I'm using embed method C or D on Formbuilder? I'm trying to avoid populating this with javascript but that would be so much easier... perhaps I'll just abandon it.
  25. Hi all, I have a simple issue with inputfield:attr() not setting a value. I'm doing this in ready.php $forms->addHook('FormBuilderProcessor::renderReady', function($e) { $form = $e->arguments(0); if($form->name != 'enquiry_form') return; $inputfield = $form->getChildByName('cart'); if($inputfield) { $cart = json_encode(wire('session')->get('cart')); $inputfield->attr('value', $cart); } }); This is lifted straight from formbuilder hooks and inputfield method specs. If I echo $cart it's definitely a simple string of json, but nothing appears in the cart field (which is a plain text field - later to change to hidden) Is there something obvious I might've overlooked here? As a side question, can anyone think of a better way to do this - add my cart to a Formbuilder submission (it's not a shop, just an enquiry) - while still storing entries easily in the formbuilder entries list.
×
×
  • Create New...