Support

Account

Forum Replies Created

  • Ok figured out the problem. In case anyone is dealing with similar issues:

    		if ( isset( $query->query_vars['post_type'] ) && ( 'post' === $query->query_vars['post_type'] || is_single() ) ) {
    			$query->set( 'orderby', 'meta_value' );
    			$query->set( 'meta_key', 'event_start' );
    			$query->set( 'order', 'ASC' );
    			$query->set( 'paged', get_query_var( 'paged' ) );
    			$query->set( 'posts_per_page', get_option( 'posts_per_page' ) );
    			$query->set( 'meta_query', array(
    				'relation' => 'AND',
    				array(
    					'key'     => 'event_start',
    					'compare' => '>=',
    					'value'   => date( 'Y-m-d H:i:s', strtotime( '-8 hours' ) ),
    					'type'    => 'DATETIME',
    				),
    			) );
    		}
    		return $query;

    Only paged and pages_per_page had to be added. Now it is working proplery.

  • …and on brief addition. It also happens that if you go on the previous post button that also events/post from the past are shown as well. more or less the entire query i sorted with the code above gets paginated. So more specifically the question would be is it possible to paginate ONLY the shown and sorted posts based in the event_start custom field.

    p.s. tried to update my initial post but somehow it seems impossible meanwhile at least i was unable to find an edit button. :/ there for sorry for the necessary follow up post.

  • Hi @Elliot Condon . There isn’t any format_value in my functions.php. But when i’ve added the double false parameters you’ve suggested all missing fields are shown up again! Thanks!
    But one follow up question. WHY do i have to use false, false in that specific case? I never ran into that before in any of my use cases as well as the get_field documentation on your site ( http://www.advancedcustomfields.com/resources/get_field/ ) isn’t documenting nor suggesting its usage. So what do those false, false actually do? Best regards Ralf

  • remove_filter(‘acf_the_content’, ‘wpautop’);

  • Ok i think i figured things out.

    function last_paragraph( $content ){
      if ( is_page( 222 ) ) {
        return preg_replace('/[\s\S]*\K(<p>)/', '<p class="mytrail">', $content, 1);
      } 
    }
    add_filter('acf_the_content', 'last_paragraph');

    I’ve set the function only to a certain page and on that page it targets only acf fields ( which are in my case only text fields, text areas and wysiwyg fields). Text fields and text areas don’t have any wrapping p tags therefor only wysiwyg fields are targeted. And with that small function it is possible that the user is able to add more paragraphs in each wysiwyg field and still the class is set on the last paragraph of each wysiwyg field.

  • thanks for your reply! i am aware of the :last-child way but i am a bit of reluctant adding a wrapping div just for that purpose to the html markup.

  • For visual configuration purpose i would take a look at the tinymce advanced plugin. and about the font example you’ve asked for i would try something like that (untested)

    function tweek_mce( $init ) {
    	$init['fontsize_formats'] = "8pt 10pt 12pt 14pt 18pt 24pt 36pt";
    	return $init;
    }
    add_filter('tiny_mce_before_init', 'tweek_mce');

    place it inside the functions.php. no acf needed in that particular case. best regards ralf

  • @Elliot Condon uhhhhhh i think i’ve figured out the reason why the “update not available” error showed up. today i’ve updated the specific page with the issue i’ve built online. updated a few plugins and ran again into the problem. updated manually and then tried around a bit again. around other steps i’Ve performed i’ve checked the activation state of the serial number. and well the field was empty. i guess that was the issue. i’ve thought by backing up my local install ( where acf was properly activated ) the activation state would be properly conserved and ported to the live server. πŸ˜‰ well an a bit faulty assumption on my side ;))) damn. i’ll have to wait until the next acf update but i suppose that was the sole reason. just wanted to let you know on a follow up that that was probably the cause of the problem. πŸ˜‰ sorry for the troubles!

  • Hi @Elliot Condon tried today again to update from version 5.0.8 to version 5.0.9 on the remote installation which made problems with previous update and the problem still persists. πŸ™ i still get update package not available. Is there any other way how i might debug things to figure out the root of the issue? also tried to disable all htaccess security measures and leave only the wp related snippet in. nothing helped. :/

  • @elliot i’ve replaced the folder and updated to version 5.0.7 on the site. Today the update to version 5.0.8 showed in the wordpress update dialogue. When i tried to update again the same error “update not available” :((( And there isn’t any php.ini or blocking htaccess possibility left. everything switched off. Is there a way to debug it further?

  • hm yep something permission related i also suspected or something related to the 5.05 version which wasn’t the initial but one between 5.0.5 and 5.0.6. So that lead to the update issues. Cuz i remember i’ve downloaded the official 5.0.6 on my local install and after the update worked again toward 5.0.7. On my remote install which was unable to update i compared the permissions but nothing out of the line grabbed my attention. Anyway i’ve replaced 5.0.5 with 5.0.7 on my remote install. Am curious now if it will work again on the next official update. I will keep the issue/thread open and unsolved till the next official update and give you a feedback then if things are solved now or still persist. Thanks for now.

    p.s. and thanks for the hint that deactivation isn’t necessary. i am always overcautious in that regard afraid to break things. πŸ˜‰

  • and about the manual update. is it the correct procedure to deactivate the plugin replace the plugin folder and then reactivate the plugin again?

  • hm as written in my second to last post i’ve remove the php.ini symlinks from the root plugins directory and all acf subdirectories and it hasn’t helped while without removing the symlinks in another plugin the update was still no problem at all. so i could foreclose the php.ini as the root of the problem. must be something else.

    maybe access rights issues? which are the default right necessary normally? or should i try manually install version 2.07? maybe since the last update was a direct update and download in between official version revisions it might be that there something went wrong?

  • A new update of one of my installed plugins came in. I left the php.ini symlinks on purpose inside the plugin directory and then updated. It worked without any problem. Afterwards i retried the ACF plugin and it failed again. So i could factor out the php.ini symlinks as the cause of the problem imho.

  • hmmm it was possible to update custom post type ui to version 0.8.4 yesterday. On Safari the error was a bit different. Package not available hasn’t showed up. instead the update plugin took felt forever (also for cpt ui). I then clicked on the dashboard again. In the case of cpt ui the plugin was updated anyway in the case of acf never. no matter how long i let the updater work.

    the failing update differs from safari and chrome. safari on the right and chrome on the left.

    https://dl.dropboxusercontent.com/u/8578/chromeleft-safariright.png

    about the things i tried aside. I let the background update tester run. it passes all tests without a fail. i also tried to install a new plugin. that also works.

    i switched on debugging in wp-config but no errors or warnings show up. i tried to add also define( 'FS_METHOD', 'direct'); like a friend suggested but that also hasn’t any effect. i’ve checked the network pane in the chrome dev tools while updating but also no errors showed up. Then i remembered one thing. The site is hosted on 1&1. They don’t allow gzip compression so you have to use zlib. therefor a php.ini file has to be in every folder (also in plugins). They are placed as symlinks to the original in the root. the php.ini contains

    
    zlib.output_compression =1
    zlib.output_compression_level =9
    error_reporting = E_ALL | E_STRICT
    log_errors = On
    display_errors = Off
    error_log = /homepages/4/d54545454545/htdocs/php-errors.log
    

    (i’Ve altered the path of the error_log for demonstration purpose in public here πŸ˜‰ )

    so i’ve deleted every php.ini symlink in the acf folders too as well as the one inside the root of the plugins folder. but still the same effect – the update doesn’t work. Now i am a bit out of ideas how to debug things a bit further. :((( Is it maybe a permissions issue of acf files and folders???? cuz i’ve manually downloaded and replaced the present version (it’s 5.0.5x – you recommended updating manually to fix a few js issues a few days back). Best regards Ralf

  • a brief follow up note. i finally managed to enable php_error.log on the server. But when i retried to update the plugin no errors showed up. :/

  • ok i’ve deactivated the plugin and then replaced it with the new one and then reactivated. Now my described WYSIWYG problem is fixed. The one specific field is working again. Coolio!

    p.s. @Elliot Condon you can drop and forget my mail i’ve sent to your support mail address one or two day ago about the WYSIWYG issue, your hint here already fixed it πŸ™‚ thanks a lot!

  • One methodical question about the replacement. Do i have to deactivate the plugin before replacing and or do i have to switch off mamp in my local dev environment before the replacement? Best regards r.

  • I have the same error message with acf 5.0.5. But in my case one of my WYSIWG fields on a options page isn’t showing any of the regular buttons and the text is inverted to white on a white background. :/

  • Would the following addition to the function make sense? At least it works but would there be a more elegant solution?

    function center_map( map ) {
    	// vars
    	var bounds = new google.maps.LatLngBounds();
     
    	// loop through all markers and create bounds
    	$.each( map.markers, function( i, marker ){
    		var latlng = new google.maps.LatLng( marker.position.lat(), marker.position.lng() );
    		bounds.extend( latlng );
    	});
     
    	// only 1 marker?
    	if (map.markers.length == 0 ) {
          map.setCenter(new google.maps.LatLng(49.45203,11.07675));
          map.setZoom( 12 );
    	}
    	else if( map.markers.length === 1 ) {
    		// set center of map
    	    map.setCenter( bounds.getCenter() );
    	    map.setZoom( 16 );
    	}
    	else
    	{
    		// fit to bounds
    		map.fitBounds( bounds );
    	}
      google.maps.event.addDomListener(window, "resize", function() {
          google.maps.event.trigger(map, "resize");
           map.setCenter( bounds.getCenter() );
      });
    }
  • Hi Elliot, no worries at all. Actually i’ve figured out the root of the problem. It wasn’t a temporary glitch, the defined urls for WP_HOME and WP_SITEURL were the reason.

    I am developing locally with MAMP and Codekit 2. When i’ve used e.g. those settings:

    define('WP_HOME', 'http://192.168.0.198:8888/mysite');
    define('WP_SITEURL', 'http://192.168.0.198:8888/mysite');

    even when i’ve set portforwarding for this ip and port i was unable to access the developed site from remote. But a friend suggested me the following:

    define('WP_HOME', 'http://'.$_SERVER["HTTP_HOST"].'/mysite');
    define('WP_SITEURL', 'http://'.$_SERVER["HTTP_HOST"].'/mysite');

    With those definitions i was able that someone else could access my locally developed site from remote. I think since i’ve changed to those $_SERVER["HTTP_HOST"] definitions other updates worked fine but it was the first update with ACF. Now i know the cause but the why i am not sure. πŸ˜‰ But maybe that helps you to understand my discovered issue better. Should the update basically work with $_SERVER["HTTP_HOST"] or not all and i shall return using local ips? Best regards Ralf

  • hmmm seems that was a bug. I tried again few minutes again. The js part of the code hasn’t changed but it is working now. πŸ˜‰ odd. but glad it is working now πŸ™‚ best regards Ralf

  • Flawless update, integration of all premium plugins, nice new features as well as further polishing and a real surprise about the license upgrade in the end. Overall a big big big THANK YOU to Elliot and everyone else involved! Worth the wait! πŸ™‚

Viewing 25 posts - 1 through 25 (of 47 total)