neocreo

Is there a HTTP_USER_AGENT set for Simply Static?

had the same problem. zip files seem to come out corrupted. Can be fixed using a repair tool. Or just opt for downloading from a local directory instead.

Solved

Solved

I will just get rid of the old plugin. Apparently not supported any more anyways.

Andrew Ozz, with all due respect – you are wrong. tables can have percentage widths, and it is actually a better way than to have widths set in pixels. And it works brilliantly for large tables with plenty of columns. As a matter of fact, it works better to have td:s with 20% added, than 200px.

OK, so WOW! I think I solved it.
I was dabbling with the MIME-types and that didn’t work. So now I looked at WHEN the file is served.

Row 70 in wp-document-revisions.php
add_filter( 'template_include', array(&$this, 'serve_file'), 10, 1 );

It seems like the standard priority of 10 is not good enough in WP +4.5.3.

add_filter( 'template_include', array(&$this, 'serve_file'), 15, 1 );
As soon as I changed the priority to HIGHER than 10 it worked. Lower than 10 it caused corruption.

I hope this information might come in handy for all you other hackers of this dead plugin.

Hmmmm. Apparantly not only PDFs.
I have managed to recreate this problem with other filetypes.
ODT – corrupt – from LibreOffice
PDF – works – from LibreOffice
DOC – works – from LibreOffice
DOCX – corrupt – from LibreOffice

It must be that the plugin has trouble handling certain filetypes. Guess I need to do some scouring here in the support forum again.

I have mucked about a little bit, and it seem like some work has been done on Github on this fork Github for Washington State

However, I had to reset the mime-type edit they had done for S3, otherwise I just saw the raw code of the files in the webbrowser.

Furthermore, I have looked on my server, and the uploaded files are uploaded correctly. When downloaded via FTP, they are uncorrupted. Something must be going on when it translates the file-name to the file in the upload directory.

I have also tested in uploading a variation of PDF-documents.

• Adobe illustrator PDF: Works
• Libreoffice PDF: Works
• NAP PDF (scanner software): Works

What doesn’t seem to work is PDFs created by my clients scanner/printer. Those are the only ones being corrupted when I upload them.

Will keep on posting if I find anything else.

• This reply was modified 8 years, 1 month ago by neocreo. Reason: forgot link text

OOOOOH OK! Now that explains it. I thought that referred to blocks of time in the calendar.
Clearly I didn’t understand the clarification on that option… doh!

I can now remove the ugly hack I made.

Thank you for your patience.

I found a way to hack this.
It is basically in the easy-appointments > js folder.
edit either frontend.js or frontend-bootstrap.js and do a change for the datepicker minDate.
minDate: 0 can change to minDate: 2.

However, I think this would be a good setting to have to allow for services that has this specific need of preparation.

Great plugin! Nicely organized and easy to plan too.

Thanks for the rapid reply Mihai ??

OK, apparantly the client had made a boo boo with the page template. There was no the_content() in the shop.php template.

I would like to chime in on this.
Needed to break out a site from a multisite installation and the documents failed to import, and the permalinks to the documents lack file endings.
Tried uploading via FTP into the original locations, but nothing works.
Wordpress 4.5.2 if you wonder. Clean install and then import.

Ignore that previous message, yup, will have to find a way to render the svg as a PNG file on the server side. Hope you don’t mind if I post my findings here for reference?