Apparently several RSS feeds can be fetched “at once” by using the fetch_feed API, but core developer not excited to advertise this possibility (and I agree because I never heard anyone complain about the lack of such a feature)
The CEO of OnTheGoSystems, the company behind the multilingual wordpress translation plugin WPML, gave a presentation in wordcamp jerusalem 2013.
The presentation started by showing leading Israeli site which have great content in hebrew but are much less impresive or even plain bad in english or russian.
For the english example he used the leading israeli news portal ynet.co.il which has full content in hebrew and a simpler site in english. For the russian example he used the site of the airline arkia in hebrew and their russian site.
I wasn’t the only one that were underwhelemed by those examples for “poorly translated” sites. Ynet is mainly about israeli news so why would they even bother with an english site? tourists or buisnessman located in israel might want to know about the major political/buisness/cultural events but are they really interested in the israeli equivalent of “american idol”? Same goes for arkia, their main costumers are israeli and whatever service they give to russian speakers is related to israel (the phone numbers in the site are local israeli numbers), and how many russian speaking israeli are there that can’t use the hebrew or the english site?
In ideal world all content would have been translated in to all languages, but in the real world translation cost money and there is no point in spending money for translating into languages from which you don’t make money. It is never enough to translate the site only when it is launched, and you always need to keep spending time and money for translating every new content.
And if the reason for not having full translation to all the languages is money related conscious decision, then why would you even start considering a solution which has the basic assumption that all content should be translated? Better to just set up a site per language and manage the translation according to the amount of effort you decided to dedicate to that language.
The presentation highlighted something that WPML seems to do well, it gives you an up to date status of the translation and makes it easy to see what parts of the site are translated and what are not. This is something you can’t automatically achieve when each language has its own site. For sites that have to have reasonable up to date content in several languages (even if not all of the content) it might be a valid solution.
A very simple plugin, adds a “search” shortcode which can be used to add a search box into content.
For an active wordpress site the content gets bigger with time. Usually tou don’t even notice that until the site becomes slow and you install some caching plugin which makes the site to run even faster and you forget about the whole thing again.
Problem arises when you want to move your content with wordpress’s export and import tools. If you have a lot of content, the exported file which will be generated might be too big to be uploaded to the new server.
The easiest way to solve the problem is to split the exported file into smaller pieces using this splitter tool, and import each one of the generated files.
In addition to many other drawbacks wordpress search has it just can’t search the description associated with a taxonomy (category, tag) or author, so even if the most obvious search search result is the category page, the internal search will never show it.
But there is a way to hack around it if you really have to. All that needs to be done is to have a page with the exact same URL as a taxonomy.
If you which for the category “events” to be searchable, assuming its url is /category/events, all you have to do is to create two pages, one with the slug “category” and a sub page of it with the slug “events” and put the text associated with the category in the “events” page.
The only problem is that the search result will be styled like a page, but this is a small price to pay.
For all content types except pages wordpress uses a system of patterns to identify from the structure of the URL itself which type of content is being accessed. Once identified it can know in which part of the DB it should look for the content associated with the URL.
This is the reason why you usually should have a prefix “directory” in the URL which uniquely identifies your content. If there are two possible interpretations wordpress will match the first that is found.
Pages are different. WordPress kind of assumes that by default all content in the site is pages and the parsing rule for page URLs is “if it is not something else it might be a page”.
This lets you place pages anywhere in the URL structure. Here the question was about having an Event/post_slug URL for posts and have also an Event/Contact URL for a page. To do that you just need to have a page with a slug Events and a page with a slug Contact as its sub page.
As long as there is no post with the slug contact, when wordpress get a Events/Contact URL it tries to find a post in the events category with the slug Contact, and if there is none it will try to find a page with the slag Contact under a page with the slug Events and BINGO.
Two problems with this approach. Neither of them is probably major enough to prevent to use of this technique
- For every URL of the structure Events/xxxx where there is no post with the slug xxxx, wordpress will have to make another DB query to check if there is a page with the slug xxxx under the page with the slug “Events”
- You always have to remember not to create a post or subcategory of the category “Events” with the slug “Contact”. If you do that you page will not be access and you will not have any warning about that.
There is an exploit that can hit only those that know how to use linux to manage their site. Apparently linux editors store a backup copy of the file being edited in the same directory of the file. Therefor when a config file is being edited a copy of it is created, and since the names the editor gives to the backup files is predictable, and usually accessible as plain text from the web, all the data in the config is exposed at edit time. It is even worse if the editor failed to erase the backup after editing was finished.
Therefor you either should not edit config files locally, but transfer them over FTP, or put then in an inaccessible location (If wordpress is installed at the root directory you can put the config file at the usually inaccessible directory above it) or replace the config script with a script that read the config, or the secret parts of it from other location.
- I don’t like GPL, I think that for most places that it is being used at, especially in wordpress, the BSD license would have served as well and would have removed the illusion that just by selecting a restrictive license your code becomes less prune for IP theft.
- Matt Mullenweg created a great product and succeeded to maintain a great community around it. So far his insistence on GPL everywhere haven’t really hurt either of them and maybe actually strengthened them.
It seems like once a year there is some form of debate about wordpress, GPL and whether people might develop software related to wordpress which does not use a GPL compatible license. This time it is about whether people selling themes/plugins under split license (one for code and another for styling) should participate in wordcamps.
Maybe it is time to take one step back and ask again whether themes and plugins have to be GPL compatible.
The legal base for the claim is this legal opinion from James Vasile of the Software Freedom Law Center. There are two things to notice
- By law a lawyer have to help his client to present the best legal case for his objective. If I had the money I could find 10 lawyers which will contradict every second word in that post.
- After many bold claims the last paragraph backtracks from it all
Finally, we note that it might be possible to design a valid WordPress theme that avoids the factors that subject it to WordPress’s copyright, but such a theme would have to forgo almost all the WordPress functionality that makes the software useful.
But the most important thing to know about lawyers opinions is that they are always not much better then a guess and only the court can actually decide what is the correct legal interpretation of a legal situation. Lawyers can “guess” much better when there are precedences, but there where no court cases revolving around the nature of derivative work similar to wordpress plugins and themes that I know of (and I’m sure the lawyer would have cited them if he was aware of any).
Well, in may 2012 there was a ruling about a similar issue, whether API is copyrightable.In the legal battle between Oracle and Google about the use of java derivative in the android OS. Oracle claimed that just because Google implemented the same API that java has, without a license from Oracle, it infringed on its copyright. This claim was dismissed in court, but it has more to it then that, and according to the report the judge had set a limit to when a derivative work do not inherit the license of its origin.
Ninety-seven percent of the source code in the API packages is different; it’s only the three percent that overlaps that formed the heart of Oracle’s copyright claim. That three percent included packages, methods, and class names. But those declarations—like starting a function with
package java.lang—can only be used in certain ways. “In order to declare a particular functionality, the language demands that the method declaration take a particular form
Therefore claiming that just because some lines of code are similar in all themes to the GPLed themes provided as part of the wordpress distribution as Mark Jaquith says
If that argument doesn’t convince you, then note that the vast majority of themes derive from the original WordPress core themes. How they load different PHP subfiles, loop through posts, and get and interact with WordPress data is all covered by the original WordPress core themes, which are explicitly GPL
Doesn’t hold water unless there is some different way to use the wordpress API, which there isn’t. Big part of the PHP code in many themes is identical because there is either no other way to perform a specific functionality, or it is the best practice.
In my opinion the wordpress foundation (or wordpress.org or whoever is talking for wordpress) might have a right cause, but they win the fights because they have bigger sticks, and not because the law is on their side.
The news are that twitter got hacked and up to 250k user accounts where compromised. I’m not a real user of twitter although I have an account, so I might be wrong but in my opinion no one will feel extremely sad if some of his mental farts will be deleted or changed. Content on twitter, by the nature of the service that focuses on real time updates, is just not important enough in the long run.
But…. twitter is also a leading identity authentication provider on the web. If my twitter account was compromised it means that for a while the hacker had access to all the sites to which I have registered with my twitter account. It is hard to generalize how much cascading damage can follow from the hacker using my account, but it is not nice to even think about it. Twitter didn’t disclose the nature of the information to which the hacker got access, but I truly hope they don’t have a log of the sites to which I authenticate myself using my twitter account.