I'm trying to figure out how to properly format the following site's pages:
http://marchofremembrancehouston.org/march/?page=CiviCRM&q=civicrm/event/register&reset=1&id=25
See how the CiviCRM data is pushed to the top right of the site? I would like the form to fit inside the content area of the theme.
I've already done a lot of research and no one seemed to give a clear answer.
This is a bug in CiviCRM. You're using a WordPress plugin that processes each page's content to create tags for Facebook Open Graph (to populate the blurb and image that goes on your Facebook post when you share the page). The problem is that processing the content triggers CiviCRM to run, and consequently, it prints all the content in the head of the page.
The issue describing this in a little more depth is here:
https://issues.civicrm.org/jira/browse/CRM-14244
The next release of CiviCRM (4.4.5) will contain the fix, but if you're in a hurry to publish the page, here's what you can do:
Go in the files of your site to wp-content/plugins/civicrm/civicrm.php
Scroll down to line 412 or so (depending upon your version) and look for the line saying
public function invoke() {
Add the following lines below it:
if ( !in_the_loop() && !is_admin() && empty($_REQUEST['snippet']) ) {
return;
}
What that says is, if you aren't displaying the main content of the page (running "The Loop"), showing an admin page, or displaying a "snippet" (CiviCRM content that belongs within another page), go back and do nothing. CiviCRM will be invoked again when it's the time to run the actual page content.
For reference, the pull request I made in GitHub to handle this is at https://github.com/civicrm/civicrm-wordpress/pull/36/files, where you can see the end result.
If you're in CiviCRM 4.3 or earlier, you'll want to add those lines to the function civicrm_wp_invoke, inserting them after the following (at or near line 292):
function civicrm_wp_invoke() {
This fix is not complete and breaks chain loading AJAX queries within CiviCRM, e.g. for retrieving state dropdown lists if a country is picked in CiviProfiles. The actual fix should check for this:
if ( !in_the_loop() && !is_admin() && empty($_REQUEST['snippet']) && ($_REQUEST['q'] != "civicrm/ajax/jqState") ) {
return;
}
NOTE: this is not yet fixed in 4.4.5 but adding the above line to wp-content/plugins/civicrm/civicrm.php should allow for the state selection to start working again, otherwise you'll also notice a nasty JavaScript error since the returned value is HTML, but the ajax call expects JSON. Why this sort of bug is not caught and fixed prior to release in a simple automated test, to this day I do not understand.
Related
I use a plugin (Popup Builder) on my WordPress site. Whenever I create a new popup with the plugin, it creates a shortcode for that popup. I want to call on that shortcode from within the theme functions.php file. But I can't seem to get it to work properly.
The shortcode runs only if conditions are met. And in this example it's when a visitor access the site for the first time. I then check for a certain cookie and if that cookie does not exist, the popup will fire up and force the visitor to choose one option from a list of options, and then the cookie will be set with the correct value, once they do.
However I cant seem to find a solution that fires the popup at all. An I also get this notice: Notice: do_shortcode_tag was called incorrectly. Attempting to parse a shortcode without a valid callback:
function check_for_cookies() {
// Check if cookie is already set
if(isset($_COOKIE['tln_valgt_fylke'])) {
// Do this if cookie is set
$string .= 'Hi, and welcome back!' ;
return $string;
} else {
// Do this if the cookie doesn't exist
$shortcode = do_shortcode("[sg_popup id=163]");
return $shortcode;
}
}
add_action('init', 'check_for_cookies');
What am I doing wrong, and what if this is not a good way of accomplishing what I want, then what is?
This is just a guess
But, I think its a timing issue. You are using the init action to hook into another plugins shortcodes. It's possible that plugin has not yet registered it's shortcode via add_shortcode or if it has registered it, it may not have "included" the file that defines the callback for it (for whatever reason).
In fact it seems likely because:
do_shortcode_tag was called incorrectly. Attempting to parse a shortcode without a valid callback
This indicates the shortcode was called and no callback existed for it. This is not a problem with your code per say. But it says that the plugin has not yet loaded the file that contains the callback.
You could test this by hooking into an action that happens later in the execution chain, after you know all plugins have been loaded and initialized. Like even wp_head
Perhaps you could even get away with changing the priority of the hook:
add_action('init', 'check_for_cookies', 20); //default is 10
This way it's triggered at the end of init, but even then it may be too soon. The only real way to know is to look at the code for the plugin and find out when it's registering it's "stuff". An easy way to do that is add this code to the plugins shortcode callback:
try{
throw new \Exception();
}catch(\Exception $e){
die("<pre>{$e->getTraceAsString()}</pre>");
}
This will throw and then catch an exception, and then output the stacktrace. Which may show you exactly where the shortcode is being setup. You'll have to trigger the callback (obviously) for it to work. You can also use print_r(debug_backtrace()) but it's much harder to read IMO.
PS I been doing a lot of WP work lately and I just had an issue with action timing ... lol. That was why I thought of it, I spent the last 2 days refactoring code. In my case I an replacing the add/edit/profile parts of the user system on both the front and back end. It's a sort of subuser plugin. And there is a lot of competing actions related to that if you know what I mean...
I'm using WordPress with Custom Content Types plugin. I have the code in a PHP file which creates a contact form.
The website is http://schools.raci.org.au/competition/ancq/
It was working fine before I migrated it to a new host. I didn't write the original code, so I don't really know how it works.
Here are the relevant files:
Here is the code for the main page: pastebin.com/piaTSVgc
and the code for the form: pastebin.com/xeqsmc5g
here is admin-ajax.php: pastebin.com/eFx2JFJu
here is the function where register_interest_form lives: pastebin.com/knrChkSP
here is functions.php: pastebin.com/hru5LkQR
Thanks in advance!
Its working from.
When we submit form. there is ajax request is been processing and getting 0 in response.
The default response from admin-ajax.php is,
die( '0' );
...by adding your own exit() or die() after returning your desired content prevents the default response from admin-ajax.php being returned as well.
The solution is to add die() to the end of your own ajax function, so you die the script before die('0')
It also generally means that your ajax call has succeeded.
Ultimately, to answer your question, it's meant to work this way. What you are doing by exiting after returning your content is the right thing to do.
details from.
https://wordpress.stackexchange.com/questions/116759/why-does-wordpress-add-0-zero-to-an-ajax-response
I am pulling an RSS feed from a Wordpress site, and it seems to have got stuck retrieving a cached version through the PHP on my site.
Viewing the RSS url via a browser shows ALL of the 8 or so posts that should be showing but DOESN'T show a post that I deleted as a test.
Outputting the raw data from the feed via the PHP (using LastRSS) it's omitting posts that were created yesterday but is still showing the deleted post.
LastRSS gets the feed using fopen():
if ($f = #fopen($rss_url, 'r')) {
$rss_content = '';
while (!feof($f)) {
$rss_content .= fgets($f, 4096);
}
fclose($f);
}
I've not used Worpress or RSS feeds all that much, so any help would be appreciated.
WordPress’ built-in RSS widget is fantastic, but sometimes it doesn’t update often enough.
Luckily, there is a fairly simple solution for that. Just add this code to your functions.php file:
add_filter( 'wp_feed_cache_transient_lifetime',
create_function('$a', 'return 600;') );
As you can see, we are using WordPress’ add_filter() function, which accepts a filter hook, callback function and (optional) priority. The wp_feed_cache_transient_lifetime hook handles the feed’s refresh rates. We’re creating our callback function on the fly using PHP’s create_function() function. It is one line, which returns the refresh rate in seconds. Our refresh rate is set to 10 minutes (600 seconds).
Set the value in seconds according your needs.
It seems that the current way to do this in 2020 is with this code:
function turn_off_feed_caching( $feed ) {
$feed->enable_cache( false );
}
add_action( 'wp_feed_options', 'turn_off_feed_caching' );
However, for me, the thing that actually flushed the cache was simply making a change to one of the articles in the feed.
I was trying to switch between Full Text and Summary modes in the plugin and spent several hours trying things until I just tried editing a post and it worked straight away then.
#bodi0 has the right answer but the code has now been depreciated. The following code uses an anonymous function to achieve the same result:
add_filter('wp_feed_cache_transient_lifetime', function () {
return 0;
});
I'm facing the weirdest issue I've ever seen with PHP. I will try to be really exhaustive because each detail can count.
I have 3 PHP pages, and their HTML is generated using Smarty. They all call session_start() at their top.
the first page can be heavy to load, it displays a big amount of clickable pictures that are previews of PHP complex objects
if a picture is chosen it leads to the second page with a specific URL.This page will generate a PHP object related to the URL info (so this page does not need info from previous page to work. If you copy-paste this URL at anytime it will work). This object will be stored into $_SESSION with a unique id.
the third page is included as an img src in the second page's HTML code (generated with Smarty). This is a PHP page having the object's session id in URL parameter and reading the object's info in $_SESSION, creating it's image preview and turns into an image with header('Content-type: image/jpeg').
To sum up :
heavy first page => second page creating and storing a PHP object into $_SESSION => third page, included in second page's HTML code, searching for this object and creating a preview.
The problem is, sometimes, this third page is trying to load the object in $_SESSION and it's just not there !
Some facts :
the problem never occurs when the second page is loaded as a stand-alone with its own URL
the problem only occurs randomly when the heavy first page starts loading images and we furiously click on one of the first ones to appear
whatever the situation is, if I dump my $_SESSION variables at the very end of the second page I can ALWAYS see the generated object in my session
So it seems that the issue is located between the very end of the second page and the beginning of the third, but all of this related to the activity of the first one !
All I know is that it is linked to a fast navigation between pages.
I've tried almost everything :
session_write_close() everywhere it's possible (at the end of my pages before/after smarty display, then at the beginning before session_start())
add exit() at the end of my scripts
even sleep(1) at the beginning of the third in case session close operation needs more time
Nothing works. I have no more clues ... Maybe Smarty ? Maybe some odd PHP session behaviour named bug #4454 somewhere ?
Thanks a lot in advance for helping me with this.
Edit : piece of code after serialize() chat
/* ===== Page2.php ===== */
/*creating object $card and setting some values ...*/
/*calling the function that gives the card preview*/
$assigns['front'] = $card->getPreviewURL();
/*other stuff ... assign $assigns to smarty ... etc*/
/* ===== Card object class ===== */
function getPreviewURL()
{
$_SESSION['products'][$this->getObjectId()] = serialize($this);
$url = '/page3.php?s='.$this->getObjectId();
return $url;
}
/* ===== Page2.html ===== */
img src="{$front}" alt="toto"
/* ===== Page3.php ===== */
/*getting id value and reading session*/
if(!empty($_GET['s'])) {
session_write_close();
$session = new Session;
if(!empty($_SESSION['products'][$_GET['s']])) {
$product = unserialize($_SESSION['products'][$_GET['s']]);
}
else {
log('$_SESSION[products]['.$_GET['s'].'] does NOT exist');
header("Status: 404 Not Found");
exit;
}
}
and when bug occurs, I get :
page2.php debug log :
Session value : [o20aee110e0853e74da4d17c9b7ab3075]=>O:8:"Postcard":19:{s:4:"tmpl";O:16:"PostcardTemplate":20:{s:2:"id";s:3:"152";s:2:"or";i:0;s:3:"ord";s:2:"14";s:11:"description";s:0:"" ... etc
page3.php debug log :
$_SESSION[products][o20aee110e0853e74da4d17c9b7ab3075] does NOT exist
Probably, the problem is, that PHP tries to unserialize your object but cannot find the class definition.
You can do one of the following two things:
serialize() the object manually before you put it into the session and unserialize() it after you loaded the class definition.
Or: Use autoloading.
I created a few mediawiki custom tags, using the guide found here
http://www.mediawiki.org/wiki/Manual:Tag_extensions
I will post my code below, but the problem is after it hits the first custom tag in the page, it calls it, and prints the response, but does not get anything that comes after it in the wikitext. It seems it just stops parsing the page.
Any Ideas?
if ( defined( 'MW_SUPPORTS_PARSERFIRSTCALLINIT' ) ) {
$wgHooks['ParserFirstCallInit'][] = 'tagregister';
} else { // Otherwise do things the old fashioned way
$wgExtensionFunctions[] = 'tagregister';
}
function tagregister(){
global $wgParser;
$wgParser->setHook('tag1','tag1func');
$wgParser->setHook('tag2','tag2func');
return true;
}
function tag1func($input,$params)
{
return "It called me";
}
function tag2func($input,$params)
{
return "It called me -- 2";
}
Update: #George Mauer -- I have seen that as well, but this does not stop the page from rendering, just the Mediawiki engine from parsing the rest of the wikitext. Its as if hitting the custom function is signaling mediawiki that processing is done. I am in the process of diving into the rabbit hole but was hoping someone else has seen this behavior.
Never used Mediawiki but that sort of problem in my experience is indicative of a PHP error that occurred but was suppressed either with the # operator or because PHP error output to screen is turned off.
I hate to resort to this debugging method but when absolutely and utterly frustrated in PHP I will just start putting echo statements every few lines (always with a marker so I remember to remove them later), to figure out exactly where the error is coming from. Eventually, you'll get to the bottom of the rabbit hole and figure out exactly what the problematic line of code is.
Silly me.
Had to close the tags.
Instead of<tag1> I had to change it to <tag1 /> or <tag1></tag1>
Now all works!