I have disabled wpautop through the given code:
remove_filter( 'the_content', 'wpautop' );
remove_filter( 'the_excerpt', 'wpautop' );
This function works. But my actual problem is that, it removes custom "p" tags that I have manually used in the content.
So the problem is that when I don't use the above given code, there are automatic p tags that destroy my website and when I disable them, custom p tags are also disabled.
The easiest and simplest way to avoid wpauto issue is to understand how wpautop works,
Any plain text, or inline element that aren't wrap with block element will be automatically wrap with p. if element is block and doesn't have two line breaks inside it, it won't be wrap with P as well as the elements inside it, empty inline element will be strip and remove.
example
inline
<img src="blabal.jpg"> will be output <p><img src="blabal.jpg"></p>,
I am awesome will output <p>I am awesome</p>,
<span>Really?</span> will output <p><span>Really?</span></p>,
block
<div><img src="blabal.jpg"></div> will be output <div><img src="blabal.jpg"></div>,
<div>I am awesome</div> will output <div>I am awesome</div>,
<div><span>Really?</span></div> will output <div><span>Really?</span></div>,
<span></span> will output nothing, (empty inline elements will be removed.),
I really like wpautop, I never disable it, I just wrap any content with DIV if there's an element I don't want to have P, I also have a shortcode that avoids wpauto when element is inside, its helpful when you have a long ass content that wanted to avoid automatic p tag
Here's a fix/work-around I just found through experimentation. Give the <p> element an attribute (<p class>). It doesn't even have to have an actual value. WordPress seems to think that if it has an attribute, it's worth keeping. Furthermore, the attribute doesn't even have to be an actual HTML attribute. For example, <p data-please-work> seems to work just fine. I'm not saying I necessarily recommend doing that, but it's worth mentioning.
I actually discovered this problem myself just now, and searching for a fix lead me to this question. It's a very exasperating situation, and I don't understand why it works like that. You would think that disabling it would simply prevent WordPress from adding its own <p> elements—but no. It seems like it tries to prevent <p> elements, period—even yours.
If someone else has another way to go about dealing with this, I'd love to know. Silver's tips seem helpful to know though.
Related
I'm having an issue where an unordered list created by data-sly-list is adding whitespace that isn't represented in the DOM or by any class. If I manually code the list rather than letting data-sly-list handle it, the whitespace isn't added.
<div class="bullets">
<ul class="columns unordered-list" id="stateList">
<div data-sly-unwrap data-sly-list.slidesNode="${resource.listChildren}">
<div data-sly-unwrap data-sly-list.states="${slidesNode.listChildren}">
<li data-sly-test="${states.valueMap.flag}">
<sly data-sly-use.htmlpaths="${'htmlpaths.js' # thePath=states.valueMap.path}" data-sly-unwrap>
${states.valueMap.name}
</sly>
</li>
</div>
</div>
</ul>
</div>
If I hardcode the list like the following, there's no whitespace
<div class="bullets">
<ul class="columns unordered-list" id="stateList">
<li>Accessibility
</li>
<li>Accessibility
</li>
<li>Accessibility
</li>
<li>Accessibility
</li>
</ul>
</div>
There's also a htmlpaths.js involved:
"use strict";
use(function() {
var path = this.thePath;
var httpRegex = /http/;
var hashRegex = /#/;
if (path !== undefined && (httpRegex.test(path) === false && hashRegex.test(path) === false)){
path = path + '.html';
}
return {
href: path
}
});
The only difference I see is that its run through Sightly iterating. Is there any fix to this? In addition to listing I'm trying to break them into columns with the following CSS
li {
width:25%;
float:left;
display:inline;
}
This works perfectly fine on the hardcoded list, but on the Sightly iterated one it creates all kind of weird spacing issues that change based on screen width
This whitespace isn't accounted for at all in the DOM. I'm not sure what to do.
More weirdness:
If the margin top is set to -9 or higher, it looks like the above screenshot. But if its set to -10 or lower, it looks like this
It's like its a breakpoint, it goes from one extreme to the other on that one pixel change. No change otherwise. It's bizarre.
It's a little weird behavior in sightly, when you have some extra spaces in your HTML code, it will display with extra spaces in the HTML.
Try to remove all the spaces in the HTML as shown below and try it.
<div class="bullets"><ul class="columns unordered-list" id="stateList"><sly data-sly-list.slidesNode="${resource.listChildren}"><sly data-sly-list.states="${slidesNode.listChildren}"><li>${states.valueMap.name}</li></sly></sly></ul></div>
You can use HTML formatter in your IDE or online tools like below to format the HTML for a readable format
https://www.freeformatter.com/html-formatter.html.
<div class="bullets">
<ul class="columns unordered-list" id="stateList">
<sly data-sly-list.slidesNode="${resource.listChildren}">
<sly data-sly-list.states="${slidesNode.listChildren}">
<li>${states.valueMap.name}</li>
</sly>
</sly>
</ul>
</div>
This should get rid of the extra spaces in your HTML.
Also, it is best to use sightly tags wherever we need some conditions to check or embed them directly in the actual div tag or html tags instead of using data-sly-unwrap.
You can also use sling models to get the required data and check all the conditions(including appending html) in the backend and send the data just to display and avoid all the conditions in sightly.
Using data-sly-unwrap or a sly tag still adds an empty line in the generated HTML. Even though most browsers ignore those spaces, they might cause issues in some cases. If you want the HTL output to look similar to your hardcoded HTML, try placing the use statement and anchor tag in a single line as shown below.
<div class="bullets">
<ul class="columns unordered-list" id="stateList" data-sly-list.slidesNode="${resource.listChildren}">
<li data-sly-repeat.states="${slidesNode.listChildren}" data-sly-test="${states.valueMap.flag}"><sly data-sly-use.htmlpaths="${'htmlpaths.js' # thePath=states.valueMap.path}">${states.valueMap.name} </sly></li>
</ul>
</div>
Also, a few tips
The sly tag doesn't need a data-sly-unwrap. It is automatically
removed in the generated HTML.
data-sly-list can be added to the parent ul tag itself instead of introducing an extra div tag and then unwrapping it.
Use data-sly-repeat instead of data-sly-list wherever possible. I was able to bring down the generated HTML of one of our complex pages from 20k lines to 12k lines, as data-sly-repeat doesn't introduce additional white spaces.
Solution
The issue is on line 7 of your HTL template:
${states.valueMap.name}
You have a space at the end of the inner HTML of your tag ;)
Unrelated
Regarding your htmlpaths.js script, are you aware of Transformers in AEM? You can use them to implement a global Link Rewriter which will fix links when a page is rendered, much like your script does. You can see an example here: https://helpx.adobe.com/experience-manager/using/aem63_link_rewriter.html
If you decide to keep htmlpaths.js, you may want to review it because I'm afraid there might be some problems with it. Of course, I don't know your requirement so it's just a suggestion :)
I am trying to print the href of a html doc, however I am not able to do so.
newurl = 'http://www.heroesfire.com/hots/guide/the-many-ways-of-abathur-1194'
buildpage = Nokogiri::HTML(open(newurl))
#puts buildpage
thistext = buildpage.css("div#wrap div#site-content.self-clear div#guide.view-guide div.col-l div.tab-contents.box div.guide-tab div.chapter-text div.text table.bbcode_columns tbody tr td.bbcode_column a").each do |href|
puts href['href']
end
I am expecting to see '/hots/wiki/talents/pressurized-glands'
I was able to get something similar to work earlier in my script, but I am having zero luck with this.
Invariably, the longer the Node selector, the less likely it will work correctly, especially if you're dealing with HTML you don't control.
Reduce it to find way-points, places that help you drill down instead of trying to define each step.
You're also relying on tbody in the selector. When we see that, the odds are good that it's not in the original HTML source but instead was injected by your browser. Selectors like that smell of using a browser and an inspector to locate a particular item in the page, but the resulting path won't work if the HTML doesn't actually contain tbody. Browsers do a lot of fix-up in an attempt to present something useful, including adding tags. So be careful when you see tbody and confirm it actually exists. In your case, it does, but the concern still exists when navigating through a document.
A simple example of simplifying the path is:
require 'nokogiri'
doc = Nokogiri::HTML(<<EOT)
<html>
<body>
<div id="foo">
<div id="bar">
<p>text1</p>
</div>
<div id="baz">
<p>text2</p>
</div>
</div>
</body>
</html>
EOT
doc.at('body div#foo div#bar p').text # => "text1"
Can be written more easily, while still accomplishing the same thing, using:
doc.at('#bar p').text # => "text1"
or perhaps one of these:
doc.at('#foo div p').text # => "text1"
doc.search('#foo div p').first.text # => "text1"
All scraping requires at least some advance knowledge of the target page's structure, so, while you're nosing around, take note of the important layout tags. id parameters are especially useful, followed by class and/or unique patterns of tags not replicated elsewhere in the document. Those make it easy to reduce the selector. Sometimes we have to step into the document incrementally like I did using first or one of the "sibling" methods after locating a particular node, but using a long selector rarely is needed.
Any ideas on good ways to apply styling to classes of articles (categories, or anything else?)
Currently, I create a first pass at the article manually, wrapping it in a span:
<span class="foo">
<p>bar</p>
<p>etc</p>
</span>
I then paste the article into JCK Editor, and have a new css file in the template directory to handle class foo.
This doesn't work very well, since JCK Editor moves the span class to the internal elements, producing something like
<p><span class="foo">bar</span></p>
<p><span class="foo">etc</span></p>
This is Ok until you start editing the article with JCK Editor, because the new content doesn't go in the span:
<p><span class="foo">bar</span></p>
<p><span class="foo">etc</span></p>
<p>New unstyled content inserted by JCK Editor</p>
I'm on Joomla3. What would be ideal would be if the name of the category appeared in the html, so I could hang a style on it, but it doesn't.
There are a number of ways to approach this. If you want to add a class to the body tag for this purpose, take a look at how I do it at https://github.com/construct-framework/construct5/blob/master/index.php#L65 and starting at https://github.com/construct-framework/construct5/blob/master/elements/logic.php#L235. This assumes that you are going to edit your template.
You could also whip up a simple plugin to add these classes to you body tag dynamically.
Otherwise, it could be possible to do this with something like http://extensions.joomla.org/extensions/style-a-design/templating/14053
If each category is sitting on own menu item, you may add 'Page Class' suffix for container div (Advanced Options > Page Display Options)
Other way would be adding template override:
copy components/com_content/views/category/tmpl/blog.php to templates/[your_template]/html/com_content/category/blog.php)
And inside of the file change
<div class="blog<?php echo $this->pageclass_sfx;?>">
to
<div class="blog<?php echo $this->pageclass_sfx . ' ' . $this->category->alias;?>">
You should probably not add p-elements inside span-elements, as span is an inline element and should not contain block-elements like p. This is why JCK is switching the elements. If you use a div-element instead, you probably won't have this problem with the text-editor.
Apart from this, I guess both the other respondents have good points.
I'm using html5, JQuery Mobile and KnockoutJS, I Have a foreach template that renders a grid like GUI from an observable array.
However, when I add items to the bound array, the styles are not applied to any new items.
They appear unstyled, most of the times.
some times they appear with style, but once the styling fails, it stays broken for as long as I run my app.
Does anyone have any idea how to resolve this problem?
Snippet:
<div id="timeEntryList" data-bind="foreach: timeEntries">
<div data-role="header" data-theme="c">
<h1>some header</h1>
The odd thing is that it works sometimes.
Hard to guess without any code. But I guess you 're saying jqm doesn't render properly after dynamically adding elements. That's right it doesn't. I guess it's like the list. And you probably can do something like $('#mylist').listview('refresh'); but I don't know what sort of component you're talking about.
you can find more info in the documentation
jQM might not support more than one data-role="header" section. I would try conforming to their standard page layout with one header, one content and one footer section and see if that helps.
I've found that if I update my KO observables in pagebeforeshow I don't have to use .listview('refresh')
our site is giving out 'badges' to our authors. they can post these on their personal blogs and they will serve as incoming links to our site.
We want to give out the best possible code for SEO without doing anything that would get us flagged.
i would like to know what you're thoughts are on the following snippet of code and if anyone has any DEFINITE advice on dos and donts with it. Also, let me know if any of it is redundant or not worth it for SEO purposes.
i've kept the css inline since some of the writers would not have access to add link to external css
i've changed the real values, but title, alt etc would be descriptive keywords similar to our page titles etc (no overloading keywords or any of that)
<div id="writer" style="width:100px;height:50px;>
<h1><strong style="float:left;text-indent:-9999px;overflow:hidden;margin:0;padding:0;">articles on x,y,z</strong>
<a href="http://www.site.com/link-to-author" title="site description">
<img style="border:none" src="http://www.site.com/images/badge.png" alt="description of articles" title="View my published work on site.com"/>
</a>
</h1></div>
thanks
Using H1 to enclose your "badge" is a really bad idea—not in so much as it'll negatively affect SEO for your site, but it will very likely ruin the accessibility (and thus SEO) of the author site. H1-H6 are used to provide document structure by semantically delimiting document headings. Random use of heading tags can confuse screen readers and webcrawlers. There's not much you can do in terms of legitimate SEO aside from making correct use of semantic HTML markup.
Edit:
Something like this would be the safest bet:
<div id="writer-badge" style="width: 100px; height: 50px;">
<strong>
Articles on x,y,z
</strong>
<br />
<a href="..." title="site description" rel="profile">
<img style="border: none" src="..." alt="..."
longdesc="http://site.com/badges-explained"
/>
</a>
</div>
I put a line-break between the text and image to treat the text as sort of a badge title. If it's not meant to be displayed that way, then I would omit the <strong> tags altogether (there's no semantic value in encapsulating the text that way, and any styling could be done using the DIV or a weight-neutral SPAN element).
IMO there's really no reason for a achievement badge to have a heading of its own (it's really not even part of the document, just a flourish in the layout), but if you absolutely must, then H6 would be more appropriate and safer to use than H1.
As far as keyword proximity, that is sorta venturing into the grey-hat area of SEO (similar to keyword stuffing), and I wouldn't know anything about that. I've yet to come across any reliable info on how Google or other search engines treat keyword placement. I think if you properly use tag attributes like alt, title, longdesc, rel, rev, etc. in images and links, you'll be alright.
I don't think there is any issue with this code except your <h1> tag. I would probably change it to <h2> simply because pages are supposed to have only 1 <h1> tag per page.
You could also use an iFrame instead if you wanted. That is what SO does but I know you will not get as much linky goodness.