Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>There's no nice way to do this in a persistent manner that you have stored and identified to each user. As such... it'd require a bit of database and code jiggery-pokery in order to actually allow for the dates to be changed in accordance to what is stored on a various cookie/session/something.</p> <p>If you're really serious about having individual user timeframes on each post, besides the obvious 'godspeed' that I'll offer, you'd need to create the variable first. <code>gmt_offset</code> is for every post that is created, sort of like a global option as you've said. You'll have to create a value just for the users to have and look at.</p> <h1>Using Cookies</h1> <p>Having cookies is one way to store the data about whether a user has a timezone selected... and it's certainly a good way to do it. The example for that would be to do this:</p> <pre><code>set_cookie( "tzDif", $_POST['timezone_change'], time()+(30*24*60*60) ); </code></pre> <p>This sets a cookie with the name of <code>tzDif</code> to have whatever value they have chosen. The same rule applies with a session with the minor differences of syntax and assignment. This would allow you to completely absolve yourself of looking at whether or not they are logged in as it would be selected and cached on their own systems.</p> <p>If you'd like to implement that... skip to the bottom for the rest of the answer, this bit is going to be another option, using MySQL.</p> <h1>Using MySQL</h1> <p>The minor problem with cookies though, is that I've found them to be a tad unreliable.</p> <p>Storing them as an SQL variable in the tables is a lot better in terms of reliability and in stuff that I like (take that however you will). This requires a lot more jiggery-pokery and actually requires for you to alter the database too.</p> <p>You'd have to run a statement to add in an integer column named '<code>user_gmt_offset</code>' for the <code>wp_users</code> table, giving it a default of '0'. So...</p> <pre><code>ALTER TABLE wp_users ADD user_gmt_offset INT NOT NULL DEFAULT 0; </code></pre> <p>As Pekka 웃 said in the comment above, you have to have some way to identify the user. You could use cookies or sessions of your own creation, or you could use the session that wordpress creates whenever you log in.</p> <p>For the sake of simplicity, I'll talk about the latter option.</p> <p>Whenever you do have a page which has been connected to the Wordpress headers, it lets you get the functions that it has, simple enough. One of those functions is called <code>update_user_option()</code> handily enough.</p> <p>The composition of the function is similar to the one above with a few adjustments:</p> <p><code>update_user_option( USER_ID, OPTION_NAME, OPTION_VALUE, BLOG_SPECIFIC )</code></p> <p>They speak for themselves for the most part. USER_ID is the id of the user you are going to be altering. The OPTION_NAME is a string for the name of the option... again, obviously. OPTION_VALUE is whatever value you are going to be setting it to now, and finally, BLOG_SPECIFIC (which is false by default) is for if you want a certain option to be specific to a blog.</p> <p>So in your case... this is the code composition you would be using (with a minor alteration in terms of how the tz selection is used):</p> <pre><code>&lt;?php //Sort out WordPress malarkey and reference all the includes for using it define('WP_USE_THEMES', false); require("URL/TO/WP/INSTALLATION/wp-blog-header.php"); //Then let's get the current user information IF AND ONLY IF they // are logged in... don't want to break things now... if ( is_user_logged_in() ) { //Although, if they've not set the timezone yet, we don't want // it to prematurely fire and break things to null or something if ( !isset( $_POST['timezone_change'] ) return; //Get the current user's information now and assign it // to the wordpress default variable for this stuff global $current_user; get_currentuserinfo(); //Now let's do the update update_user_option( $current_user-&gt;ID, 'user_gmt_offset', $_POST['timezone_change'] ); } ?&gt; </code></pre> <p>Assuming that I have done things right in theory... that should change an individual user's value to whatever timezone they have desired. That was the SQL explanation.</p> <h1>Implementing in Wordpress</h1> <p>Moving on again to how it's actually implemented... you're going to have to go and find the function that gets the time, in other words... <code>the_time()</code> as I recall, and alter it to check a few things.</p> <p>You'll have to check whether or not the user is logged in/if the cookie is set, if they're/it's not, use the default values of gmt_offset given in the database, and if they are/it is... use the value that has been defined previously, whether it's in the cookie, or in the database.</p> <p>I'll not go into too specific detail of how to do that, I figure there's enough detail in this post to potentially confuse before I start rambling on about altering that function to something else (read as written too much).</p> <p>I'll do some checking and re-update this with any enhancements that I find.</p>
    singulars
    1. This table or related slice is empty.
    1. POchanging wordpress timezone manually by visitors
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USM4Numbers
    1. USM4Numbers
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POchanging wordpress timezone manually by visitors
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COthanks @M477h3w1012 ive manged to add it as a cookie in the function.php `function set_new_cookie() { setcookie("tzDif", $_POST['timezone_change'], time()+(30*24*60*60) ); } add_action( 'init', 'set_new_cookie');` and it got stored in the browser with the value I choose from the select but when I try to echo $_COOKIE['tzDif'] I dont get anything why is that though its stored in the browser am I calling it in a wrong way ?
      singulars
      1. PO
      1. USKash
    2. CO@MohammedKashmiry: Try putting $_COOKIE["tzDif"] instead of using '. Quite honestly, I'm not sure why it didn't work with ' for me. If that fails, do a var_dump of the cookie variable and see what pops up.
      singulars
      1. PO
      1. USM4Numbers
    3. CODid a var_dump got a null after going through it turned out that the cookie disappear after a while so after I submit a value through _POST I need to refresh the page again and the value will appear the problem is after refreshing for a second time or going to a different page the cookie get deleted not sure what is the issue here the expiry is set to (10 * 365 * 24 * 60 * 60) so I dont think its that is it with the way I am posting the value to the cookie with _POST?
      singulars
      1. PO
      1. USKash
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload