WordPress does some odd things when it comes to managing the DOM elements, especially when it comes to JavaScript and CSS. WordPress has crafted their own creative PHP methodology for getting data from PHP into JavaScript when loading the scripts. This allows for JavaScript variables to be “pre-initialized” when the scripts are first rendered.
Useful for getting a known starting state in JavaScript based on PHP state and logic that has run up to the point that the scripts are loaded.
Not standard AT ALL given today’s single page app and other advanced methodologies just as REST queries, etc. that could do the same job.
Originally all of the SLP settings forms had to be submitted by clicking a save button. This runs a typical form post + full page render… old-school web 1.X style.
Along the way work was done to utilize JavaScript triggers and save data with an onBlur on settings form fields. The tech uses jQuery using an AJAX-type model to send a single form field to the WordPress AJAX processor to manage saving a single field without re-rendering the entire page or sending the entire form.
How It Is Triggered
SLP base plugin’s admin.js initializes and hooks a change_option JS function to any INPUT type field with a quick_save CSS class attached.
var qs_inputs = jQuery('.quick_save').find(':input');
qs_inputs.on('change', function (e) {
change_option(e.currentTarget);
});
qs_inputs.on('blur', function (e) {
var start_val = e.currentTarget.defaultValue;
if (e.currentTarget.value !== start_val) {
change_option(e.currentTarget);
}
});
VVV -enabled vagrant boxes are “ready to go” with real-time xDebug debugging. You’ll need to enable it after you’ve booted the guest OS by getting into the guest via command line.
Boot your vagrant box.
vagrant ssh
Once you are into the guest type…
xdebug_on
The xdebug broadcaster is now enabled for the guest OS. Any time you surf to a guest web page it will broadcast Xdebug data. Your IDE should be able to listen for xdebug publications and associate the local code to the xdebug publication. It may require that you “map” your folder structure from your IDE to the relevant server-named path, for example map ~/MyDrive/vagrant-local/www/wordpress-one/public_html to /srv/www/wordpress-one/public_html for it to associate the code in the IDE to the code in the server broadcast messages.
When forking a repository you are making a new copy of the original source , creating what can become a completely different codebase over time. Often that is not the intention when working on a project ; you typically want your own copy to mess with but need it to be “in alignment” with the main production software, or “upstream”, on a regular basis.
Keeping your fork updated is done by using a secondary remote source on your local git clone of the forked repository. By default git clone creates a single remote with a default name of “origin”. Origin is typically the github or bitbucket copy of the codebase stored via git.
Any git repository can have multiple remotes assigned to them. One of the first things you should do when forking a repo and cloning it to a local box is to setup the “upstream” remote point of reference. I use the graphical git tool Sourcetree to help with this.
After cloning your fork, double-click the repository name in Sourcetree to open the commit browser window. With that window open you can open the Repository | Repository Setting menu. Open the sub-tab for “remotes”, add a new remote, name it “upstream” and put in the git URL that represents the original code repository from where your forked version came.
You can now fetch upstream branches alongside your own. When you want to bring your forked copy “in alignment” with the upstream, checkout the branch you want to have aligned… develop for example… fetch the same branch from upstream, them merge upstream/develop into your origin/develop branch. Push your local develop back to origin/develop and valla — your forked copy is now ‘in alignment” with upstream for that particular branch.
