Solinx

Hi Chouby,

Many thanks for the quick reply.

I’ve actually got some promising results on a solution I’ve been working on today:

public function parse_query($query)
	{
		if ($query->query_vars['override_singular']) {
			$query->is_singular = false;
		}
		if ( ! $query->is_main_query()) {
			return;
		}

		if (
			isset($query->query_vars['pagename']) &&
			! empty($query->query_vars['pagename'])
		) {
			// Perform query
			$args = array(
				'post_type' 		=> 'page',
				'override_singular'	=> true,
				'name' 				=> $query->query_vars['pagename'],
				'posts_per_page'   	=> 1,
				'suppress_filters' 	=> true
			);
			$the_query = new WP_Query();
			$the_query->query($args);

			if (isset($the_query->post) && $the_query->post instanceof WP_Post) {
				unset($query->queried_object);
				unset($query->queried_object_id);
				$query->queried_object = $the_query->post;
				$query->queried_object_id = $the_query->post->ID;
			}
		}
		return $query;
	}

The trick is to unset the queried object and set is_singular to false, which prevents that the tax_query that is set by your plugin is ignored.

This solution is a raw draft. I’ve yet to figure out why the urls in your language menu are broken on the front end (but not in admin). Also, I’ve only tested it with regular pages and thus far found out it does not work with child pages. Finally, it would be more efficient to change the actual main query string, which is something I’ll look into tomorrow.

Cheers,
Wouter

You’re welcome. And thanks again for taking the time to make these changes.

Cheers,
Wouter van Dam

Thanks.

I’ve done a few quick tests and everything appears to work as expected.

And I’ve also taken a look at the code. The code in ‘admin-filters-column’ and ‘admin-filter-post.php’ looks good, but I noticed that the ‘frontend-filters.php’ code is unchanged. Could you apply the same changes in that file as you did in ‘admin-filter-post.php’?

Cheers,
Wouter van Dam

Hi Chouby,

Thanks for considering the proposal.

Good point about checking for user owned posts. You’ll want to check with current_user_can($post_type_object->cap->edit_post, $post_id) to stay compatible with custom post types.

In my second post I was a bit too quick with the copy&paste – I copied from the original file. Taking your feedback into account the capability statement should have been:
if ($updated && !current_user_can($post_type_object->cap->edit_post, $post_id)) || (!$updated && !current_user_can($post_type_object->cap->create_posts))
The $updated value provided by the ‘save_post’ hook is true when a post is being edited, and false when a post is being created.

And also a good point about not needing to check for those term permissions. It actually highlights an upcoming problem with my current project. I’ll need to figure out a way to limit a custom role to only being able to edit their own tags.

Thanks again for looking into this.

Cheers,
Wouter van Dam

Came across another problem concerning user capabilities.

In both admin-filter-post.php and frontend-filter.php you hook in on the ‘save_post’ action. In the method that you apply you check for both the edit_posts and create_posts capabilities, without checking whether the post that is being saved is new or not.

This can easily be fixed by applying the following code.

First change the param count when you register the ‘save_post’ action.
add_action('save_post', array(&$this, 'save_post'), 200, 3);

Then modify the ‘save_post’ methods.
1. Add ‘$updated’ as 3rd argument to the method.
2. Change the capability if statement into the following:
if (!current_user_can($post_type_object->cap->edit_posts) || !current_user_can($post_type_object->cap->create_posts))

We’d appreciate it if could also include these modifications into the next release. Thanks in advance!

Regards,
Wouter van Dam

You could put the code at the bottom of the functions.php file of your theme.

Be sure to remove “public” from “public function …”, unless you know what PHP Classes are and will place the code within a class.

@maplewang:
No, this is specifically for the polylang plugin.

Hi Greg,

Thanks for including this already!

Regards,
Wouter

Thanks, that will be much appreciated!

Before posting I tried to think of alternative solutions, but all of them probably involve quite a bit of time.

The one I favor involves creating an actual css file per page that uses the PageBuilder, to be generated when you save the PageBuilder page. You can avoid generating a ton of files by generating a hash for each css file based on contents. You could then use that hash as filename and store the hash as a meta field of the page.

This solution would be efficient for visitors, and allow you to use the regular enqueue system as it is meant to be used, but I expect it will involve a bit more work than just putting back the old solution as an option.

Cheers,
Wouter

@greg

The slowdown registered by the P3 Plugin Profiler could well be related to the way you load CSS.

Check this topic for two solutions to get polylang and pagebuilder working together:
https://www.ads-software.com/support/topic/polylang-multilingual-plugin-incompatibility

You’re welcome.

Here is the code we’re using now to specifically filter out the meta field for the page builder.

/**
	 * Filter the meta values that are synced between translated posts
	 *
	 * @since	18 Oct 2013
	 * @version	1.0
	 * @param	$metas 	an array of post metas
	 * @param	$sync 	false when copying metas to a new translation, true when synchronizing translations
	 * @return	Filtered array of post metas
	 */
	public function filter_copied_post_metas($metas, $sync)
	{
		if ($sync) {
			if(($key = array_search('panels_data', $metas)) !== false) {
			    unset($metas[$key]);
			}
		}

		return $metas;
	}
add_filter('pll_the_languages', 'filter_the_languages', 10, 2)

Hi Greg,

I suspect something similar is happening for select boxes with the ‘multiple’ parameter.

The widget I wrote behaves as expected in a regular sidebar, but in the page builder the array is reduced to one selected option.

Do you think it is related? And if so, do you have plans for fixing this issue?

Regards,
Wouter

Hi Esal,

We ran into exactly the same problem today. Fortunately there is a fix. The PageBuilder stores its information in custom fields, so the easy solution is to go to the polylang settings panel and turn off synchronization for custom fields.

If you have other custom fields attached to your posts you will need to do some more work, to manually sync those fields you added yourself. This requires hooking in on filters from polylang.

Alternatively you may be able to explicitly prevent the page_builder custom field(s) from being synchronized. We’re probably going to give that a try later today.

Regards,
Wouter van Dam

Hi Greg,

Thank you for looking into this. What you describe sounds like a great solution.

Cheers,
Wouter

Solved my own issue. By disabling the “Redirect caching” option… It really was as simple as that.

I still like this plugin, but after looking at the code structure and seeing all the minor errors it produces when you turn on debug mode, I’ve got to be honest and say there is room for improvement there. I’m swamped with work now, but (if I’m keeping this plugin around) I’ll be sure to have a look at these issues eventually.

From what I can tell it still beats the heavier caching plugins on low resource setups, and to be fair I’ve not checked to see how many errors these heavier plugins produce.

Edit:
The option fixed the ‘redirect loop’ issue. But then it did not cache the paged archives and categories. To fix this I had to comment out line 290 in wp-content/plugins/hyper-cache/plugin.php. So far everything is working great.