[wp-hackers] Best Practice for Mobile WP View
Will Anderson
will at itsananderson.com
Sun Jun 24 08:17:38 UTC 2012
Media queries are probably a decent option, but depending on how much
you've already invested in writing separate themes, that might not be
feasible.
Here's a mu-plugin solution that works more along the lines of what you
were hoping to accomplish:
https://gist.github.com/2982374
You'll want to change that code in the following places:
Line 14: Change the domain to your actual mobile site domain
Line 29: Change the theme to your actual mobile theme
Also, it's probably a good idea to read through the rest of it to get an
idea of what's going on. Basically it's switching your theme (and changing
the site URL) based on which domain was used to make the request.
To get this working on your site, install the code as a Must Use plugin
(after making the previously mentioned changes). Must Use plugins go in
/wp-content/mu-plugins/. You'll probably have to create the mu-plugins
folder. Name the PHP file something like "mobile.php" (or
whatever-you-want.php, really). Then just point both domains at that
WordPress instance, and you should be good to go.
The one caveat I can think of is that site caching might do funny things to
this solution (like serve mobile versions to desktop users, or visa-versa).
You could probably find a decent workaround for that as well, but it would
almost definitely have to be more specific to the caching plugin you're
using.
Also, this solution doesn't actually redirect mobile users to the mobile
domain, but I'd assume there's already code (or a plugin) out there
somewhere for doing that.
Hope this helps!
Will Anderson
On Fri, Jun 22, 2012 at 7:42 AM, taylor young <taylor.d.young at gmail.com>wrote:
> Use media queries to change the layout, use the same markup, and the same
> domain.
>
> http://adstexas.com
> http://modassicmarketing.com
>
> -Taylor
>
> On Fri, Jun 22, 2012 at 7:00 AM, <wp-hackers-request at lists.automattic.com
> >wrote:
>
> > Send wp-hackers mailing list submissions to
> > wp-hackers at lists.automattic.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > or, via email, send a message with subject or body 'help' to
> > wp-hackers-request at lists.automattic.com
> >
> > You can reach the person managing the list at
> > wp-hackers-owner at lists.automattic.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of wp-hackers digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Best Practice for Mobile WP View (Jeffrey Nolte)
> > 2. preventing the duplicate wp_insert_post effect (Haluk Karamete)
> > 3. Re: preventing the duplicate wp_insert_post effect
> > (Haluk Karamete)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 21 Jun 2012 13:02:26 -0400
> > From: Jeffrey Nolte <jnolte at getmoxied.net>
> > Subject: [wp-hackers] Best Practice for Mobile WP View
> > To: Wp Hackers <wp-hackers at lists.automattic.com>
> > Message-ID: <9153C94F-420D-471E-96EF-C7E22AAD2E36 at getmoxied.net>
> > Content-Type: text/plain; charset=us-ascii
> >
> > We are on the process of building a mobile site in WordPress.
> >
> > I would like to get some insight on best practice for configuring the
> > site. I have listed some details below.
> > Site is current in WP on http://site.com
> > We would like to have mobile on http://m.site.com
> > Both domains / views / sites will use the same database and assets
> (images
> > attached to posts, etc)
> > Our ideas for implementation were to configure another WordPress(
> > http://m.site.com) on the same server as using http://site.com and
> > connecting this new WP install to the existing db (http://site.com).
> >
> > I know there may be a better way hence me reaching out to the community.
> >
> > Thank you in advance,
> >
> > Jeffrey Nolte
> > Moxie Media Group, Inc.
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 21 Jun 2012 12:08:38 -0700
> > From: Haluk Karamete <halukkaramete at gmail.com>
> > Subject: [wp-hackers] preventing the duplicate wp_insert_post effect
> > To: wp-hackers at lists.automattic.com
> > Message-ID:
> > <CAHERW=2F3G8jRRh=
> fh4y4jaWUVQVnwEY_CtDeuyPVxaquKcR+g at mail.gmail.com
> > >
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > This is all part of a migration routine I wrote where a while loop
> > goes thru 15,000 records from an ms-sql table and converts each record
> > into a post_data array to be fed into the wp_insert_post API.
> > Technically, since I'm dealing with 15000 recs in ms-sql, I should end
> > up with 15000 posts in a fresh installed wp_posts table. Right? In my
> > case, I sometimes get 16000, sometimes 290000. It's never the same.
> > Everytime is different. I'm almost to the point to re-write the code.
> > But if the culprit itself the wp_insert_post and some internal wp
> > process or wordpress cache that I do not know of or mysql server
> > config and or and or and or... , even the new approach won't work.
> >
> > After some research, I've come to learm I'm not alone on this. But
> > from what I read, I could not get a wrapper around it.
> >
> > As I said above, I create the posts going thru a while loop.
> >
> > Since the process takes a long time, I had to build a custom time-out
> > module. As the code goes thru the iterations of the while loop, it
> > marks its process into a time_out table, and siince I got a watch dog
> > page that's running in an iframe to keep an eye on the time_out
> > table's progress, even if the bottom frame ( the one that handles the
> > ms-sql to wp_posts process ) times out, I know from what record to
> > kick start the process.
> >
> > This way I do not have to sit in front of the computer to keep
> > clicking on 'continue'. link.
> >
> > Well, this trick works on all of my implementations that are severed
> > by timeouts . I eventually end up getting the whole table is processed
> > and the watch dog iframe stops refreshing when the number of records
> > to be processed is equal to the number of records that have been
> > processed in the last instance. So the time-out module works perfectly
> > except....
> >
> > Only and only when the destination table is wp_posts and when the the
> > wp_insert_post API is involved, I get a problem.
> >
> > After the first time-out, things start getting hay-wired.
> >
> > >From time to time, wp_insert_post ends up firing twice/thrice causing
> > the same record to be inserted multiple times.
> >
> > To remedy the situation, I've tried 3 different techniques including
> > the use of custom fields, but no luck. I also tried inserting a unique
> > key into the post itself to minimize the database activity. I found
> > this is better cause it avoids the involvement of custom fields, and
> > yet achieves the same goal. I put the source_key ( which is something
> > like --{$db_name}.{$table_name}.{$recid_value}-- ) in the post and
> > at_insert_time , I just check the existence of that key ( using like
> > operator ) to see if that post was added previously. but even that
> > fails... Wp_insert_post surprisingly creates double records. and up
> > until now, I simply cannot pin-down the occurrence of the problem.
> >
> > I read this, Prevent duplicate posts in wp_insert_post using custom
> > fields But my techniques were simply alternatives to it.
> >
> > Here is a cut-down code of how I do it...
> >
> > while ($row = mysql_fetch_assoc($RS)) :
> >
> > $source_recid = $row['source_recid'];
> > //source_recid is something like db.table.tablerecid
> > //example services.media.1223
> >
> > $post_data['post_content'] =
> > $row['some_field_thats_got_page_content'];
> >
> > //append the source_recid to the post data in forms of an html
> > comment for uniqueness purposes
> > $post_data['post_content'] = $post_data['post_content'] .
> > "<!--{$source_recid}-->";
> >
> > //do the other stuff... ( shortened here for the clarify
> > purposes... )
> >
> > ....
> >
> > $post_data['post_status'] = 'publish';
> >
> > Insert_or_UpdatePost($dbh,$post_data,$source_recid,$post_id);
> >
> >
> > if ($post_id==0):
> >
> > //log the error and move on
> >
> > continue;
> >
> > endif;
> >
> >
> > endwhile;
> >
> > function Insert_or_UpdatePost($dbh,$post_data,$source_recid,&$post_id){
> >
> > // this function first looks up the --db.table.tablerecid--
> sequence
> > // across all wp_posts post_content field
> > // in determining if this record has been already INSERTed!
> >
> > // and depending on the outcome, it does an insert or update
> > // and return the $post_id accordingly
> >
> > // if the function determines there are no such records,
> > // then and only then, it runs the wp_insert_post!
> >
> > // if the function determines that there is a post like that,
> > // it retrieves the post_id
> > // and then switches to operation
> > // to use the wp_update_post instead!
> >
> > // with this approach, technically speaking,
> > // it should impossible to run wp_insert_post on an existing post!
> >
> > // and yet, I still get duplicate posts...
> >
> > // here we go;
> >
> > $post_id_probed = blp_sql_getdbvals($dbh,"select id from
> > wp_posts where post_content LIKE '%--{$source_recid}--%'");
> >
> > if (blp_isnumber($post_id_probed)):
> > $post_id = $post_id_probed;
> >
> > $post_data['ID'] = $post_id;
> > $post_id = wp_update_post( $post_data );
> >
> > if ($post_id == 0):
> >
> > //add error
> >
> > return FALSE;
> >
> >
> > else:
> >
> > update_post_meta($post_id, "wpcf-blp-migration-date",
> > blp_now('mysql'));
> >
> > return TRUE;
> >
> > endif;
> >
> >
> > endif;
> >
> > // if we make it this part, it means only one thing!
> > // there is no post for the db.table.tablerecid yet,
> > // so do the insert!
> >
> > $post_id = wp_insert_post( $post_data );
> >
> >
> >
> > if ($post_id == 0):
> >
> > //add error
> >
> > return FALSE;
> >
> >
> > else:
> >
> > //add_post_meta($post_id, "wpcf-blp-migration-source",
> > $source_recid,TRUE);
> > //no need for that anymore
> >
> > return TRUE;
> >
> >
> > endif;
> >
> >
> > }
> >
> > There is also a post I created at wordpress.stackexchange site.
> >
> >
> >
> http://wordpress.stackexchange.com/questions/19732/prevent-duplicate-posts-in-wp-insert-post-using-custom-fields
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Thu, 21 Jun 2012 17:12:00 -0700
> > From: Haluk Karamete <halukkaramete at gmail.com>
> > Subject: Re: [wp-hackers] preventing the duplicate wp_insert_post
> > effect
> > To: wp-hackers at lists.automattic.com
> > Message-ID:
> > <CAHERW=
> 1Rw+xQV55iPPUtN6U4Wqsi-EWHdQG0V4fdmpnSapx5Nw at mail.gmail.com
> > >
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > One discovery...
> >
> > If I change the "wp_insert_post" to wpdb->insert and use a straight
> > wpdb insert, there are no problems. So this is all comes down to the
> > wp_insert_post.
> >
> > On Thu, Jun 21, 2012 at 12:08 PM, Haluk Karamete
> > <halukkaramete at gmail.com> wrote:
> > > This is all part of a migration routine I wrote where a while loop
> > > goes thru 15,000 records from an ms-sql table and converts each record
> > > into a post_data array to be fed into the wp_insert_post API.
> > > Technically, since I'm dealing with 15000 recs in ms-sql, I should end
> > > up with 15000 posts in a fresh installed wp_posts table. Right? In my
> > > case, I sometimes get 16000, sometimes 290000. It's never the same.
> > > Everytime is different. I'm almost to the point to re-write the code.
> > > But if the culprit itself the wp_insert_post and some internal wp
> > > process or wordpress cache that I do not know of or mysql server
> > > config and or and or and or... , even the new approach won't work.
> > >
> > > After some research, I've come to learm I'm not alone on this. But
> > > from what I read, I could not get a wrapper around it.
> > >
> > > As I said above, I create the posts going thru a while loop.
> > >
> > > Since the process takes a long time, I had to build a custom time-out
> > > module. As the code goes thru the iterations of the while loop, it
> > > marks its process into a time_out table, and siince I got a watch dog
> > > page that's running in an iframe to keep an eye on the time_out
> > > table's progress, even if the bottom frame ( the one that handles the
> > > ms-sql to wp_posts process ) times out, I know from what record to
> > > kick start the process.
> > >
> > > This way I do not have to sit in front of the computer to keep
> > > clicking on 'continue'. link.
> > >
> > > Well, this trick works on all of my implementations that are severed
> > > by timeouts . I eventually end up getting the whole table is processed
> > > and the watch dog iframe stops refreshing when the number of records
> > > to be processed is equal to the number of records that have been
> > > processed in the last instance. So the time-out module works perfectly
> > > except....
> > >
> > > Only and only when the destination table is wp_posts and when the the
> > > wp_insert_post API is involved, I get a problem.
> > >
> > > After the first time-out, things start getting hay-wired.
> > >
> > > From time to time, wp_insert_post ends up firing twice/thrice causing
> > > the same record to be inserted multiple times.
> > >
> > > To remedy the situation, I've tried 3 different techniques including
> > > the use of custom fields, but no luck. I also tried inserting a unique
> > > key into the post itself to minimize the database activity. I found
> > > this is better cause it avoids the involvement of custom fields, and
> > > yet achieves the same goal. I put the source_key ( which is something
> > > like --{$db_name}.{$table_name}.{$recid_value}-- ) in the post and
> > > at_insert_time , I just check the existence of that key ( using like
> > > operator ) to see if that post was added previously. but even that
> > > fails... Wp_insert_post surprisingly creates double records. and up
> > > until now, I simply cannot pin-down the occurrence of the problem.
> > >
> > > I read this, Prevent duplicate posts in wp_insert_post using custom
> > > fields But my techniques were simply alternatives to it.
> > >
> > > Here is a cut-down code of how I do it...
> > >
> > > while ($row = mysql_fetch_assoc($RS)) :
> > >
> > > ? ? ? ?$source_recid = $row['source_recid'];
> > > ? ? ? ?//source_recid is something like db.table.tablerecid
> > > ? ? ? ? ? ?//example services.media.1223
> > >
> > > ? ? ? ?$post_data['post_content'] =
> > $row['some_field_thats_got_page_content'];
> > >
> > > ? ? ? ?//append the source_recid to the post data in forms of an html
> > > comment for uniqueness purposes
> > > ? ? ? ?$post_data['post_content'] = $post_data['post_content'] .
> > > "<!--{$source_recid}-->";
> > >
> > > ? ? ? ?//do the other stuff... ( shortened here for the clarify
> > purposes... )
> > >
> > > ? ? ? ?....
> > >
> > > ? ? ? ?$post_data['post_status'] = 'publish';
> > >
> > > ? ? ? ?Insert_or_UpdatePost($dbh,$post_data,$source_recid,$post_id);
> > >
> > >
> > > ? ? ? ?if ($post_id==0):
> > >
> > > ? ? ? ? ? ?//log the error and move on
> > >
> > > ? ? ? ? ? ?continue;
> > >
> > > ? ? ? ?endif;
> > >
> > >
> > > endwhile;
> > >
> > > function Insert_or_UpdatePost($dbh,$post_data,$source_recid,&$post_id){
> > >
> > > ? ? ? ?// this function first looks up the --db.table.tablerecid--
> > sequence
> > > ? ? ? ?// across all wp_posts post_content field
> > > ? ? ? ?// in determining if this record has been already INSERTed!
> > >
> > > ? ? ? ?// and depending on the outcome, it does an insert or update
> > > ? ? ? ?// and return the $post_id accordingly
> > >
> > > ? ? ? ?// if the function determines there are no such records,
> > > ? ? ? ?// then and only then, it runs the wp_insert_post!
> > >
> > > ? ? ? ?// if the function determines that there is a post like that,
> > > ? ? ? ?// it retrieves the post_id
> > > ? ? ? ?// and then switches to operation
> > > ? ? ? ?// to use the wp_update_post instead!
> > >
> > > ? ? ? ?// with this approach, technically speaking,
> > > ? ? ? ?// it should impossible to run wp_insert_post on an existing
> post!
> > >
> > > ? ? ? ?// and yet, I still get duplicate posts...
> > >
> > > ? ? ? ?// here we go;
> > >
> > > ? ? ? ?$post_id_probed = blp_sql_getdbvals($dbh,"select id from
> > > wp_posts where post_content LIKE '%--{$source_recid}--%'");
> > >
> > > ? ? ? ?if (blp_isnumber($post_id_probed)):
> > > ? ? ? ? ? ?$post_id = $post_id_probed;
> > >
> > > ? ? ? ? ? ?$post_data['ID'] = $post_id;
> > > ? ? ? ? ? ?$post_id = wp_update_post( $post_data );
> > >
> > > ? ? ? ? ? ?if ($post_id == 0):
> > >
> > > ? ? ? ? ? ? ? ?//add error
> > >
> > > ? ? ? ? ? ? ? ?return FALSE;
> > >
> > >
> > > ? ? ? ? ? ?else:
> > >
> > > ? ? ? ? ? ? ? ?update_post_meta($post_id, "wpcf-blp-migration-date",
> > > blp_now('mysql'));
> > >
> > > ? ? ? ? ? ? ? ?return TRUE;
> > >
> > > ? ? ? ? ? ?endif;
> > >
> > >
> > > ? ? ? ? endif;
> > >
> > > ? ? ? ? // if we make it this part, it means only one thing!
> > > ? ? ? ? // there is no post for the db.table.tablerecid yet,
> > > ? ? ? ? // so do the insert!
> > >
> > > ? ? ? ?$post_id = wp_insert_post( $post_data );
> > >
> > >
> > >
> > > ? ? ? ?if ($post_id == 0):
> > >
> > > ? ? ? ? ? ?//add error
> > >
> > > ? ? ? ? ? ?return FALSE;
> > >
> > >
> > > ? ? ? ?else:
> > >
> > > ? ? ? ? ? ?//add_post_meta($post_id, "wpcf-blp-migration-source",
> > > $source_recid,TRUE);
> > > ? ? ? ? ? ?//no need for that anymore
> > >
> > > ? ? ? ? ? ?return TRUE;
> > >
> > >
> > > ? ? ? ?endif;
> > >
> > >
> > > }
> > >
> > > There is also a post I created at wordpress.stackexchange site.
> > >
> > >
> >
> http://wordpress.stackexchange.com/questions/19732/prevent-duplicate-posts-in-wp-insert-post-using-custom-fields
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> >
> > End of wp-hackers Digest, Vol 89, Issue 29
> > ******************************************
> >
>
>
>
> --
> -Taylor Y.
> taylor.d.young at gmail.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
More information about the wp-hackers
mailing list