szabesz

Because of this I either move the name filed to the content tab (which is OK for a non multilanguage site, but for more than one language it is wasting a lot of valuable space at the top of the edit page) or display the name right under the Title field's label, which is not editable but at least not so hidden as the Setting tab. There is room for improvement is this area for sure. WP's solution is very good, except that it is single language and I've never seen their(?) multilanguage solution.

If you try to create some sort of page-builder featureset this way, than this is not what you are looking for as fields and templates are for developers (and most of the time they are the only superusers in the system...). People usually use RepeaterMatrix or sometimes the PageTree to implement page-building functionalities. There are plenty of examples in the forum demonstrating these. Some devs used custom coding too, again, they showcased their work in the forums.

In addition to what @teppo said above, some sample snippets to get you sarted:

Related: MDN Now Built With React https://www.i-programmer.info/news/87-web-development/12972-mdn-now-built-with-react.html

People should boycott FB - and any other similar sites for that matter - for their own good anyway.

Hello folks, Your voice can also be heard: https://hacks.mozilla.org/2019/07/mdn-web-developer-designer-survey/ "The survey results will be published on MDN Web Docs (MDN) as an annual report. In addition, we’ll include a prioritized list of needs, with an analysis of priorities by geographic region."

Hi, It looks like you are right: https://processwire.com/docs/tutorials/but-what-if-i-dont-know-how-to-code/

In my case the solution was to install a clean system and set up all the apps I use. No wifi issues ever since.

Simply hooking into Page:viewable might not be enough, see: Meaning $pages->find() works independent of Page::viewable ?

Also worth noting: https://stackoverflow.com/questions/5943149/rebase-array-keys-after-unsetting-elements

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...

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..."

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.

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 ?

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.

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:

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/

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?)

? 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.

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.

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.

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.

Hi @AndZyk I can confirm this. If I upload a PNG saved by Photoshop then all is good but if I upload a PNG optimized with ImageOptim then transparency is removed and some sort of inverted version of the image is generated. It does look like it is a ProcessWire 3.0.132 issue indeed. It would be great to fix it ASAP as it is a real pita....

I would like to add that by using vanilla JS only, one has to keep an eye on event listeners in order not to introduce memory leaks, and jQuery does remove "its own" listeners before disposing of a node, which is quite handy. The only issue with a helper like jQuery is that it keeps changing (because it keeps evolving) and it might be problematic to update possible other jQuery dependent components of a website when their new versions start to require different versions of jQuery. Yeah, dependency is always an issue but I do not think it is possible to eliminate it completely anyway.

I guess Ryan is going to fix any bugs which are worth the effort, especially if the bug report itself is as helpful as it can be.