Pierre-Luc
-
Posts
291 -
Joined
-
Last visited
-
Days Won
2
Everything posted by Pierre-Luc
-
Hard to say without seeing the <head> on the specific pages you're talking about. Google still says this though: IMPORTANT: We continue to support and recommend using separate locale URL configurations and annotating them with rel=alternate hreflang annotations. Discovering based accept-language is one thing (this targets the users), you should still use the hreflang tags and <html lang="…"> (this targets crawlers). This will give better results as it's not prone to interpretation I believe. I haven't seen anything weird on the sites I use the plugin on yet, but will be monitoring.
-
Updated to support the devns branch.
-
Just when you think it wasn't possible to like ProcessWire any further. This is amazing news and will open up so many opportunities for complex data, very much appreciated! -
@ryan don't worry about it!
-
Have a look at this discussion: https://github.com/ryancramerdesign/ProcessWire/issues/839 Also, doughnuts.
-
The translation has been updated to 2.7. Just pushed to GitHub.
-
Forgot to update it. Now done, thanks to notifying me!
-
Hey, this is the exact use case why I made the http://modules.processwire.com/modules/process-field-generator/ module. It will generate crypto safe strings to use as page names (you don't have to expose the page id, especially with the combined use of urlSegments as a view handler).
-
I just started the process of going 2.0 on my first PW build. It's been running smoothly on 2.5.3 for a little while now, its first iteration was on 2.4, early 2012 according to timestamps. It never had an issue whatsoever, neither DB or security issues. The only downtimes I've ever had with it is moving from a shared to a dedicated server and a few security updates on the server itself. Satisfied customers for 3 years in a row! Since then, PW has seen so much.. and I've gotten a lot better at architecting content on it.
-
Hey, these strings have changed with the 2.6 >> 2.7 transition (the tree was partially (completely?) redone afaik). I'll be updating the translation soon, no ETA yet, but it looks like I might have some this this weekend. If you really need French everywhere, please stay on 2.6 master for now. EDIT : What LastKobrakai said.
-
Hi oliverx, that's a nice addition. Send me a patch (in a new issue) or pull request on GitHub, I'll review it and incorporate it in the next few days. If you're not on GitHub send it over at info@plauclair.me Thanks!
-
My pleasure Beluga.
-
How is the data stored on the cheatsheet? Would it be possible to host the project on GitHub? I've wanted to add stuff many times, but it's not really obvious how to contribute.
-
It can be possible, but right now it's not ready to do that.
-
Does it have composer support for modules though? If the autoload hasn't changed it probably wouldn't work.
-
Replied as well, not telling who I am.
-
You'll probably like the Bourbon family, on SCSS. http://bourbon.io -- Mixins http://neat.bourbon.io -- Semantic grid http://bitters.bourbon.io -- Bootstraping styles On bigger/more complex projects, have a look at the Susy SCSS layout framework, mixed with Bourbon and Bitters. http://susy.oddbird.net uikit and the like are nice, but I think there is too much overhead when modifying them.
-
Module Pagetree Add New Child Reverse (on Top)
Pierre-Luc replied to horst's topic in Modules/Plugins
Hey, love the plugin but this would really benefit from using the Selector inputfield as a selector instead of the textarea. -
Hey, I agree with you! I've slowly started adding different geographic input fields and ways to request them to ProcessWire (don't hold your breath, it's far from over! — and the repo is currently private..) I've been following stuff about MySQL, and the coming 5.7 release will be a big progress. Calculations on a sphere (no need for the harvestine formula), a handful of handy functions and lots of other things will finally make it finally possible to have relatively good quality GIS on MySQL. If you want to have some fun, you can read about some of the improvements on http://mysqlserverteam.com/mysql-5-7-and-gis-an-example/. It's still pretty easy to build those queries on PW, build a custom SQL query, get pages ID and build a pageArray from those IDs. You can use common fields like float and text and grab geometry from the stored lon, lat, or even store polygons and lines in text fields. The onus is on you to keep those values sane though, so it's still some work but not impossible.
-
… kidding aside, 1.0 is around 2007 but I don't see a way to pinpoint the exact date.
-
Well the first GitHub commit is 2011-03-20, that's a start. What was before then? Is it like the Big Bang and nobody knows?
-
The cheatsheet is a bit outdated.. Don't be surprised if you don't find everything in there, but most of it is.
-
Hey I've been wondering if any of you who are currently using this in production or testing have any feedback? I want to do a proper release soon, and I'd love your input! Cheers!
-
Haven't been able to test in depth.. but any report on compatibility with the new access settings in 2.6 dev branch?
-
Hey Sérgio, I've read that too but after doing some research it's really not as clear cut at StackOverflow might want it to be. As far as I know crawlers don't use Accept-Language typically, and the plugin does absolutely no redirection when it is not set so it should not change their behaviour. This is what Google's documentation says, and others too, and it's also why I implemented the plugin the way it is implemented. From the "Location-aware crawling" page from Google, you can read this: This means that if your website is serving purely based on Accept-Language, there might be trouble cause Google isn't sending any typically, I've seen this happen in the past. The plugin does none of this, it's in your hands to implement a good solution. What you want to do : DO use <link> with hreflang to help the crawlers find other pages. Don't serve multiple languages from the same URL — always use lang.example.com/.. or example.com/lang/.. It's confusing to users not to and they can't send pages to their friends in the "right" language. Don't use GET parameters to set anything language related. Don't prevent the user (or crawlers) from switching languages and become trapped in a language that isn't their own — aka always have a language switcher in a prominent place and don't detect more than once. Read all the "International" section very carefully and find a solution that works for you. Localization is not an easy topic. Note tough that Google tells you what alternative methods supported (tough there's a huge red warning box at the top of the page) : In each case : 1) AutoDetect language isn't a location (geo-ip or else) aware plugin. 2) Discussed earlier, wouldn't recommend for various reasons but might still work. Google says "usually don't". 3) That's the firewall's job! However, if you guys still follow best practices and have trouble being indexed, I'm open to look at more "advanced" solutions. …But more complexity means more points of failure and that's something I usually want to avoid. Just want something that's accessible to beginners and works in the most common cases.
