Vunderbar

Hey Lou,

Well, that indeed did the trick. You finally got it and your persistence paid off!
Feel free to let loose, crank up a song (or two), and do your version of a Happy Dance around the room.
And take the rest of the weekend off!

Cheers, congrats and thanks!

Hi Loushou,

Just applied the latest update (1.10.29) and …. oooh, So Close.
The browser version is still fine.
And the PDF version is now hunky dory … except for the back portion is missing the map image on the right side.
Otherwise, the layout and fonts and information are all good and displaying properly.

Well what do you know. Our OT was also installed in a sub-directory.

Would not have thought to have mentioned that, or that it would even be the piece of the puzzle that made a difference. Way to go Julie.

Our event is finished now, attendees simply printed the browser version, and that worked out just fine. Minor issue or not, kudos on your persistence to resolve this Lou.

Hi … yup, ditto that. The good news though, is that the error messages are gone that I was getting before. So at least the PDF version is back, which I’ll take any day over error messages. At this point, the event is tomorrow, so I’m no longer concerned about this. And of course they can just print out the browser version of the tickets. Always good to have options and backups.

But to help Julie and others that may be dealing with this (are we really the only two lucky ones?), figured I’d provide my update and let you know that it worked for nixing the error messages.

Not sure if this will help, but here is what I’m noticing re/ some of the folder structures and files re/ the fonts and locations you are discussing loushou. It appears there are 3 folders with the exact same contents of fonts. Their locations are:

1 – wp-content > plugins > opentickets-community-edition > libs > dompdf > lib > fonts
2 – wp-content > uploads > qsot-dompdf-fonts-(5alphanum)
3 – wp-content > uploads > qsot-dompdf-fonts-(5alphanum)

(where alphanum is a 5 character combo of letters and digits, each different for folders 2 and 3)

There is also a “dompdf_font_family_cache.dist.php” file in each folder.
Could these be interfering with each other in some way? Should one or two of them (the folders) be deleted?

Eg. – if as you say “In a recent update we moved these from living in the plugin directory to living in the uploads dir, so that you can add to the fonts if needed, …“
Would that mean I could delete folders 1 and 2 (or 1 and 3) mentioned above?

Also in the “wp-content > uploads > ” folder are two sub-folders “qsot-cache-(10alphanum)” with the same file in it. I believe one was a copy I made before deactivating/reactivating.
I suppose it can be deleted.

Hey Lou,

Thanks for the clarification. Good to know I wasn’t missing something. That being said, it’s always more appreciated when information like that is available from the beginning instead of appearing to be sneaking stuff in and having users figure it out later by accident and after it’s too late to switch if one has already put a lot of time into adopting and using it. But as you point out, it’s customisable (it is open source after all), so that is also appreciated.

Re/ wishing to “get OT’s name out there”. That’s certainly understandable, and I have no issue with that. And as much as I may wish for everything to be private/white labelled and/or no-name generic, another part always wonders how everybody is able to put so much free time and effort into developing all of their free products and projects, let alone keep everything up to date!

Kudos on a great product … and to your high standard of support. It’s uncommonly detailed and responsive. Thanks!

Hi,

I was having the same problem with the PDF showing in the manner described by juliepayne76. Followed your steps loushou, and first checked the settings permissions on the folder, it was at 755, changed it to 775. Tried downloading the PDF, no difference. Then tried renaming the original qsot-cache-alphanumeric to qsot-cache-alphanumeric-Original. Then deactivated and then reactivated OT. Logged back in w/ Dreamweaver and checked, and yes there was a new folder w/ the same name (without the “-Original” suffix of course). And it contains the same file in it with the same alpha-numeric name.

Also checked and changed its settings from 755 to 775. There were also 2 new folders: qsot-dompdf-fonts-0abe4, and qsot-dompdf-fonts-5610d. Both contained 17 php and afm files.

Refreshed the View Ticket page (still the same, displays fine … almost. (See Issue2 next re/ branding display) and then clicked on the Download PDF link again. This time, no PDF file at all, but rather the following error messages:

Warning: require_once(/home/name/public_html/domain/subfolder/wp-content/plugins/opentickets-community-edition/libs/dompdf/lib/fonts/dompdf_font_family_cache.dist.php): failed to open stream: No such file or directory in /home/name/public_html/domain/subfolder/wp-content/plugins/opentickets-community-edition/libs/dompdf/include/font_metrics.cls.php on line 233

and

Fatal error: require_once(): Failed opening required ‘/home/name/public_html/domain/subfolder/wp-content/plugins/opentickets-community-edition/libs/dompdf/lib/fonts/dompdf_font_family_cache.dist.php’ (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/name/public_html/domain/subfolder/wp-content/plugins/opentickets-community-edition/libs/dompdf/include/font_metrics.cls.php on line 233

So, downloaded that file (font_metrics.cls.php) and found line 233 and it says:

$dist_fonts = require_once DOMPDF_DIR . “/lib/fonts/dompdf_font_family_cache.dist.php”;

I have a “…wp-content/plugins/opentickets-community-edition/libs/dompdf/lib/fonts/” folder.

Not being a coder, don’t know what this means so don’t want to touch it and mess anything else up. Is it just some coding here that needs to be changed/fixed/added?

Or do I just need to use notepad or DW to create a blank/empty php file named dompdf_font_family_cache.php” and upload into the fonts folder? And create any necessary permission settings?

What would be the next step?

Its late, so I hope this is making sense. The site is now live, so need a fix for this quickly. In the meantime, is there a way in WooCommerce of OT to put ticket sales on hold while troubleshooting an issue? Maybe put up a “Holding Pattern” message of some sort? eg. – The Ticket Store is currently undergoing some maintenance. Please check back soon (or a set time).

Solved

You may disregard this one. It was because I was logged into WP as admin at the same time, so it was picking up the data from there. When I log out of WP and visit the site, the field is empty.

Funny how you wrack your brain for so long trying to figure something out, and then discover the answer completely by accident in 5 seconds. (Hand to forehead … “Of couuuuurse” … d’oh!) heh

Hi Tim,

Sooo … I’m assuming I shouldn’t install any other plugins or do anything else on the site until this is resolved right?? Yes, no??

Can you provide any insight or information on what this issue might be and what that line of code refers to?

//@wp_mail($email, __(‘New WordPress Site’), $message);
}
endif;

With the scan results showing a big bright Red X along with the words “Critical” and “Core file” for a WordPress issue, this does not sound good.

Should I uninstall and then reinstall WordFence again? Adjust settings and then run the scan again? I doubt WordFence made any changes to that file, so I’m guessing the problem would still be there, right?

Could the GoodBye Captcha plugin (v1.1.16) have made the change? It was installed just prior to WordFence.

The WF scan mentioned the problem was found at the point where it was “Comparing core WordPress files against originals in repository”. Other than that, everything else was clean.

Hi,

I used the one-click WP install from the Host, and installed both WF and GBC through the WordPress system. No themes installed yet either.