Menu
WordPress Blog Posting Trending Search Troubleshooting Tutorial
It can be tempting to put down “revisit to functionality” oddities as one off issues not to be concerned about. But this is not always such a good strategy, and is a bit of an arrogant strategy, because it is like you (as programmer) saying …
My code has no bugs
… an out and out lie from whoever says this. Take a scenario to its extreme (eg. natural disaster disabling the hardware behind the software), and such a statement can’t be justified.
Even if an issue can’t be examined there and then, even a repeat of the operation is worth it, as a first check of the optimistic proposition above. If no time now to fix a repeat problem, at least note it down for a revisit, we recommend.
And so we have an example of such an occurrence for us, revisiting the functionality of WordPress Blog Posting Trending Search Primer Tutorial, in (relatively) recent times.
Before today’s changes (believe me) we were getting a blank webpage screen when we visited thechanged trending_on_wordpress
php live
run link.
Fast forward to today’s troubleshooting work. We find “troubleshooting” and “debugging” requires a shift of mindset, often. This is because it can be tempting to see all this as “sideways” progress. It is a bit, but it is also a learning chance for you. Such as, at the end of it … “am I susceptible to this type of coding weakness into the future?”. That different mindset, for us, is to be as systematic and logical as you can be.
To help be logical, with web application work, we find the modern non-mobile web browser Web Inspectors invaluable, even with PHP work (as PHP begets HTML, after all … but not always the total “debugging package” (that PHPStorm would more likely to be)). With this in mind, even with the “window.open” popup window scenario of us being …
- in Google Chrome web browser visit this blog’s All Posts (menu) -> Trending Searches on this Blog submenu … getting us to …
- Trending Searches webpage … blank … aaaaarrrrggggh! … so … dooooonnnnn’t pannnnnnnic …
- View -> Developer -> Developer Tools
- Click “Console” tab … getting us the error …
Uncaught SyntaxError: Unexpected identifier trending_on_wordpress.php:25
… and here, we must warn that “25” is not necessarily a PHP code line number, but rather a “resultant HTML webpage” line number … so … - Click that trending_on_wordpress.php:25 link to get to real code of interest … and we note that nothing appears wrong with the left hand side of (the PHP to HTML result of) …
var thecwords=\"" . str_replace("\n"," ",$theswords) . "\"; \n
… that being (up to right hand edge of Web Inspector webpage, for us) …
var thecwords=" PHP PHP Python Overlay WordPress Avatar WordPress PHP Python Python PHP Python WordPress PHP Google@!@Chart Javascript jQuery Reveal Overlay Javascript XML HTML PDF MySql ...
… but that is when you should scroll over to the cursor position of the issue off to the right, to where we see the problem with (later, over to the right) …
... Power@#!@Management "Inhouse@!@Slideshow" Inhouse Inhouse ... ... ... ... ";
… aaaahhhhh … a data related problem we hadn’t catered for (that perhaps we could have envisaged, better, at the time of writing the code, indeed) … remedied by changing that PHP line to …
- better PHP codeline …
var thecwords=\"" . str_replace('"','\"',str_replace("\n"," ",$theswords)) . "\"; \n
… fixing the (unescaped) double quote within a double quote (“Uncaught SyntaxError: Unexpected identifier”) PHP variable definition bug
… a lot of which you can see play out with today’s tutorial picture.
Especially with the serverside languages such as PHP that can “infill” variables via data stored away in an independent datastore, data related bugs like this can be avoided best by programmers who remain sceptical and questioning regarding the implications of the “power and variety of data” … a life’s work, we figure?!
Previous relevant WordPress Blog Posting Trending Search Primer Tutorial is shown below.
WordPress Blog Posting Trending Search Primer Tutorial
We wanted to share some search information used by other users of this blog, in case what other people are searching for, might be the thing you didn’t know that you wanted to search for. This is human nature. We learn from each other, and that is why “trending” is such a big word in I.T. these days.
We’re going to start, limiting the pool of information this functionality reads its information from, to those new “Title RE” (ie. regular searches of Blog Posting Title) searches we introduced when we presented WordPress Blog Posting Title Regular Expression Search Primer Tutorial.
So there are two parts to this functionality, those being …
- the collection of “Title RE” search information to the web server … we pick a flat file source of that data … which is then read by …
- reporting of trending “Title RE” searches made at the blog, reading that dynamically changing pool of “Title RE” search data
… consecutively handled in …
- (good ol’) header.php of WordPress theme TwentyTen … to gather data … as per …
function asksr() {
var av=prompt('Blog Posting Titles matching Regular Expression?', document.getElementById('s').value);
if (av != null) {
if (av != '') {
if (av.substring(0,1) == '.') {
location.href='//www.rjmprogramming.com.au/itblog/match/' + encodeURIComponent(String.fromCharCode(92) + av + 'fRoM');
} else {
location.href='//www.rjmprogramming.com.au/itblog/match/' + encodeURIComponent(av + 'fRoM');
}
}
}
}
… helping out mapperphp, that changed in thisway to accommodate along with the new … - trending_on_wordpressphp … with its liverun for this blog’s trends … PHP to report on those trends via a Javascript alert box window and Google Chart Histogram Chart … thanks to this very useful link regarding some of the suavest logic used in it
So one last thing is, where do we “store” this functionality? We thought, put it on the “All Posts” main menu as a submenu option, so that it becomes a piece of functionality only causing web server processing activity loading when a user chooses to ask for this.
Previous relevant WordPress Blog Posting Title Regular Expression Search .htaccess Tutorial is shown below.
WordPress Blog Posting Title Regular Expression Search .htaccess Tutorial
As we pick up from yesterday’s WordPress Blog Posting Title Regular Expression Search Primer Tutorial with explaining the functionality behind our new WordPress Blog Title Regular Expression Search functionality you can …
- take a peak at the URL created during its use on the way .. via (header.php’s Javascript HTML select element onchange event logic) …
function asksr() {
var av=prompt('Blog Posting Titles matching Regular Expression?', document.getElementById('s').value);
if (av != null) {
if (av != '') {
if (av.substring(0,1) == '.') {
location.href='//www.rjmprogramming.com.au/itblog/match/' + encodeURIComponent(String.fromCharCode(92) + av);
} else {
location.href='//www.rjmprogramming.com.au/itblog/match/' + encodeURIComponent(av);
}
}
}
}
… to showing the top of the page HTML select element dropdown … or, be a smart Alec and … - take a peak at the second last word of today’s blog posting title
… to get the hint that, today (as with WordPress 4.1.1’s WordPress Blog Posting Title Regular Expression Search .htaccess Tutorial), we have on our hands an example of the use of an Apache web server .htaccess approach to URL processing and navigation control.
The use of .htaccess files in Apache web server environments is quite a big subject, and for more far reaching detail than what we provide today, we would like to direct you towards this useful webpage (and while you are at it, read about our upgrade from WordPress 3.0.3 to WordPress 4.1.1 and some .htaccess work via the blog posting thread ending at WordPress Upgrade Crontab Curl Tutorial). What can you do within a subject area you want to learn? Stay informed, read, consult or … take leads from others, and by so doing, know more the specifics of what you need to read and research, we hope?! So it was with us, taking leads off something we’d done earlier taking leads off what WordPress had shown us was possible in that ‘earlier on’ period.
We find .htaccess work very satisfying, as it is making URLs look less ‘manufactured’ … though, today, it must be admitted, an interim URL we use obfuscates that elegance a fair bit. Nonetheless, having these ‘magical’ URLs with no ? nor & (quite often) doing these strange things happens (with .htaccess work) because … the .htaccess mapped URL’s PHP or HTML code is passed the original URL and it behoves that mapped code to make use of that fact … in other words, the address bar URL will still be the elegant non-?-& URL that the PHP or HTML’s document.URL sees and can ‘chameleon fashion’ change its guise, according to … and we go and ‘change the guise’ to a self recalling arrangement of a URL that does contain a ? and is thus available to the PHP we write in the global variable $_GET[‘pm’] as per (hint: mapper.php’s) code snippet …
if (isset($_GET['pm'])) { // recall scenario
// populate the HTML select element dropdown via $_GET['pm'] ... rest assured, PHP's eregi is used in this logic
} else { // got here via .htaccess in //www.rjmprogramming.com.au/itblog/match/ web server directory
// recall yourself via location.href='//www.rjmprogramming.com.au/itblog/match/mapper.php?pm=' + document.URL.replace(''//www.rjmprogramming.com.au/itblog/match/', '');
}
Okay, so did you “take a peak at the URL created during its use on the way to showing the top of the page HTML select element dropdown”? If so you’d have found a sequence of URLs, the first two really hard to get a glimpse of …
- //www.rjmprogramming.com.au/itblog/match/Python
- //www.rjmprogramming.com.au/itblog/match/mapper.php
- //www.rjmprogramming.com.au/itblog/match/mapper.php?pm=Python
… because it all happens so fast, and we’ve helped you out in today’s tutorialpicture imagining it happening. But what happens? Well, the URL’s //www.rjmprogramming.com.au/itblog/match/ underlying web server directory has a special file, at least to Apache web servers, and it is called .htaccess and for the scenario above it comprises …
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /itblog/match/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /itblog/match/mapper.php [L]
</IfModule>
# END WordPress
… about which you need to see that Apache’s mod_rewrite module needs to be active for this .htaccess file to be noticed and that “RewriteRule . /itblog/match/mapper.php [L]” is the bit that spurs the …
- //www.rjmprogramming.com.au/itblog/match/Python
- //www.rjmprogramming.com.au/itblog/match/mapper.php
… mapping taking place, and is the doing of the .htaccess file, while the rest happens within our homegrown mapperphp where its navigational progression …
- //www.rjmprogramming.com.au/itblog/match/mapper.php
- //www.rjmprogramming.com.au/itblog/match/mapper.php?pm=Python
… can only feasibly be guessed at by mapper.php because the previous “//www.rjmprogramming.com.au/itblog/match/Python” URL is available to it in the Javascript DOM client “document.URL” global … cute, huh?! And, that being the case we know to construct HTML select element dropdown contents based on “Python” and to populate an HTML iframe below with the landing page of the blog, awaiting any user specified instructions.
You may well reason that you don’t have to involve .htaccess Apache methods to get this job done, and you’d be right, but the topic can be extremely useful regarding Apache web servers, like we have at www.rjmprogramming.com.au … and so we thought we’d show you some details here, and we hope you like it.
Did you know?
Were you a blog reader here when we introduced WordPress version 4.1.1 into the equation? Do you recall us making URLs …
… “equate” to the same web (blog) application webpage? Please read the “Did you know?” of WordPress Upgrade Implications Tutorial for more information here, but the gist of making this happen was to place into //www.rjmprogramming.com.au/itblog/ URL’s underlying web server directory the .htaccess file as below …
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /itblog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /ITblog/index.php [L]
</IfModule>
# END WordPress
… which amounts to a very similar concept to today’s mapper.php for our Blog Post Title Regular Expression Searches scenario, and is a lesson in how individual web server directories can have tailored .htaccess functionalities.
Previous relevant WordPress Blog Posting Title Regular Expression Search Primer Tutorial is shown below.
WordPress Blog Posting Title Regular Expression Search Primer Tutorial
One of our chief aims with this blog is to send the user off on a themed ‘thread’ of inquiry. What came, by default with our WordPress TwentyTen themed blog was to categorize via …
- Category
- Tag
- Search (string)
… and then … some time back … sun comes up, sun goes down x 100’s … we allowed a Search (string) arrangement within one of the other two ‘parent’ searches … and today … da da da da da, da da da … we allow a Regular Expression search of Blog Posting titles … because …
- it fits in quite nicely with our long-winded blog posting title regime, which has been designed to tell it like it is … but not great for SEO (you should be warned) … and …
- we’ve always felt that an exploration of a topic like “Python”, for example, will not necessarily fit into a “Category” nor necessarily even a “Tag” scenario nearly as well, for us, as to allow a (Regular Expression) search of Blog Posting Titles for “Python”
… as well as the cute feature that, because it is using PHP Regular Expressions via the eregi method, you could narrow the search via ^Python as an example to ensure Blog Posting Titles have to start with “Python”.
There is a dual purpose to this work, but we’ll just be discussing the “interface” to the WordPress blog today, and detail something else regarding it tomorrow. So for today, we add a new HTML input element type=checkbox next to the blog’s Search input textbox, and off whatever might have been entered as text into that field as the default string for a Javascript prompt window asking of what Blog Posting Title Regular Expression Search they want to perform, and this sends the user to a new webpage consisting of …
- one HTML select element dropdown of matching Blog Posting Titles … under which is …
- one HTML iframe element initially showing the blog’s landing page but ready to be repopulated via any choice the user makes regarding the HTML select element dropdown above … like a television with “top” control
That HTML input element type=checkbox (that you can see in today’s tutorialpicture) is coded (in … you guessed it … good ol’ header.php) as below …
<input title='WordPress Blog Posting Title RegExp search ...' onclick="asksr();" type='checkbox' id='scbtype' value='Title RE'></input><a style='cursor:pointer;text-decoration:underline;' title='WordPress Blog Posting Title RegExp search ...' onclick="asksr();">Title RE</a>
We’ll be taking off from this point explaining more about the architecture behind this functionality tomorrow. But you being here, up at the Search input box you can try out what we mean, to see all this in action. And it may be worth considering … a “Regular Expression” each day keeps you Regular … yes, you heard it first here, folks!
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
