Andrew

Thank you for your reply, but I am using:

add_filter( 'wpo_wcpdf_paper_format', 'wcpdf_custom_inch_page_size', 10, 2 );
function wcpdf_custom_inch_page_size($paper_format, $template_type) {
    // change the values below
    $width = 9.5; //inches!
    $height = 4.125; //inches!
 
    //convert inches to points
    $paper_format = array( 0, 0, $width * 72, $height * 72 );
 
    return $paper_format;
}

…and somewhere there is a 1.5″ margin being added on. @page does not help, and even if I remove ALL CSS, the issue remains. It seems to still have it’s formatting for the 8.5 x 11 standard letter.

How can I specify a custom margin since I am printing for an envelope? At this point, I can’t get my return address to print because of it.

Additionally, I am looking to only affect the packing slip, but when I replaced the $template_type argument with ‘packing-slip’ it did not work. Do you have any suggestions?

Thank you

• This reply was modified 8 years, 1 month ago by Andrew.

Thanks for the reply Samuel.

If you speak for the majority community, that is fine, but I do disagree, which should also be fine.

Table locking and corruption handling has nothing to do with normalization. In fact, a database in Third-Normal-Form is more prone to table corruption errors, because a corrupted table used in many JOINs breaks the relational restrictions. Meaning that one table failure in a 3NF schema actually can prevent all insertion of any kind, just because the table is inaccessible.

It does though. A single table with many columns utilized more than would be in a normalized relational schema is far more likely to experience locks in concurrency. Should data become corrupt, the entire table will be effected throughout the query, rather than perhaps a single post type being unavailable, in which case the rest of my site will work, while yours may not.

Regarding your mention of many JOINs, I am not saying to over-normalize here, as that would have its own negative affect on queries as well, but reducing the amount of data that is needed to be returned to memory, filtered, sorted and displayed is much more efficient in smaller logical sets.

Consider even Microsoft’s SharePoint, as they have made huge strides in this area. Originally, they imposed a soft limit best practice of list queries below 5000 for this exact reason, as sites became slower, even as intranets.

Blind injection is an uncommmon issue, and discovering table names or even fuzzing most common ones is not difficult either. You don’t secure things by obscuring them. Yes, you can limit damage through those practices, but it’s much better to simply prevent the injection vectors in the first place.

Obscurity is a part of security. Let’s not forget your installation allows for naming the table prefix. When someone Google hacks a community framework, they are looking for common known exploits. When someone runs WPScan in Kali Linux, etc, it too is looking through a common library of attacks. I can manually enact each of these specifically in my penetration testing, but packaged attacks are much more likely, and as a simple example, may be one reason you rename wp-admin. Does that mean it is secure? Of course not, and you should implement access control on it so it is only accessible from approved IP’s, but does that secure it?…no, they can be spoofed, but it is certainly part of the process. The point is, the more obscure, they won’t even no you’re there. On top of that, secure the application, and on top of that, feed them incorrect data during the attack.

Yes, practices like these you mention are important to understand and follow, but they don’t drive growth or adoption rates. That’s not what makes a better publishing tool. The best programmed thing is not always the best user-friendly thing.

If that is the consensus and vision of the community, I am saddened to hear, as it is quite close to reaching the next level. I did not come here to pick a fight, but present a few concerns, and take a peek into your vision.

Regards

• This reply was modified 8 years, 1 month ago by Andrew.
• This reply was modified 8 years, 1 month ago by Andrew.

One more final point. WordPress is amazing, and has the potential to be so much more. Having begun as a blog, it would be unfortunate to see the vision stay small, when some basic core changes (hooks into core functions, wp_query enhancement, and data normalization), could make WordPress an Enterprise Go-To.

Thank you for your reply.
As mentioned, I think it will do for small projects, but it is highly inefficient, wastes memory, and has more room for error.

MySQL can handle tables of over 1 billion records, and for many, that may seem like a lot, but it is a hard limit. My project has just begun, and is over several hundred thousand records. Combine that with version history, and many custom post types, and within 10 years, there will be a serious issue. This is not planning or scaling for the future appropriately.

