Jump to content

szabesz

Members
  • Posts

    2,700
  • Joined

  • Last visited

  • Days Won

    16

szabesz last won the day on January 31

szabesz had the most liked content!

1 Follower

Contact Methods

  • Website URL
    http://szabesz.hu

Profile Information

  • Gender
    Male
  • Location
    Hungary

Recent Profile Visitors

8,767 profile views

szabesz's Achievements

Hero Member

Hero Member (6/6)

3.1k

Reputation

3

Community Answers

  1. This is the same UX issue I always encounter with "ProFields: Page Table" (aka FieldtypePageTable) as well. So far, I have only solved it for Page Table, but I guess you could do something similar in your case as well. I used JavaScript for the admin to clone the button, like this: /* * Adds a clone of the PageTable field's Add New button to the top of the table */ function clonePageTableAddButton() { $(".InputfieldPageTableButtons").each(function () { $myButtons = $(this); $myTableContainer = $myButtons.closest(".InputfieldPageTableContainer"); //Only add button when Table is not empty (length != 0) and no button has been added already (length < 2) if ($myButtons.closest(".InputfieldPageTableContainer").find(".AdminDataTable").length != 0 && $myTableContainer.find(".InputfieldPageTableButtons").length < 2) { $myButtons.clone().prependTo($myTableContainer); } }); } I also had to solve the issue what crops up when the Page Table is updated via ajax calls, so I had to implement a little bit more what I posted above, but if repeatable fields are not updated via ajax, then probably something no too complex to code should be enough to clone the button after the DOM is ready to be manipulated. Hope this helps.
  2. I agree. However, to make a tutorial series complete, one needs to introduce the basics as well. Perhaps a concise but not too long overview would do the trick (especially if it links to all the official docs and blog posts in order to point out where to learn more about the basics). @3fingers In order to teach as much as possible in the shortest possible time, you might want to provide your learners an installable site-profile which does all the basics already, and you "just" finish it off by implementing the rest (which is everything beyond the basics). I would also pay for such a course, so that I can think outside of my box (and to support your efforts, of course).
  3. Have you already seen this library perhaps: https://github.com/k-samuel/faceted-search ?
  4. Hello @3fingers, +1 to this approach. What I think nowhere demonstrated in a nice and concise tutorial is the broad topic of search. One can take a look at Ryan's Skyscrapers demo profile but other than that there are just scattered bits of info on the topic. There is also @teppo's SearchEngine but that is a 3rd party module and I am not sure it can be used for Faceted Search or not, for example. With all that ecommerce raging these days, showing how to implement Faceted Search would be invaluable (along with listing products, sortable by categories), I think. Also, frontend autocomplete is another valuable topic, and what I have not yet tried but looks useful to build upon is InputfieldTextTags: https://processwire.com/blog/posts/pw-3.0.177/ See this related quote from Ryan: "...InputfieldTextTags works on the front-end, such as in FormBuilder or LoginRegisterPro forms, or any other InputfieldForm on the front-end." I have done some of the above over the years (built on ProcessWire of course) and I had to dig up ideas from source code of modules and from this forum of course. However, a guided tour can always speed up the learning process. Good luck with your endeavor!
  5. Inserting some HannaCode into the editor via TinyMCE Templates could be an easy way to add HannaCode with a simple preview and some description. Maybe something as complex as HannaCodeDialog by @Robin S could be based on the TinyMCE Template plugin. Anyway, my current issue is, that I could not make TinyMCE Templates work because InputfieldTinyMCE seems to be parsing the template options setting improperly, see my issue report for details: https://github.com/ryancramerdesign/InputfieldTinyMCE/issues/16
  6. Another option is to use the Toggle InputField: https://processwire.com/blog/posts/pw-3.0.139/#new-toggle-field as it has a "Default selected option" (yes / no / no selection) setting among other useful settings.
  7. It used to close just the InputField in question, yeah, which I always found strange. Currently, the most up-to-date dev version I am working with is 3.0.205 which also works the way you noticed, except that there are cases when the label and icons left to the closed InputField disappear:
  8. Was it generated with an Ipsum creator, I wonder? As it does not even make any sense. BTW, if anyone interested, here is one that can even generate fake code snippets: https://jaspervdj.be/lorem-markdownum/ which is kinda cool.
  9. While not "most of them" but surely a lot of them, so I agree that our options are limited. I'm not keen on Font Awesome icons, btw. I guess they can be downloaded and actually be bundled with the core, but I cannot find an easy way being offered to do that. https://github.com/google/fonts What I found is this: Download All Google Fonts You can download all Google Fonts in a simple ZIP snapshot (over 1GB) from https://github.com/google/fonts/archive/main.zip Another option is this, for example: https://icons.getbootstrap.com/
  10. Hi, Can you be a bit more specific? What is the exact wording of the message and what is its actual source? Do you have a backtrace or something else?
  11. Just a quote from Ryan from the past (I forgot to jot down the source of the original, sorry...) "In order to run an upgrade/download process, the module must be loaded and its upgrade() method called. With the exception of "autoload" modules, ProcessWire loads modules on demand, as requested from the API. This is an intended behavior. When you do a "Modules > Refresh", it should tell you about version changes it found and also indicate that it will apply those when the module is next loaded. Module changes are applied when the module is next loaded, so it's not a matter of scheme (http, etc.) but rather just whether the module is needed and thus loaded for the request. Many modules are only used for rendering http requests (such as Process) modules, so it may have that appearance that http is required for some. It's best that updates are only applied when a module is actually going to be used, since it is the module's own upgrade() method that is called to perform the upgrade. And loading a module in a context where it wouldn't typically be used might be problematic or cause errors. But if you have a need for to do this, you could try doing a foreach $modules and load each module individually $modules->getModule($name)... updates will be applied as each is loaded. Again though I think it may be potentially problematic to do that since this is not the way it's designed to apply upgrades."
  12. Thanks a million Ryan! My highlights: it'll be available to install by or before this time next week Yes there's a dark mode! The toolbar configuration ... via InputfieldTextTags ... plugins are selectable from checkboxes Five UI The inline editor after we click in it Multi-language I will especially be happy to use Five UI and the inline editor appearing after we click in it, as these options save a lot of screen space which I prefer to whitespace bonanza. BTW, may I propose that in the "other settings" section we can also have options via InputfieldTextTags wherever appropriate (instead of typing in literals).
  13. As for direct statement about financial advantages I cannot provide anything (thought I remember reading something related to it) but I do infer such a thing from this comment, for example: https://processwire.com/talk/topic/2043-drupal-vs-processwire/?do=findComment&comment=19084 Quote: "The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious)." Well, while writing this, I actually remember reading somewhere that he wrote that his previous way of doing business (when still using Drupal perhaps) was more profitable than the current one based on ProcessWire, but that is not just about working with PW vs Drupal but as business as general. Maybe we should ask @ryan itself? Anyway, as an addition to the actual topic: This might also help @3fingers when explaining the benefits: https://processwire.com/talk/topic/4426-pushing-pw-in-web-design-agencies/
  14. Relying on the frontend cache all the time is the telltale sign of the system's request process being very slow most of the time. Usually it is the result of over-engineering and "enterprise developers" are soo keen on that. In my coding vocabulary: $enterprise === $overEngineering // > true Also tell them that Ryan developed ProcessWire because working with Drupal took so much extra time that even developing his own system was a lot better choice, therefore more profitable. Probably Nette's Tester can do the trick when they complain, see:
×
×
  • Create New...