For the following website that I have made: ifrs.site (WordPress site with custom theme, if that's important), there is an overlap of content by the footer when the browser window is not maximised on desktop, or when viewed on mobile. I fixed this overlap issue in the dev environment, but the live website with the same CSS code as the dev website ends up with a worse overlap.
What is the cause in discrepancy? You can see the differences in code at this github repo: https://github.com/keg504/IFRS-Website-theme-files, in the 2 branches dev-files and master. What is on master is what is used on the site currently.
I'm using Local by Flywheel for the dev environment on Windows 10, and the CSS is run using a webpack configuration on nodejs.
Edit: As Aliqua has requested, I've added the wp_enqueue_style function I'm calling to load the CSS: wp_enqueue_style('our-main-styles', get_theme_file_uri('/bundled-assets/styles.ba56d060f11656536bc3.css'));
The part between styles...css changes whenever npm run build is run in the command line
Depending on your design/setup the css could have attached in the source code a ?ver=1.0.0 or similar. Which means if you have made changes but not updated the version it is still recalling the original file from the cache.
Some developers overcome this by setting the enqueue_script() version part of the array to a date() (including time with hour-min-sec) function. This will mean that everytime the page is refreshed the version is different and it wont recall older versions of the css from the cache.
Search your code for the enqueue script line for the css in question and see if you can set date() to the version value.
Refer to https://www.php.net/manual/en/function.date.php for more information.
Update:
Based on your update, you could replace it with something like this.
wp_enqueue_style( 'our-main-styles',
get_theme_file_uri('/bundled-assets/styles.ba56d060f11656536bc3.css'),
array( $parent_style ), // remove if there is no parent style
date("His")
);
Reference wp_enqueue_style - https://developer.wordpress.org/reference/functions/wp_enqueue_style/
Final Thoughts:
Please note, that this answer may in fact not be the actual solution as much as I have tried to identify your issue. Please refer to https://developer.wordpress.org/ to familiarise yourself with the introductory information in relation to wordpress development. If you are going to want to do more changes to your wordpress CMS, you will need a basic understanding of how to make changes. Please focus some of your research to plugin creation, working with child themes, and how to make your own custom functions. Then you will be able to write better questions, and be able to action the answers in the future.
Best of luck with your development.
Related
This issue started occurring today: the menu links stop working intermittently (I try clicking, and nothing happens) and I can only get them to start working again by doing a few refreshes. Then again, after moving around the menu a few times, the links stop working.
I noticed this problem on the localhost and then, to test it, I uploaded the website to a webspace and the problem is still there (also tried two different computers, clearing cache, etc.).
The test page is here: http://toulouse.xardas.lima-city.de/en/
I have deactivated several plugins and tried retracing my steps to see if anything I did today could have caused it (I mainly worked on changing the image sizes on the main page in CSS), but I couldn't find the cause.
I have tried the trick where you re-save the permalinks once with a new structure, and then change them back to what they were again and save. That didn't help.
I'm at a loss.
Your problem its not related to plugins, your website has 2 critical javascript errors that show up on the console and they seem to be disabling your website Javascript:
jquery.min.js is no able to load.
masonry.pkgd.js is not able to load.
Both errors are occurring because WordPress its trying to load them from a local server of yours (127.0.0.1).
Since your website its not on a local server, you need to change the tag that refers to those scripts and update the src to the real address of those libraries.
You can need to make sure that this script:
<script type="text/javascript" src="http://127.0.0.1/wordpress/wp-content/themes/elisabethzeigt-topmenu/js/jquery.min.js"></script>
Gets replaced with this:
<script src="http://toulouse.xardas.lima-city.de/wp-content/themes/elisabethzeigt-topmenu/js/jquery.min.js"></script>
The only thing that was updated was the initial part of the src: "http://toulouse.xardas.lima-city.de/" instead of "http://127.0.0.1/wordpress/".
Remember: You should to the same to the other script tag of the masonry library.
If you don't know how to replace them: just search for "jquery" and "masonry.pkgd.js" in your functions.php file and you will find the lines of code.
There is a chance that you functions.php has a global variable with the path to your website and you can fix the issue updating that variable instead of the scripts.
We were tasked to integrate fuelPHP to run in WordPress Website to gain the advantages these two offers to developers. We've been looking for methods over the internet on how to do it and we came to this site.
We followed all the instructions, Yes, it successfully installed wordpress but failed to integrate with FuelPHP, when we tried to open fuelphp, it returned an error:
Fatal error: Cannot redeclare class Fuel\Core\Autoloader in
C:\xampp\htdocs\game-bootcamp\fuel\core\classes\autoloader.php on line
24.
is there somebody there who successfully do it? Can you give us instructions on how to do it?
Excuse me for answering an old question, however it is not answered anywhere on the internet. This is important question because Wordpress is good for end-users, and Fuel PHP is very fast & good for programmers.
You can integrate Wordpress and Fuel PHP in two ways.
Wordpress to run in Fuel PHP
Fuel PHP to run in Wordpress
The first way
I bet you asked for the second one however you posted a link to tutorial for the first one. I can give you answer only for the second one.
Generally, the first way will be probably painfully, however here is some tip to get you started.
Wordpress Codex - Integrating Wordpress with Your Website
This way you can probably override using Wordpress themes and outputing anything and let the Fuel Request take the lead using Wordpress query functions. It seems as good way to integrate if you want Wordpress panel and Fuel PHP display, I don't think it's good idea at all, but if you want - go for it.
The second way
I wanted to achieve backoffice panel based on Fuel PHP and Wordpress website with the data taken from this backoffice panel with Fuel PHP classess inside Wordpress code.
This way you should leave the Wordpress application routing as it is and take advantage of HMVC pattern of Fuel PHP.
I have found this one which gave me the overall idea how to make this:
https://github.com/robertosobachi/wp-fuel-framework
Step #1 - Wordpress basics
Do not modify Wordpress core. Do not modify Wordpress themes. Either create your own child theme or your own theme. If you want to make everything right - you should create Wordpress plugin for that.
You can then integrate Fuel PHP in functions.php file, however the best way is to create your own theme with Sidebar (Widget) Areas and create plugin which will make use of either theme-defined sidebars, defined PHP functions or/and shortcodes.
In your theme/plugin code you need to load Fuel PHP. You can make it on Widget Init action however it's your choice where to load this exactly.
The code below is for Fuel PHP 1.8, however you can probably go with further versions following this steps.
Step #2 - Fuel index.php duplication
Let's assume following folder structure:
/apache/www/backoffice/ (with fuel and public folders)
/apache/www/wordpress/ (with wordpress)
Open the /apache/www/backoffice/public/index.php and see what's going there. The first thing to do is to duplicate the steps Fuel is doing but within Wordpress. Every code I paste should be placed in your Wordpress plugin or theme (as you like). ABSPATH is defined by Wordpress.
$dir = realpath(ABSPATH.'../backoffice/public');
define('DOCROOT', $dir.DIRECTORY_SEPARATOR);
define('APPPATH', realpath($dir.'/../fuel/app/').DIRECTORY_SEPARATOR);
define('PKGPATH', realpath($dir.'/../fuel/packages/').DIRECTORY_SEPARATOR);
define('COREPATH', realpath($dir.'/../fuel/core/').DIRECTORY_SEPARATOR);
Now you can copy the rest of Fuel index.php:
defined('FUEL_START_TIME') or define('FUEL_START_TIME', microtime(true));
defined('FUEL_START_MEM') or define('FUEL_START_MEM', memory_get_usage());
// Load in the Fuel autoloader
if ( ! file_exists(COREPATH.'classes'.DIRECTORY_SEPARATOR.'autoloader.php'))
{
die('No composer autoloader found. Please run composer to install the FuelPHP framework dependencies first!');
}
// Activate the framework class autoloader
require COREPATH.'classes'.DIRECTORY_SEPARATOR.'autoloader.php';
class_alias('Fuel\\Core\\Autoloader', 'Autoloader');
The rest of the index.php code is based on the Request class which we don't want to use now, so do not copy it. However you can see the line:
require APPPATH.'bootstrap.php';
Let's go to that file. Inside in the first lines you can find:
require COREPATH.'bootstrap.php';
So let's start with this one first.
Step #3 - CORE bootstrap.php duplication
It is save and probably required to copy the first lines of this file.
define('DS', DIRECTORY_SEPARATOR);
define('CRLF', chr(13).chr(10));
define('MBSTRING', function_exists('mb_get_info'));
require COREPATH.'base.php';
setup_autoloader();
get_composer();
Do not copy register_shutdown_function, set_exception_handler, set_error_handler unless you know what you are doing. You probably want to use default Wordpress error handling. Use fuel error handling is very tricky to do however if you want - try it. Personally I gave up.
You have to copy the setup_autoloader and get_composer functions. They are long, but they are crucial to make this integration works. I didn't copy it here to make this post more readable.
Step #4 - APP bootstrap.php duplication
Hope you are not lost yet. We have to go back to APP bootstrap.php and copy this lines.
\Autoloader::add_classes(array(
// Add classes you want to override here
// Example: 'View' => APPPATH.'classes/view.php',
));
\Autoloader::register();
\Fuel::$env = \Arr::get($_SERVER, 'FUEL_ENV', \Arr::get($_ENV, 'FUEL_ENV', \Fuel::DEVELOPMENT));
\Fuel::init('config.php');
I am not sure if Fuel::init is so much important to load, haven't tested it yet. However you must be aware that Fuel::init method is setting some global variables like date_default_timezone_set (according to the config) so it can somehow modify the way Wordpress is working.
So, that's it. Now within your plugin/theme file you can make HMVC requests to your Controllers. You can access your models, Fuel classes - just like you used to do. Do not forget to activate your plugin in Wordpress.
$widget = Request::forge('widget/sample')->execute();
You have to be aware that it's not echoing the view automatically - see Fuel documentation for more.
Here is the pastebin: link
EDIT:
There is another tricky part I found using sessions: when you are using only HMVC requests the Session is not saving so you have to call Session::write() manually within your code (wherever you want to save it). You will have to call it before the Wordpress output is made so try to hook to init or just place it in your main plugin file.
EDIT #2:
There is yet another tricky part with Wordpress auto "magic_quotes_gpc" feature. Do not simply turn this off by $_POST = stripslashes_deep($_POST); as it may break Wordpress security. The better way is to stripslashes right before adding to the database within your Fuel code and only those variables that you need to strip.
I am using FitVid in my theme and all is well except for a specific site that was migrated from Drupal. FitVid works fine with objects and embeds but not iframes, and only on this particular site. The only difference I can find is that a random <noscript> is inserted after the iframe.
Here is an example of the non working iframe on the problematic site:
http://wp.alimomeni.net/project/animal-warmth-no-64/
And here is an example with a different database where no shows up:
http://wpfolio.notlaura.com/project/pollen-from-hazelnut/
Why is FitVid not working for iframes that particular site install? I am concerned there is an issue with the database itself as the content was pretty messy after the initial migration and I haven't been able to replicate the issue anywhere else.
Any help greatly appreciated!
P.S. I have tried other responsive video plugins and my own jQuery to wrap the iframes.
edit
Since the first "problem"'s being resolved, here's another try:
I saw that your fitVid-JS is different from mine. Maybe on purpose, but maybe it's outdated somehow. Here's what I am using in my script which works - for me:
(function($){$.fn.fitVids=function(options){var settings={customSelector:null};if(!document.getElementById("fit-vids-style")){var div=document.createElement("div"),ref=document.getElementsByTagName("base")[0]||document.getElementsByTagName("script")[0],cssStyles="<style>.fluid-width-video-wrapper{width:100%;position:relative;padding:0;}.fluid-width-video-wrapper iframe,.fluid-width-video-wrapper object,.fluid-width-video-wrapper embed {position:absolute;top:0;left:0;width:100%;height:100%;}</style>";
div.className="fit-vids-style";div.id="fit-vids-style";div.style.display="none";div.innerHTML=cssStyles;ref.parentNode.insertBefore(div,ref)}if(options)$.extend(settings,options);return this.each(function(){var selectors=["iframe[src*='player.vimeo.com']","iframe[src*='youtube.com']","iframe[src*='youtube-nocookie.com']","iframe[src*='kickstarter.com'][src*='video.html']","object","embed"];if(settings.customSelector)selectors.push(settings.customSelector);var $allVideos=$(this).find(selectors.join(","));
$allVideos=$allVideos.not("object object");$allVideos.each(function(){var $this=$(this);if(this.tagName.toLowerCase()==="embed"&&$this.parent("object").length||$this.parent(".fluid-width-video-wrapper").length)return;var height=this.tagName.toLowerCase()==="object"||$this.attr("height")&&!isNaN(parseInt($this.attr("height"),10))?parseInt($this.attr("height"),10):$this.height(),width=!isNaN(parseInt($this.attr("width"),10))?parseInt($this.attr("width"),10):$this.width(),aspectRatio=height/width;if(!$this.attr("id")){var videoID=
"fitvid"+Math.floor(Math.random()*999999);$this.attr("id",videoID)}$this.wrap('<div class="fluid-width-video-wrapper"></div>').parent(".fluid-width-video-wrapper").css("padding-top",aspectRatio*100+"%");$this.removeAttr("height").removeAttr("width").css({'width': '', 'height': ''})})})}})(window.jQuery||window.Zepto);
Sry for minified code, I only copy & pasted it.
I'm pretty sure I've read somewhere that you can actually move the main plugin *.php file to somewhere else (I assume under your theme directory) to have it safe in case you made changes to it and your plugin updates. I tried Google but I can't find anything. Google page with good results will suffice.
I've just experienced a situation where my 2 plugins which had its layout changed and accommodated my needs and I want to make sure it doesn't happen again. Apart from having the main file in another location, is there a way to move along any CSS and JS files as well?
In Concrete5 CMS there is a nice way of doing this, by creating a new folder inside a block of an addon (may be regarded as a WP plugin), inside of which you can create copies of main file, any CSS and JS files and then you can simply edit them and choose that template for a page location you are using that block in.
I assume there is no such thing in Wordpress but how close can I get?
UPDATE: I found where I applied that advice on creating a new instance of the file then moving it to the theme directory.
The plugin in question was HL-Twitter. These are the plugin files:
admin.php
archive.php
functions.php
hl_twitter.php
hl_twitter_archive.php
hl_twitter_widget.php
import.php
widget.php
Now, this is the top contents (commented out) of the hl_twitter_widget.php:
Widget Theme for HL Twitter
To change this theme, copy hl_twitter_widget.php
to your current theme folder, do not edit this
file directly.
Available Properties:
$before_widget
$after_widget
$before_title
$after_title
$widget_title
$show_avatars
$show_powered_by
$num_tweets: how many tweets to show
$tweets: array of $tweet
$tweet: object representing a tweet
$tweet->twitter_tweet_id
$tweet->tweet
$tweet->lat
$tweet->lon
$tweet->created
$tweet->reply_tweet_id
$tweet->reply_screen_name
$tweet->source
$tweet->screen_name
$tweet->name
$tweet->avatar
$user: represents the Twitter user (ONLY SET IF SHOWING A SINGLE USERS TWEETS!)
$user->twitter_user_id
$user->screen_name
$user->name
$user->num_friends
$user->num_followers
$user->num_tweets
$user->registered
$user->url
$user->description
$user->location
$user->avatar
So I was wrong about copying the main file (in this case hl_twitter.php), but still - this enabled me to edit the file outside the plugin directory and the system somehow checks for its existence and picks it up if exists.
If this behavior something that is natively supported by Wordpress or it has been integrated in the plugin itself?
With themes, Wordpress has a concept of "child themes" which allows exactly that: to keep changes separate from main theme, in case it changes.
I haven't yet found a way to do this with plugins.
I'm using a few tactics myself:
I bump plugin version to a very high number like 99.9. This way Wordpress won't ever update the plugin.
Store my plugins in version control (i use git, but it doesnt matter), this allows you to update the plugin, run the 'diff' tool and see what changes happend. If you don't like you just revert like it would be a bad code you've written. But this approach requires a bit of skill.
Are you talking about running parts of a modified 3rd party plugin, and an updated version, at the same time?
That's not going to be possible. There is no magical method of "preserve my changes and transfer them into the new version automatically". The way to go here is doing a diff between the edited version and the update, and integrating the changes in the actual source files.
The bottom line is, if you manually edit a third party plugin, you're in for manual review (and possibly rework) once an update takes place. That's why it's usually not a good idea to extensively modify third party plugins.
Well in fact, yes! There is some kind of way.
You have to remove the to be modificated plugin's original actions/filters and then add your altereted actions/filters.
If the desired plugin is even coded in OOP you can just inherit the whole class and rewrite the wanted functions (oh sorry: "methods". we're talking about OOP ;) ). Instantiate your inherited class and rest as above.
Maybe there are better ways! I already search for a method so that the original class won't even get loaded but our altered one instead but I'm no John Carmack.
I was experiencing an odd problem where blocks were not showing up on a site. After a lot of spelunking I have found that block.tpl.php is not getting called/discovered.
Looking at the suggestions that the theme engine is trying to find it looks like the most general template it will look for is block-MODULE.tpl.php - ie if I set up symlinks for block-block.tpl.php, block-views.tpl.php etc then the content will show.
It just won't find block.tpl.php
So I can kind of make the problem go away, but I'd feel a lot better if I could fix it properly.
Anyone know why (or where) this would happen?
This is drupal 6, with a zen subtheme. zen is in sites/all/themes/ the subtheme is in sites/example.com/themes/.
(it does seem to be finding page.tpl)
PHPTemplate will find the more general templates (e.g. block.tpl.php): you can confirm this behavior by looking in the themes/garland folder which has its own block.tpl.php.
The most common reason for the template engine ignoring your template overrides is because the theme registry has not been reset. You can reset it by going to Site Configuration -> Performance and clicking Clear cached data at the bottom of the page.
Also make sure you've gone through and followed the instructions for sub-theming exactly: missing a step can produce unexpected results:
How to build your own sub-theme (6.x-2.x)
How to build your own sub-theme (6.x-1.x)
Turns out I had added a to the hook_theme() function in template.php for blocks that was pointing to a different location and confusing everyone.
Why I did that is lost to history, but it seems to server no useful purpose.
there should be a version of block.tpl.php in both the theme and subtheme directories.