maxxd

If your host provides cpanel, try the Metrics > Errors log. That may point you in the right direction.

Yes. Depending on how everything is set up and when and where the function is defined you may have to pass jQuery to the function, but it's easily doable. For instance (and please note it's late and this hasn't been tested so ... you know, look up the functions but the idea is solid) this: $('#mycontrol').on('click', function(e){ e.preventDefault(); $.post({ // ....etc etc... }); });

OK - I've been beating my head against this for a bit now and I give up... I've got a vagrant box up and running on my host system. I'm using gulp with several node modules from the host system, and everything is working well except browser-sync. My directory structure (abbreviated): /dev /_assets /javascript /less /build /templates gulpfile.js package.json Here's the code so far: const _ = require('lodash'); const aw = require('gulp-load-plugins')({ pattern: ['*'], scope: ['existingDevDependencies'] }); aw.browserSync = require('browser-sync').create(); const pkg = require('./package.json'); var themeName = pkg.name.toLowerCase().replace(new RegExp(' ','g'), '-'); aw.gulp.task('Develop', ['browserSync', 'developJS', 'compileCSS', 'watch']); var theme = { srcJS : '_assets/javascript/**/*.js', srcCSS : '_assets/less/**/*.less', srcStyle : ['!_assets/less/variables.less', '_assets/less/style.less', '_assets/less/**/*.less'], destJS : pkg.directories.content + '/js', destCSS : pkg.directories.content + '/css', }; /** * Set up the browser reload on the host machine when the files are updated */ aw.gulp.task('browserSync', () => { aw.browserSync.init({ proxy: "vagrant.craft.internal", host: "vagrant.craft.internal", open: "external", port: 80, }); }); /** * Development JavaScript handling. * Browserify, Babelify, and uglify with in-line sourcemapping */ aw.gulp.task('developJS', () => { "use strict"; _.forEach(_.castArray(pkg.scripts.entry), (script) => { aw.browserify({ entries: ['./_assets/javascript/' + script + '.js'], debug: false }) .transform(aw.babelify, { compact: true, retainLines: false, comments: false, }) .bundle() .on('error', handleError) .pipe(aw.vinylSourceStream(script + '.min.js')) .pipe(aw.vinylBuffer()) .pipe(aw.uglify({ sourceMap: { url: 'inline' } })) .pipe(aw.gulp.dest(theme.destJS)); }); }); /** * During development, obviously we want the system to watch for any * important changed files and to handle those automatically. */ aw.gulp.task('watch', ['browserSync', 'developJS', 'compileCSS'], () => { "use strict"; aw.gulp.watch(theme.srcCSS, ['compileCSS', aw.browserSync.reload]); aw.gulp.watch(theme.srcJS, ['developJS', aw.browserSync.reload]); aw.gulp.watch('./build/templates/**/*.html', aw.browserSync.reload); }); /** * Production and Development .less processing * Processes the .less to CSS, then minifies the file. * Note that grid support is enabled and we're bablifying * back to IE10. This should change in the very near * future as we drop support for 10. */ aw.gulp.task('compileCSS', () => { "use strict"; return aw.gulp .src(theme.srcStyle) .pipe(aw.plumber(handleError)) .pipe(aw.less({ strictMath : 'on', strictUnits : 'on', })) .pipe(aw.concat('all.css')) .pipe(aw.autoprefixer({ browsers: [ "last 2 versions", "IE 10" ], grid: true })) .pipe(aw.cssmin()) .pipe(aw.rename({ extname : '.css', basename : 'style' })) .pipe(aw.gulp.dest(theme.destCSS)) .pipe(aw.browserSync.stream()); }); browserSync initializes just fine - my browser opens, loads http://vagrant.craft.internal and my terminal shows the proper Local, External, UI, and UI External addresses. I update my .less, .js, and .html files and my terminal says 'Reloading Browsers'. But there's no browser reload...

I'm totally confused - you say in the OP that a problem is that " it won't hide those previously refunded entries. ", but you need to see the previously refunded entries? I'm not getting it, so I'm gonna bow out in an attempt to lower the signal-to-noise ratio...

Chances are very good, yes. However, it's going to depend on how the tables are structured. I'm assuming there's a way to tell refunds from sales in your database - use that as your JOIN criteria. So, basically, when joined on transaction ID.

This sounds like a data gathering issue. I assume the data's coming from a database and includes a transaction ID and transaction type, yes? Would it be easier to pull transaction type sale without a corresponding refund transaction type - I'm sure there's additional business logic to be considered, but it seems to me it'd be easier than pulling everything and culling data you don't want from that.

I'll admit, given that you could handle assigning a value to a variable and reading a value from a form element, I honestly just kinda assumed you'd be able to extrapolate assigning a variable value to a form element. Kicken's example should work for you - follow Barand's advice and tear it apart. As to the question of doing the data manipulation on the server-side, it depends on what you're doing and how you're comfortable doing it. The world is moving to a place where online applications act and feel like desktop applications, so getting comfortable with asynchronous functionality (AJAX and fetch) will serve you well in future development. However, if you're not familiar or comfortable with JavaScript (or any of the umpteen bazillion JS frameworks that are out there now) but feel good with PHP, do it on the server side. It'll get the job done and give you more time to explore other processes and solutions.

I'll just leave this here again (I added the emphasis). You need to change the value of the field before you submit the form. Or follow kicken's suggestion to do the data modification on the server side in PHP. Or use the jQuery Datepicker widget and avoid all these issues you've been banging your head against for several days now.

Again, are you setting the value of #birthday to the computed date before you submit the page? If not, the processing script will have 'birthday' in $_POST['birthday'] because your validation script doesn't change the value of the field.

I'd give http://api.jqueryui.com/datepicker/#method-getDate a shot - it should at least put you on the right track for this. http://api.jqueryui.com/datepicker/#option-yearRange You're already running a complete page refresh on form submit, so I don't really see where this would become an issue for you. And again, you could format the date string in PHP before it's output to the page, thereby negating what appears to be a pain point for you.

Legit. However, you can use jQuery's datepicker with drop-down month and year selectors to make this easier. To the question at hand, you say you're getting the date from a drop-down menu. How is that built? Seems to me it'd be easiest to add the leading zero on the value attribute (not necessarily the display text) during form compile rather than during validation and/or submission. As to your question about the validation, it depends on how you're submitting the data to the controller script. If you're submitting via AJAX from JavaScript, make sure you're passing the 'birthday' variable you've built in that snippet. If you're doing a full page refresh, assign the value of the 'birthday' variable to the hidden input before submitting the form - otherwise whatever script is processing the form data is getting the data from the hidden form field and not the JS variable.

Is there a reason you're not using a datepicker? I know the jQuery DatePicker has formatting options and I have to assume other native/node/ESx datepickers do as well. It'd certainly be easier than prepending zeros to combobox values everywhere.

I'm pretty sure - though I could be wrong - that rem and em take browser zoom into account, so if I'm right that could be another thing to look at. Although requinix is correct - the entire point is to make the font bigger. It can be pretty safely assumed that people that use the zoom functionality know they're messing with the designer/developer intent of a site and are OK with it. Kinda like turning off JavaScript in your browser - you do it and you pretty much forfeit the right to complain about site functionality (now days, anyway).

You would simply pass the database query results (or portions thereof) to the function that outputs (or collates the data for) your form. It certainly doesn't need to be a global variable, unless I'm misunderstanding what you're asking. Post the code you're working with and we'll all have a better idea of what's going on.

Add $mail->SMTPDebug = 2; before you try to send the mail. It'll give you a lot more detail as to the error that's happening.