bernhard

I think you would need a login for the clients then. You can do shopping history with cookies - but I doubt how useful that would be... as dragan already mentioned users can switch devices and the history would be lost... true, thx

I've done something like this using cookies: https://www.grafikgesellen.at/textilien/textilien-mit-wunschdesign/t-shirts/ I'll showcase the site as soon as they've launched it. Any feedback already welcome (don't want to intercept this thread though ). This one sounds a little more challenging. I think you would need a login for the clients then.

don't know if this site was already posted or where they get their data from, but maybe it is interesting for someone: https://trends.builtwith.com/cms/ProcessWire/Market-Share

At the moment I have loads of other things to do that have priority, sorry. Maybe if you implemented the save/open feature it would already be usable? Should not be that hard..

no "ironic" tags... and not even in the pub... *uff

@tpr seems he is already using it

Fixing the error is no option? I can imagine there are situations where fixing is not the best option, for example I just created a filter for my mailbox that deletes warning emails about AIOM warning In this case fixing the issue would mean hacking this module, what I do not want to do. On the other side those warning e-mails are annoying, so I came up with the filter solution (deleting e-mails containing "AllInOneMinify.module:713"). So I still get other warnings but don't get annoyed by this special one. Maybe that's also an option for you? Fatal error sounds a little more serious though than my php warning

Hi and welcome! Advice: Definitely stay in the admin! I had exactly the same thoughts before I created my CRM because modifying the admin seemed totally complex and out of my scope. But once you get the concept it is REALLY simple and you get all the benefits that the pw backend offers (all fields, all functionality like login, sanitization, field collapsing, hooks etc). That's why I created the blogpost that Robin linked to (thx btw ). The ROI (return on invest) of digging into the PW admin is huge and it will help you a lot to improve all your pw related work, because you will understand everything a lot better. I wish you good luck and a lot of fun

Thanks for the effort! Am I misunderstanding something or is the only difference to the Matrix Field the code+preview sections? I have the feeling that if you really need complex blocks with complex visualisations it might be better to stick to frontend editing? Maybe it could be an option to load frontend editing into an iframe in the backend (whooo, no idea if that makes sense in any situation, just thinking loud ).

Veto! I think that should be done by the core Also came around this several times and was annoyed. So I think it would be better to open a PR than adding another snippet to AOS.

Sorry and thx, it's a ProfieldsTable Anyhow... I don't want to dig deeper into this issue. Thanks for all your help. I could file a bugreport, but I would have to check a lot more if it is a bug or just a misconfiguration on my side. No time for that atm, and you helped me to identify what is the issue and so I can happily live with that, thx

Inside a pagetable?

Yep, thx, I believe you The thing is just that I was unclear here: de_DE does not work LC_ALL=de_DE.utf8;LC_NUMERIC=C does work, but: LC_ALL=de_DE does also work, so I guess your example is ignored because it is wrong somehow. This is the description of the field, so I think your example would lead to something like setlocale(LC_ALL, 'LC_ALL=de_DE.utf8;LC_NUMERIC=C') ...and I guess that is wrong and therefore ignored

Thx, i removed the locale setting from the translation file ( it's here if anybody is interested: /setup/language-translator/edit/?textdomain=wire--modules--languagesupport--languagesupport-module ) and it works. Don't know if your line really helps - I think it's just ignored since XXX also works (just like leaving the field empty). As long as I don't have any other issues with the default locale I'll continue using it.

{ "file": "wire\/modules\/LanguageSupport\/LanguageSupport.module", "textdomain": "wire--modules--languagesupport--languagesupport-module", "translations": { "4994a8ffeba4ac3140beb89e8d41f174": { "text": "Sprache" }, "185d23ff9526ad93077a1c9ad5ed26a2": { "text": "E-Mail-Adresse" }, "b78a3223503896721cca1303f776159b": { "text": "Titel" }, "0d61f8370cad1d412f80b84d143e1257": { "text": "de_DE" }, "3f94f86633491ad8e5d18f5e481330c2": { "text": "\u00c4nderungen zu diesem Feld werden nicht gespeichert weil Sie nicht berechtigt sind f\u00fcr folgende Sprache: %s." } } } Sorry @BitPoet I don't get what you are saying The locale is de_DE (of course). But I have no clue how this whole locale thing works and where the problem is. Maybe it's on my server? locale -a shows: C C.UTF-8 de_DE de_DE.iso88591 de_DE.utf8 deutsch en_US en_US.iso88591 en_US.utf8 german POSIX Thx everybody so far!

Thanks for your help so far. I would not have asked if I knew where to look and what for. I've also only very limited experience with locales, so I don't know where and what for I could look. I just inspected the file that causes the problem and I didn't see anything strange..

Interesting... When I delete all translation files it works... OK, found the file... As soon as I upload wire--modules--languagesupport--languagesupport-module.json it breaks. All other translation files seem to work. Any ideas what could cause this strange problem?? It's not important, because I have again a working german admin with decimals but maybe that's worth a bugreport? No idea thought what the bug is actually...

Hi everyone, I have a quite old and stable website running 2.7.2 multilang (only for having a german admin, the frontend is german only). Today my client told me that they cannot save decimal values to the price fields in repeaters. I narrowed it down and the strange thing is that it works on the default language (english) but does not work when the users language is german. It just strips off everything after the comma. First I thought that might have something to do with dot/comma sign, but it's the same for both. Also my module that replaces , by . is not the reason. I created a new test-field of type float and this single field worked without an issue. The pagetable item is of type "decimal". I tried "float" as well. Same result. The quickfix is that i switched the admin for my client back to english - not ideal but it works. Does anybody have ideas what I could check? Any of you ever had a similar problem? Thanks

nice idea! it's only my personal blog and atm just for my thesis... so no time for gimmicks like this but with that fix we would be very close to bard! also good idea. though, i guess in my case this would not be possible, because i have some html code blocks that inject script tags and also some textareas that are rendered as highlighted code.

Are you aware that your changes to wire/modules/InputFieldImage.js will be lost when you update your processwire installation? I'm sure there's a better but also simple solution if you already have a working setup

719kb is really not huge and it should not be a problem on any server

Should be quite simple. You can see adrians module: Instead of using InputfieldFile you would use InputfieldImage: https://github.com/adrianbj/CustomUploadNames/blob/master/ProcessCustomUploadNames.module#L98

just got an email from them:

Sure, you can create a ProcessModule only for that purpose like shown in my blogpost and then restrict this module to your desired roles.

are you uploading huge images? maybe you find some helpful information in the console log and in pw's log folder?