bernhard

Members
  • Content count

    1,403
  • Joined

  • Last visited

  • Days Won

    24

bernhard last won the day on November 11

bernhard had the most liked content!

Community Reputation

1,567 Excellent

About bernhard

  • Rank
    Hero Member

Contact Methods

  • Website URL
    https://www.baumrock.com

Profile Information

  • Gender
    Male
  • Location
    Vienna, Austria
  • Interests
    Sports

Recent Profile Visitors

10,324 profile views
  1. glad you like it and thanks for the compliment yeah... it's not as easy to find in the beginning (and often i'm still searching a lot around the code). but most of the necessary informations are not too hard to find if you look at the code. Inputfields for example have a baseclass here: https://github.com/processwire/processwire/blob/master/wire/core/Inputfield.php Also see somas tutorial about forms (i updated my initial post with the link: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ ) I'll see what i can do...
  2. hi dragan, you don't have any limitation when working with InputfieldMarkup. It just RETURNS markup, but of course you can create this markup via php or whatever you want. For example: $html = '<p>This is a test</p>'; for($i=0; $i<10; $i++) $html .= "<div>Line $i</div>"; $field = modules('InputfieldMarkup'); // using the functionsAPI it gets that short $field->value = $html; $form->add($field); but also in my example you could place any PHP code inside the renderChart method.
  3. thats nice! so what about making a PR on github so that ryan can accept the compressed profile? ...and i'm pretty close to release something even more awesome i have to see if the new online installer changed anything or if it still works.
  4. you need to use the classname of the inputfield that you are modifying. your field is inside a repeater, but it is not a repeater itself. if it is a textfield you have to use InputfieldText, if it was a checkbox it would have to be InputfieldCheckbox. Also $field->entityEncodeText = false; is only necessary if you want to use markup in your note
  5. i encourage you to take this challenge as soon as possible. it's really not hard and it will make your head think differently in some situations and make your code cleaner and easier to maintain. and in the end that will save you time have fun
  6. i don't think there is any noticable performance difference (just guessing). the main difference imho is reusability. for small things functions are totally fine. there is a reason why the _func.php file exists in the profile but if you use your function across several pw installations it's for sure better to pack them in a module, host them on some version control system and push updates to all of your sites easily whenever you want. that could get tedious when you have your code spread all over your sites and _func files...
  7. very nice in the second example: where does the content come from? a regular page that is linked? what kind of panel is this? is there a reason why you use an uikit panel instead of the built in pw-panel?
  8. ok didn't know there is a difference. if you do not do already i recommend using adrians awesome tracy debugger module. then you see that inside a repeader the field has a different name: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $field = $event->object; bd($field->name); }); hope that helps and you find your solution on your own i'm busy
  9. mhm, interesting ok, thousands of likes in one pagefield would not be possible. but what about a solution like this in such cases? should'nt it be possible to handle thousands of likes that way? it would be easy to store likes (or any other datatype) via the api and it would be easy to retrieve them. it would also be possible to show them in a paginated way with a runtime markup field and a lister (i guess). or (one day) maybe even with my datatables module (if anyone wants to join me on this project it would be appreciated)... dont get me wrong. i don't want to disagree about this, but i don't really get an idea of how a page reference with thousands of pages could look like. we also have the profields table that creates a database table with desired columns. only the interface for editing lacks support for large data. maybe the problem is just to have a proper way of presenting a large amount of pages inside the page editor (inside a field)? maybe my datatables would fill that gap? i'm using it all around in my projects, so i think there is a need for it. and i think it would be a great addition to processwire. do you agree or are you talking about something different?
  10. hm.. ok i get the point when we are talking about the pagefield in general i agree that it can be limited at some point. i connected it to my datatables module to get a filterable, paginated list of selectable options: but in this case i'm only browsing many pages... i've never had the need to reference a lot of pages in a pagefield. can you give me some examples when you needed this @Robin S ?
  11. of course it it possible i would recommend you to stay inside the pw backend and adapt it to your needs rather than building a frontend on your own. it's really versatile and easy to use once you get the basic concepts of inputfields:
  12. never got any replies on that @Pete
  13. you could do something like this: <input type="checkbox" id="checkall"> <script> $('#checkall').on('click', function() { $('#yourfield').find('input[type=checkbox]').prop('checked', true); }); </script> i don't think there is a need to "bloat" processwire with features when you get simple and taylormade solutions on google or the forum within some hours edit: i know the feeling of looking for plugins and solutions by the CMS for almost any feature you want. but the main feature of processwire is that it so so easy to adopt to your needs that you do not need all those ... plugins
  14. i'm working on something in this direction i have to polish up a lot though. don't know when i find time...
  15. hi androbey, welcome to the forum. you might already have an option for what you want: http://processwire.com/api/multi-language-support/multi-language-fields/#language-alternate-fields this would mean you also get different images for different languages, meaning more storage needed but also the option of different images in different languages https://github.com/adrianbj/AutoImagePages https://processwire.com/talk/topic/8698-creating-page-for-every-image-uploaded this creates a page for every uploaded image meaning you could have 1 image but multiple tags with a regular multilanguage-textfield