Recently Updated Topics

Showing topics posted in for the last 7 days.

This stream auto-updates     

  1. Yesterday
  2. kongondo

    Update: Menu Builder Version 0.2.5. Just a quick maintenance update. Changelog Fixed a minor bug where we had to check if a variable was an array first before "counting" it. Removed a leftover debugging statement from the code (an echo of all things! Not even a bd()!!) .
  3. Hi, I am writing a custom module that requires storing array of settings in the module config/settings. Is there a built-in fieldtype that allows me to store settings in an array (sort of like Repeater)? I tried using InputfieldAceExtended and InputfieldTextarea to store JSON array. Both times, my data was stored in the module settings (in the database) but upon reload, that information was not retrieved. Thanks Rudy
  4. @Gadgetto I have a module but didn't add it to module directory https://github.com/trk/FieldtypeToggle Module using : https://github.com/victornpb/vt-toggle Module only works with checkbox, will add support for radio, checkbox group and radio group. You can try it or you can continue with your solution.
  5. Just a idea: build a textformatter module, attach it to all desired fields, plaintext and ckeditor fields. In the textformatter method, check what type the calling field is of, (HTML or plaintext). If plaintext, use the php function strip_tags() on your replacement content, otherwise leave as is.
  6. rick

    Fixed it for you
  7. szabesz

    I can tell you how to transfer me the $9995 you could not get rid of, just PM me
  8. kongondo

    We're still working on it :-). I'll write a progress report (post) next week.
  9. @dragan spoke with Alex @ PushAlert and the short answer is it has to be in the root. Long answer is that there is alternate, unpublished code that allows integration in sub-directories. Alex will send me the code to review. Will keep you posted Update Using PushAlert from PW site installed in a subdirectory is not difficult. It will require an additional field on the module config page and is on the roadmap for the next release.
  10. Last week
  11. @Ivan Gretsky, this issue should be fixed in v0.1.4.
  12. To have configuration fields for your fieldtype (displayed on the config tab) you'll need to implement ___getConfigInputfields(Field $field) in your Fieldtype class. To specify allowed overwrites you'll need to implement ___getConfigAllowContext($field) in your Inputfield class. As examples you may look at wire/modules/Fieldtype/FieldtypeTextarea.module and wire/modules/Inputfield/InputfieldTextarea.module. Edit: Please note that FieldtypeTextarea.module actually pulls additional configuration field from the InputfieldTextarea, so this is not a simple example for creating the config inputfields. A more straight forward example for ___getConfigInputfields would be wire/modules/Fieldtype/FieldtypeText.module.
  13. Yes, I just read that! I'll dig into solving that
  14. Ivan Gretsky

    I think this one of the most massive discussion about the project architecture I have ever read, featuring so many respected forum members, should not be left unanswered by the project lead. So feel like we need to bring it back up and ask @ryan to participate.
  15. @NorbertH - thanks for the screenshot - nothing out of the ordinary there. There is no need to deactivate the RequestInfo panel, just uncheck the "Field List & Values" option from its settings: That will reduce the size and time of that panel considerably. The API Explorer and Captain Hook panels are naturally going to be large in size, but the time should be significantly lower the next time you load it because the content gets cached - for me it's 79ms. Hope that helps a little.
  16. Thanks @OLSA for this reply. This put me back on some tests I had done previously but didn't work, but I've managed thanks to you ! In fact, I had tested the hook you mentionned (for the 1st time, by reading about it in the 'Custom PHP cide' section in the template page) but I had put it in a _init.php file I include in all my templates, but I guess this was the wrong place for back-end templates. From what you've indicated, I put my code in admin.php and it works as expected So a big thanks to you ! For information in case someone reads this, here's my code : $wire->addHookAfter('InputfieldPage::getSelectablePages', function(HookEvent $e) { $user = wire('user'); $pages = wire('pages'); if($e->object->name == 'group') { if ($user->isSuperuser()) { $selector = "template=group, sort=title"; } else { $selector = "template=group, created_users_id=$user->id, sort=title"; } $e->return = $e->pages->find($selector); } }); Of course, I had to remove my selector string in the template page because it triggered an error otherwise by indicating that the saved page didn't match.
  17. arjen

    this would be really nice. I also used to put stuff in the homepage, but this can get cluttered really easy.
  18. Or use the option manager with a fixed string, something like this: $field->save(); // save field first $manager = new \ProcessWire\SelectableOptionManager(); $manager->setOptionsString($field, __("Yes\nNo"), true); $field->save();
  19. Robin S

    @bernhard, thanks for the pull request. I've merged parts of that along with a few more of my own changes. But probably not necessary to do much more with this particular repo though because it really only exists to serve as a quick demo for people like yourself who might like to take the idea further. I'm not feeling possessive of this idea/code at all so anyone is very welcome to take it and use it for their own purposes in any way they like - further developments don't need to happen via my repo. To go further into something that would be more widely useful to the community, shared in the modules directory, etc, would require a new module that doesn't bundle any particular Process module like my demo does. I'm imagining something that would work with any custom Process module. And maybe focuses on the iframe approach because that seems the most promising (I was also playing around last night with the same JS library you mentioned). I might tinker around with something later but anyone is welcome to have at it and beat me to it. To respond to some of your points... Great, we don't want that exposed. I wish there was a better way than string replacement on the whole HTML output but there isn't any way I can see to set that part of the JS config object directly and I fear setting $config->urls->admin before the page render could have other unwanted consequences. The redirect isn't really about the ?modal=1 (although that is unwanted) - it's the Post/Redirect/Get pattern. If you look at the core Process modules you'll see that they all redirect after form POST submissions. In any case the specific code within the demo Process module is not something that anyone needs to use, it's just so the demo module renders something visible. What a person puts in their execute methods will depend on what they want their module to do. Incidentally, setting $this->wire('input')->get->modal = 0 unfortunately doesn't solve the problem for redirects as these still have the modal parameter forced onto them. I think the simplest solution for that is just to make sure any redirect URLs include "//" (e.g. use http URLs). I think it is too late within any Process module to throw a 404 exception. The best I could come up with is to check that any URL segment is valid and if not redirect to the 404 page. Maybe someone will discover a better way. Thanks to this post I think I have a solution for this, added in the recent commit. ProCache can run on any page where the user isn't logged in, which for guests will be all pages besides the ones executing a front-end Process module.
  20. Steve_Stifler

    OK. I was asking for the purpose of when I go to create my formulas, I am going to need to know how the system thinks to know how to structure my "Fetch" statements ro however I grab data from another Table's/Page's field. So taking what TTS said and from what you are saying (and please excuse the terminology but I think you guys are smart enough to translate into PW as I'm not yet!) I have a Table/Page called "PORTFOLIOS" which houses the Assets and Liability related fields of a client and another called "CASHFLOWS" which houses the clients income and expenditure related fields. CASHFLOWS will need to fetch the "Debt" field from Portfolios to calculate the repayments and PORTFOLIOS will need to fetch the "Salary" field from cashflow and the "Income Items" to determine what is an asset or not. So in this case, for a particular formula which calculates REPAYMENTS am I (in English of course) scripting in CASHFLOWS - Define x as a variable which equals the following * the value of the DEBT field in the table/page PORTFOLIOS - REPAYMENTS = x So I am fetching by telling the system which table/page to go to then the field_name?.....am I on the right track?
  21. thetuningspoon

    I find that the need to set the value of one field to another field is so rare in practice that it cannot possibly outweigh the time, frustration and possible security flaws that dealing with turning off and on output formatting has caused me over the years. It is not hard to use $page->getUnformatted('field') in the rare instance when that is what I actually want to do. At least if I am unintentionally saving formatted values to other fields, it is just a mistake and not a potential security concern like outputting fields to the page that are not entity encoded is. And it certainly doesn't seem like it should be an application-terminating error. One example I recently ran into was calling a function to send an email while in the midst of editing a page via the api. In such a case you need to remember to turn off output formatting and back on again before calling the email function (and then back off again before doing your save), or your email will be outputting unformatted fields. it took me ages to figure out why the dates in my emails were sometimes coming out as timestamps. I use setAndSave() now wherever I can, but I do wish I could use the regular object setting syntax sometimes. I think this is why people say that "global mutable state" is dangerous.
  22. I've never created any custom field types myself, but maybe this recent thread helps:
  23. Tom.

    Soo, erm, I was running 3.0.125 Sorry guys.
  24. So I was tinkering around with the "select fields" field type and added it to a repeater. My thoughts were I could have a user select a field (textarea, text, etc etc) that I defined and give it a name (another field in the repeater) and create their own form on the page. To be honest, I am now a little lost with rendering the form and mailing the results as potentially the form will be unique and custom every time. The only way I know to handle the output is by going about it this way: $forms = $page->form_select_fields; foreach($forms as $form) { if($form->name === "form_input") { //output input with custom name } elseif($form->name === "form_textarea") { //output input with custom name } } Is there a better way to go about rendering the elements from the repeater? As far as the custom sending goes, I am really at a loss since it would be pretty dynamic. Has anyone used this type of approach, and if so, how did you handle this without going insane?
  25. Marco Angeli

    hey zoeck, thank you for the feedback. I finally resolved the issue: I installed the module by uploading the zip file: that didn't work. Then I uninstalled everything and followed the instructions: I created a folder named "FieldtypeLeafleftMapMarker" with everything inside and that worked. Thanks again.
  26. rgaikema

    Thank you Spica! I will look into this
  1. Load more activity
  • From Twitter

    • New post: This week we take a look at what’s in ProcessWire 3.0.126 which focuses largely on resolving issue reports, but also includes a handy new Page if() method— processwire.com/blog/posts/pw-…
      15 February 2019
    • New post: ProcessWire 3.0.125 has several useful new Sanitizer methods & options, plus new ways to access them directly from the Input API variable. This makes handling user input even easier than before. Plus updates to our i18n functions & API docs— processwire.com/blog/posts/pw-…
      25 January 2019
    • New post: In this week’s post, we’ll take a look a look at the new website and focus on some parts of it and how they were built. Then we’ll dive into the latest version of ProcessWire on the dev branch, version 3.0.124— processwire.com/blog/posts/pw-…
      11 January 2019