The fact that this is not shows that not many people (here) agree. :)
I personally have no opinion on DB schema because I never looked that deep, but last time I had to deal with WP its codebase was just horrible. And don't get me started on plugins' code quality, it goes to entire other level of "horrible". The project might have a lot of talented contributors, but they seem to be overshadowed by everyone else.
They might have fixed it from the last time I looked of course (though I doubt it, judging by never ending stream of vulnerabilities).
Sorry if it was not clear. Sensei, along with all of other other plugins will remain and continue being develop as normal. No need to worry at all. We have a lot of exciting things coming up for Sensei ;)
I have never had good luck with that. Some generated URLs still use the DB value and so forth. Perhaps it's an indictment of plugin developers vs WP core. I still cannot think of a good reason for that value to be in the DB at all.
I won't go into detail on that here but know that there's a very good reason for it. Plugin and theme developers should be using for example `esc_url( home_url( '/' ) );` when requiring the URL of the site.
Ok, as someone who's battled with this... feature... of WP I am super curious as to the very good reason for storing the domain in the DB. Why couldn't links be relative (no need to know the domain), or set only as a sitewide variable in wp-config.php?
edit: and just discovered the 'guid' column on the posts table is hardcoded as the URL of the post -- the domain you're on at the time you create the content + the post ID. Seems like a nightmare for content staging on a non-prod environment.
> just discovered the 'guid' column on the posts table is hardcoded as the URL of the post
It comes up every so often. The WordPress devs are well aware of the platform's warts & WTFs. People have talked for a while about replacing it with a proper UUID, but there are way too many themes & plugins that use the guid field to get the post's URL instead of calling, say, get_permalink( $post_id ).
So now the devs are stuck. You can deprecate "guid", but you can't get rid of it. You can't replace the URL with a UUID because of backwards compatibility with third-party code. Do you add a "uuid" column? Now you have a guid column & a uuid column and people are going to get even more confused.
Right now, content staging is a bit of an edge case and folks who need it are able to store a UUID in a post_meta field. So it's not a really critical issue. But it would definitely be nice to see a proper UUID in core.
Certainly there are configuration options that are appropriate to store in the database, but I'm trying to understand why domain is one of them. The site knows what domain it is on by virtue of being hosted on that domain.
Storing the domain in the DB may be reasonable if it's done once, but WP does it multiple times: WP_SITEURL ("the address where your WordPress core files reside"), WP_HOME ("the address you want people to type in their browser to reach your WordPress blog") and of course GUIDs for every post have the domain hardcoded into their values (that can mess up links in a weird way, where you're on your local environment, click a link, and now you're silently on prod).
I could definitely be missing something, but I can't for the life of me figure out why this is a good idea.
There are only two places where the URL should be stored. Anywhere else is an issue with the plugin or theme storing them incorrectly. Both are contained within the wp_options table for home URL and site URL. Those are the only values required to be changed. If you have a development environment, you should not be migrating the wp-config.php file anyway as it has sensitive information for product sites thus on your dev site you can have a separate wp-config.php file to take into account the new values for home and site URL's.
You aren't missing anything. This problem has been there in WP for a long time, and it makes staging/testing/migration setups a horrible pain (as others have suggested, lots of search & replace).
But, it's stored all over the place, not just a single table or file. All of the URLs on the site get put into the DB as fully qualified. Just today, I had to do a search-and-replace with wp-cli on 26k instances of the domain name in the db.
Giving users everything they want is a surefire way to build a disaster of a codebase. I have no knowledge of WordPress, that's just a general principle. Users are a bit too silly to trust.
Hey all. I'm Michael, a Developer Advocate at WooThemes and now Automattic. I'm happy to answer any questions. As you can imagine, we're all really excited about this.
> We had talks with potential partners, including VC firms and competing companies. This led us to Automattic, who had previously shown great interest in the popularity of WooCommerce. CEO Matt Mullenweg, who is also the co-founder of WordPress, had built his company in the same distributed manner as WooThemes with a team of over 300. This was our dream partner!
Here's a question: do you have any idea of what the first initial changes might be for developer/firms and how we work with WooCommerce/WooThemes/WooMatic?
The WooCommerce eco-system relies on our third-party developers and we will continue working with them. We don't have any immediate changes that would affect developers and agencies. We do plan to introduce a new developer program (a re-imagined Affiliated Woo Workers) to help agencies and developers in the coming months but is unrelated to the acquisition and has been in the works for the last few months.
> Also, it sounds like job roles transferred over one-to-one?
Usually when a company merges like this, there's a period just after acquisition where both companies still operate independently while the higher-ups try to figure out the integration plan. That doesn't mean titles/roles won't change, but the same day as the announcement? It'd be business as usual at both companies.
Michael works with other companies to encourage better integration, like payment gateways and shipping tools. It's a new position, but a sure exciting time to be there :)
Congrulations! This is a great step forward for the community and for both parties involved.
As for WooThemes - will we start seeing proper documentation [1] when products are released? I've been bit in the past by something being released by WooThemes, and documentation taking another half year up to year to follow.
You're right. We could have done a better job at documenting the REST API. We've been slowly introducing and fixing issues with the the REST API since it's debut. We never fully announced it as it was still very much a work in progress. However in WC 2.3 I'm happy to announce we've significantly improved the REST API and documentation.
Without a doubt we're also going to have many more resources joining Automattic and their talented group.
After reading your answers, it looks like at this point, you don't have clear visibility into a lot of areas (integration with Wordpress, impact to third party developers, etc) as to what is going to happen in the future. Understandably so.
Do you have any area (like better documentation, which you wrote about) where you have a clear vision about the future? Can you tell us about that? I think that will be more useful.
Shared on Facebook and sadly showed up as "Home page - Lily" with no meta description. If you're looking for more people to share and click, try fixing your meta tags so when people share it shows full a good teaser of the product is.
Since the iPhone introduced widgets, I've found it a lot easier to check-in using Swarm. I swipe down and click check-in. It already knows where I am. Before this, I rarely used Swarm.
This has been an issue for me for awhile. I've been scouting for screens for awhile for something cheap. I've been visiting GoodWill often as they have a large selection of monitors to choose from but most of them are far too large for a small screen. $15 is a great deal for a cheap monitor, but it takes up a huge amount of room.
I would agree. I work in a large organization that shoves all websites into drupal, and provides our non-technical clients with solutions they don't like using.
The Drupal pumpers I always feel are just highly opinionated techno-files, and somewhat insufferable to debate with. I think most are scared of learning new technologies, and none of their opinions are based on developing solutions and workflows that easy to use for their clients or how people surf the web (google it).
All the drupal modules are 5 years old, have 30,000 installs, and don't actually do anything nicely that you want them to do. Go find a drupal module that is similar to Yoast SEO. Go find a great responsive template to base your sites design on for that matter. Setup a author-editor-publish workflow that someone who only knows how to use facebook and gmail can work with. Drupal is terrible for clients to manage.
Perhaps biased since I work for WooThemes but I disagree. First of all WooCommerce is free. What you need on your site is not needed on all sites. There is no "basic" version of WooCommerce. There is only one version and what you need on top of that is up to you. Extensions can be purchased from our marketplace or several others, but that's optional. There are free ones on WordPress.org that provide what you're looking for that are free but you will need to pay for support. WooCommerce itself works the same way. You also have the option to develop what you need on your site.
