Jump to content

szabesz

Members
  • Content Count

    2,232
  • Joined

  • Last visited

  • Days Won

    12

szabesz last won the day on June 17

szabesz had the most liked content!

Community Reputation

2,492 Excellent

About szabesz

  • Rank
    /sɑːbɛs/

Contact Methods

  • Website URL
    http://szabesz.hu

Profile Information

  • Gender
    Male
  • Location
    Hungary

Recent Profile Visitors

5,498 profile views
  1. In my case the solution was to install a clean system and set up all the apps I use. No wifi issues ever since.
  2. Simply hooking into Page:viewable might not be enough, see: Meaning $pages->find() works independent of Page::viewable 😞
  3. Also worth noting: https://stackoverflow.com/questions/5943149/rebase-array-keys-after-unsetting-elements
  4. Buying ProFields for this reason only should be enough 🙂 After all, without Ryan there is no ProcessWire so we need to support him. Anyway, I think ProFields really shines when one needs it for Repeater Matrix. The other modules can also come in handy sometimes but with other free modules and/or other built in modules similar functionalities can also be implemented mostly without too much effort. What I find not powerful enough is Table. The features of Table are quite limited. I understand that implementing such an inputfield is quite time consuming, so developing a much more powerful ProTable module as an independent paid module would make sense. For example, @bernhard has been working on his on his modules (#1 and #2 and maybe more?) and we also have the not-really-worked-on-anymore ProFields: Page Table with lots of lucking features as well (eg.: pagination). All this development effort towards an independent Pro module based on tabulator.info would be welcome. I imagine a "ProFields: Page Table" based on Tabulator which would be a big hit...
  5. Sounds like this issue is sowewhat related to this one: https://processwire.com/talk/topic/21716-processwire-profiles-whats-missing/?do=findComment&comment=186721 Maybe @Jonathan Lahijani has already come up with his "solution"? Quote: "...I don't know what term would accurately describe it, but its a ProcessWire module that's an opinionated, update-able starting point, oriented towards developers..."
  6. In the case of order numbers - for example - it is common not to start counting form 0 and not to increment by 1. This is a practice to make it harder for the customer to realize that a brand new webshop has just started selling... So as the comment says: @param int $change (optional) The amount to change the counter by. Must be non-zero integer. Defaults to 1. @param null|int $min (optional) If specified, the returned value will be greater or equal to this value. "If specified, the returned value will be greater or equal to this value." actually means: initial starting value.
  7. Hi all, Stumbled upon this recently: https://frontendmasters.com/books/front-end-handbook/2019/ ( https://github.com/FrontendMasters/front-end-handbook-2019 ) Quote: "This is a guide that anyone could use to learn about the practice of front-end development. It broadly outlines and discusses the practice of front-end engineering: how to learn it and what tools are used when practicing it in 2019. It is specifically written with the intention of being a professional resource for potential and currently practicing front-end developers to equip themselves with learning materials and development tools. Secondarily, it can be used by managers, CTOs, instructors, and head hunters to gain insights into the practice of front-end development." Plenty to explore! I've warned you 😉
  8. Yes. I'd rather give you access to the site (as it is not yet live anyway) so that you can also use Tracy's file editor to poke around. What do you think? BTW, I could not really uninstall the module, it was just FieldtypeRuntimeMarkup which seemingly went through the uninstall process, but PW – as expected – kept complaining about InputfieldRuntimeMarkup being used when I also clicked the uninstall button of that one. However, if I delete the RuntimeMarkup filed, I am back where I started.
  9. Hello @kongondo I updated a site to v.0.0.6 and now when trying to edit a – seemingly unrelated – TextareaLanguage field by using the field overwrite editor modal of a template I get this: Fatal Error: Uncaught Error: Class 'ProcessWire\RuntimeMarkupUtilities' not found in .../site/modules/FieldtypeRuntimeMarkup/InputfieldRuntimeMarkup.module:68 Stack trace: #0 .../wire/core/Modules.php(624): ProcessWire\InputfieldRuntimeMarkup->init() #1 .../wire/core/Modules.php(1336): ProcessWire\Modules->initModule(Object(ProcessWire\InputfieldRuntimeMarkup), Array) #2 .../wire/core/Modules.php(1193): ProcessWire\Modules->getModule('InputfieldRunti...') #3 .../wire/core/Modules.php(1566): ProcessWire\Modules->get('InputfieldRunti...') #4 .../wire/modules/Fieldtype/FieldtypeTextareaHelper.php(40): ProcessWire\Modules->find('className^=Inpu...') #5 .../wire/modules/Fieldtype/FieldtypeTextarea.module(338): ProcessWire\FieldtypeTextareaHelper->getConfigInputfields(Object(Proce (line 68 of .../site/modules/FieldtypeRuntimeMarkup/InputfieldRuntimeMarkup.module) This error message was shown because: site is in debug mode. ($config->debug = true; => /site/config.php). Administrator has been notified. Error has been logged. I tried uninstalling the module (because the site does not use it yet anyway, meaning there is no field using RuntimeMarkup) and when I click on the uninstall button I also get: Class 'ProcessWire\RuntimeMarkupUtilities' not found However, if I create a RuntimeMarkup field then the error goes away in both cases described above. It looks like the case when there is no RuntimeMarkup filed in the system is not taken into account. So with a RuntimeMarkup field created, I could uninstall the module as the fatal error did not crop up in that case. Also note that I find it strange that both FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup show up as RuntimeMarkup in the module list, see the screenshots:
  10. Just want to add for anyone reading this post, that while in the admin this cannot be done, it is doable via code. By putting something like this into init.php,: $templates->get('home')->filename = $config->paths->templates . 'views/home/home.php'; it is possible to store a template file wherever you want. Read more about this in this topic: https://processwire.com/talk/topic/2676-configuring-template-path/
  11. I do not need it 🙂 but my client does so I had to find a way not to upload the "same" image twice, once for the client and once for the site. The client also needs those PNGs to be as small as possible, so that is where crushing them comes into play. Anyway, if you could revert the change, that would be great for the time being. Maybe a note in the source code about the issue could help to decide when to add it again to the supported filetypes is feasible. (A few years from now on, maybe?)
  12. 🙂 I know the theory, however, saving space can be important on some servers. Also, in this particular case form a 3000x3000 PNG8 a 1000x1000 JPG is generated, and I do not think anyone can tell what the source was just by looking at it.
  13. I see! Yes, those PNGs are indeed PNG8 in my case. Tracy on MAMP Pro reports :IMAGICK SETTINGS Version: 6.9.6 Whereas in production: IMAGICK SETTINGS Version: 6.7.8 It seems like it is a bug in older verions of Imagick which are still quite common, I guess.
  14. Hi @tpr I have z-index issue with UIkit Sticky header being on. input.InputfieldDatetimeDatepicker has a higher z-index than the header. I quick fixed it with #pw-mastheads {z-index:11 !important;} but I'm not quite sure what to do.
  15. Hmmm, upon further inspections, I'm no longer so sure that it is a ProcessWire issue because the clone of the site in question in my local dev environment (MAMP Pro) can generate proper PNGs, while the one in production cannot. But still, it started happening after some ProcessWire upgrades.
×
×
  • Create New...