Aside from that, every select loads into memory, and it is “WRONG” to load data that is not needed.
If you have 10 post types with a common author, and need to filter through all in order to display the posts on an author’s bio, all post data is loaded into memory. Caching, CDN, etc only goes so far, and the proper way is to ONLY query the table containing the data needed, so that my memory utilization is efficient.

Another consideration is table corruption. If my schema is normalized, and data is corrupted in a table, only that table is unavailable and the rest of the site will function. This means, that the base web application should operate independently, with all auxiliary calls separate so that the functionality of the site is not impacted when a query fails to return.

When considering penetration testing, not only is the size of the data once again an issue, but having all the data in a single place or even just a few, is not wise. WP_Posts, WP_Meta, etc. Traversal should be caught functionally and they would need to know what the table names are for blind sql injection.

Lastly, WP_Query is also inefficient in its current implementation, causing multiple unnecessary queries. When a page is loaded, it should use MVC methodology to query data once and return. My first implementation of this project brought in WCK to help fastrack progress, but with the complexity, we had pages initially returning 3000+ queries, taking anywhere from over one minute to load to simply timing out.
Once we discovered the limitation of the structure and hacked the core, we now have a single query resulting in a page load of a 700 millisecond average.

To take it a step further, we have no developed our own API and push the data from the database to JSON for the site to digest. The front end site now no longer touches the wordpress database and is unidirectional. This eliminates possibility of being hacked, and also keeps site efficiency to a maximum.

The point is, other frameworks already do this. Drupal, Laravel, etc are already much more mature than WordPress, and I am only recommending that the community learn from that.

Is there a fix for this as it was posted 1 month ago?

I’m going to try W3 Total Cache.

Thank you. I will give that a try.

I don’t know if you are just trying to get post cred or what, but Googling for someone is rather insulting. If you don’t have anything to add specific to this post, you should just move on to other posts you do have knowledge about. Imagine if support forums were merely full of replies from people who just posted the first Google hit they found, or simply said one of the following: uninstall, reinstall, disable, enable, debug. Come on man.

I am a developer and approaching the issue from that direction. I appreciate your willingness, but I do not believe it applies here. Disabling plugins is a way to identify a conflict yes, but it does not rectify the issue and only confirms the reliance on someone else you need to fix it. I primarly work in SharePoint and .NET systems, and tracing correlation id’s is what I am used to. I am curious if there is a way to “properly” debug in WordPress via PHP best practices, etc. Either way, this post has really gone off on a tangent.

I saw that was your suggestion in your first reply, but that is not an option in this case. At some point I may take a current snapshot and update dev, but there are perhaps other individuals who may be aware of this specific issue, or know how to trace debug, which is more along the lines of what I am looking for. Rather than turning off and throwing out a conflicting plugin, are you familiar with trace debugging and how it could be performed to find the conflict?

Actually, I wouldn’t say it works like a charm. I too have had numerous issues with this plugin, but it is hit and miss. Sometimes the cache regeneration works and other times varying pages result in a blank white page. It has caused a bit of headache since each time it purges and regenerates, I need to walk through the site in a private browser session so I am not mislead by browser cache.

It would be nice to know what causes this unreliability.

deleted

404 Redirection
Akismet
All In One SEO Pack
Anti-spam by CleanTalk
Breadcrumb NavXT
Calls to Action
Call to Action Plugin
Captcha
Custom Permalinks
Digg Digg
Display Widgets
DUPLICATE POST <— yours
Embed Code Generator
Formidable
Formidable Math Captcha
Google XML Sitemaps
MaxA/B
Really Simply CAPTCHA
Redirection – Manage all your 301 redirects and monitor 404 errors
TablePress
Widget Classes
WooSidebars
Wordpress-to-Lead for Salesforce CRM
WordPress Backup to Dropbox
WP Smart Pagination

The Avada theme actually works perfect for me. The menu is very robust in a responsive way.
https://www.monstergrips.com

Hopefully WordPress releases a fix soon.

Oh I see. I tried a different theme and the options became available. That’s too bad.