dragan

Just a quick note: remove the hints in the function, otherwise it won't work: function getFieldsetOf($context, $fieldsetName, $collectValues = false, $fieldsetCloseIdentifier = '_END'); // this will work function getFieldsetOf($context, String $fieldsetName, bool $collectValues = false, $fieldsetCloseIdentifier = '_END'); // this won't at least not with the latest PW dev on PHP 7.0.9 example function call: $fieldSet_import = getFieldsetOf($templates->get('project'), 'import_only', false, $fieldsetCloseIdentifier = '_END');

I never used Blade, so I don't even know if that's an option, but can you tell Blade to not create that cache file in the first place? If that's not possible, try to disable cache in your template(s). Alternative multilang approaches are described here: And then there's also the recently added functional fields (never used it myself so far): https://processwire.com/blog/posts/functional-fields/

I'm sorry, but I have never used hooks until now. When creating pages directly with the API, I made it a habit to simply add the necessary language actions in the same script. Basically, you then use $page->save() twice. 1st step: add page, define parent, template, fill field values etc. save #1. 2nd step: with the new page id you get, add the lang. actions (status etc.). save #2.

Try to avoid using persistent connections? I see you bumped up the timeout from 10 to 50 seconds already - did you change the wire core file? https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Session/SessionHandlerDB/SessionHandlerDB.module#L69 There's an alternative session handler here: https://modules.processwire.com/modules/session-handler-redis/ But regardless, 600k pages is a lot... some tweaking for performance will probably be necessary on any setup. Perhaps somebody else can chime in with suggestions. I never had to deal with such huge PW-installs.

That's the problem with CSS-frameworks. They do some stuff OK, save you time in the short-run, but they're a pain in the neck when you want to have it your way. Nowadays I don't understand the wish for using a CSS-framework. At the very least, you should be highly selective (e.g. only get helper-classes and mixins). tbh, this <h2 class="title is-2"> looks retarded... What's known im BEM philosophy as modifiers makes sense, but h already stands for heading, and h2 already states that it's a level 2 heading. Why overcomplicate things so much? What's next? <p class="is-paragraph">lol</p> <table class="is-tabular-data">...</table>

It works with v. 3.0.62... well, sort of. When I get results / list, the console says ProcessBatcher.js?v=104-1499794358:54 Uncaught TypeError: $(...).fancybox is not a function at HTMLDocument.<anonymous> (ProcessBatcher.js?v=104-1499794358:54) at l (JqueryCore.js?v=1499794378:2) at Object.fireWith [as resolveWith] (JqueryCore.js?v=1499794378:2) at Function.ready (JqueryCore.js?v=1499794378:2) at HTMLDocument.A (JqueryCore.js?v=1499794378:2) Also, the "Actions..." bar doesn't work anymore

Thanks! Re-installed it and everything works like a charm.

Sorry if I ruin your Saturday... I ran into a problem when I copy and pasted something from MS-Excel, where some fields contain line breaks. The frontend displays everything correctly. But in page-edit, I get a JS error, and the same msg again: "Please save this page to be able to change this content" When I inspect the offending line, it's the first occurance of a line break in var field = JSON.parse Do you have any idea what could cause this?

That looks awesome. I finally found some time to play around with it, and I'm quite impressed. I can already see some concrete usage scenarios - especially what you already mentioned re: when it's too tedious to go the "export CSV from Excel, import CSV to PW" route. I am somehow stuck though when trying to add i18n options to the datepicker. I took your example (Jan-Dec), added a few options, and everything worked fine in the back- and frontend, but now I don't see that handsontable anymore in "page edit" mode. I get a message saying "Please save this page to be able to change this content". I did that repeatedly, but it's always the same. Funnily enough, I don't see any errors in the PW error log, and the frontend works just fine (granted, it's only a print_r() so far, but at least it still fetches something from PW and spits it out correctly). Did you run into similar situations? Any idea what I did wrong? This is my JSON: var colheaders = ['Jan', 'Feb', 'März', 'Apr', 'Mai', 'Juni', 'Juli', 'Aug', 'Sep', 'Okt', 'Nov', 'Dez', 'Datum']; hot.updateSettings({ colHeaders: colheaders, minCols: colheaders.length, maxCols: colheaders.length, rowHeaders: false, minRows: 1, copyPaste: true, autoWrapRowBoolean: true, autoWrapColBoolean: true, minSpareRows: 1, columns: [ {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, {}, { type: 'date', dateFormat: 'DD.MM.YYYY', correctFormat: true, defaultDate: '01.07.2017', i18n: { previousMonth : 'Voriger Monat', nextMonth : 'Nächster Monat', months : ['Januar','Februar','März','April','Mai','Juni','Juli','August','September','Oktober','November','Dezember'], weekdays : ['Sonntag','Montag','Dienstag','Mittwoch','Donnerstag','Freitag','Samstag'], weekdaysShort : ['So','Mo','Di','Mi','Do','Fr','Sa'] } datePickerConfig: { firstDay: 1, showWeekNumber: true, numberOfMonths: 3, disableDayFn: function(date) { return date.getDay() === 0 || date.getDay() === 6; } } } ] }); Edit: D'oh - I missed a comma after the i18n block... OK so the table is back, but although Saturdays + Sundays are deactivated, and Monday is set as the 1st day of the week, the days and months still display in english. Guess I have to dig into the original docs a bit further... Thanks for this great addition to PW!

Importing data into PW is certainly no big deal. I guess the actual challenge is to find out whether an update is necessary, or creating a new recordset (page). If your export from the other system (I guess a CRM) only allows to have ALL data exported, then it's going to be tricky. It would be ideal if you had three different exports: only completely new records (new customers, new sales reps) only updates to existing data (new customer address, new sales rep phone number) only removals from the system (or a flag like "inactive") You would probably need unique identifiers (perhaps an ID from your CRM that you store as a special field in your PW-template), to make sure you update the right page.

Didn't have time to test either of these, but you should have a look here: https://modules.processwire.com/modules/fieldtype-select-ext-option/ https://modules.processwire.com/modules/fieldtype-select-relation/ https://modules.processwire.com/modules/process-dynamic-selects/ Maybe one of those does exactly what you want, or at least can be tweaked easily...

Well, I tried to submit the form (with test Mastercard numbers), but looking at the browser console, it seems like there is a security issue because you are trying to post from www.domain to domain. Adjust the form post URL, and see if that helps (use relative URLs, or make sure visitors always get redirected to www.). See attached screenshot. If that doesn't fix the issue, you'd have to look into lamoon.js, or jquery.validationEngine.js (But yeah, as other ppl have mentioned, this has nothing to do with ProcessWire per se.)

Can't you do this? Each product is a page = parent / container. Here you also define all possible variations that each individual item can have. Below are child-pages that serve as individual products. Each page is an individual item with the variations in size, color, fabric. These attributes would be simple checkboxes or radio-buttons / dropdown selects. Add a field for this template to hold SKU (article number) and one for price.

I see this error when looking at http://www.bielenberg-soerup.de/center/ with Chrome, and console open in phone mode... What I also found strange: when opening the hamburger menu on mobile, there is no "close menu" icon visible...

Try to disable cache for the template(s): setup > templates > cache (at least for a temporary workaround if it's a live site) Perhaps checking if pw namespaces are at the top of your files might be another fix (that was introduced with pw 3). https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/#compiled-template-files